微服務(wù)是什么？
微服務(wù)是一種架構(gòu)設(shè)計(jì)模式。在微服務(wù)架構(gòu)中，業(yè)務(wù)邏輯被拆分成一系列小而松散耦合的分布式組件，共同構(gòu)成了較大的應(yīng)用。每個(gè)組件都被稱為微服務(wù)，而每個(gè)微服務(wù)都在整體架構(gòu)中執(zhí)行著單獨(dú)的任務(wù)，或負(fù)責(zé)單獨(dú)的功能。每個(gè)微服務(wù)可能會(huì)被一個(gè)或多個(gè)其他微服務(wù)調(diào)用，以執(zhí)行較大應(yīng)用需要完成的具體任務(wù)；系統(tǒng)還為任務(wù)執(zhí)行——比如搜索或顯示圖片任務(wù)，或者其他可能需要多次執(zhí)行的任務(wù)提供了統(tǒng)一的解決處理方式，并限制應(yīng)用內(nèi)不同地方生成或維護(hù)相同功能的多個(gè)版本。
使用微服務(wù)架構(gòu)還提供這樣一種機(jī)制：增加新加入開發(fā)者的生產(chǎn)效率，并減少新功能的推廣時(shí)長。每個(gè)微服務(wù)的代碼庫與相關(guān)工具集都很有限；開發(fā)者無需再去了解龐大而復(fù)雜的系統(tǒng)，只需理解自己所做的那部分微服務(wù)相關(guān)子集，便能貢獻(xiàn)生產(chǎn)力。由于無需考慮應(yīng)用的現(xiàn)有部分使用了什么語言或工具集，或者較大應(yīng)用的其他開發(fā)者是否了解這些語言和工具，只需使用當(dāng)前任務(wù)最趁手的工具，因此微服務(wù)開發(fā)起來非常迅速。
為了充分利用速度優(yōu)勢，讓小團(tuán)隊(duì)開發(fā)成為可能，團(tuán)隊(duì)需要自主權(quán)；他們必須能迅速作出決定，避免過度監(jiān)管。要想支持這一點(diǎn)，工作團(tuán)隊(duì)?wèi)?yīng)當(dāng)包括所有相關(guān)人員，從產(chǎn)品經(jīng)理到發(fā)布運(yùn)行人員。由于微服務(wù)組件是松散耦合并通過API通訊的，各方在大多決定時(shí)擁有高度自主權(quán)并不會(huì)影響應(yīng)用的整體功能。只要微服務(wù)能發(fā)布API，并能用這些API執(zhí)行所需的功能，整體系統(tǒng)就能運(yùn)作良好。
由于在一個(gè)微服務(wù)架構(gòu)中有許多獨(dú)立的組件，在彈性網(wǎng)絡(luò)（比如公共或私有云）上使用現(xiàn)代化的DevOps對于確保整體系統(tǒng)在大多數(shù)情況下正常運(yùn)轉(zhuǎn)就顯得尤為重要。特別是像與額外實(shí)例的自動(dòng)部署相關(guān)聯(lián)的健康與負(fù)載自動(dòng)監(jiān)控（為了盡可能減少未充分利用的實(shí)例）這樣的東西在很多情況下就變得至關(guān)重要。
SOA是什么？
服務(wù)導(dǎo)向式架構(gòu)（SOA）是集成多個(gè)較大組件（一般是應(yīng)用）的一種機(jī)制，它們將整體構(gòu)成一個(gè)彼此協(xié)作的套件。一般來說，每個(gè)組件會(huì)從始至終執(zhí)行一塊完整的業(yè)務(wù)邏輯，通常包括完成整體大action所需的各種具體任務(wù)與功能。組件一般都是松耦合的，但這并非SOA架構(gòu)模式的要求。
盡管沒有嚴(yán)格要求，SOA一般使用某種集中式管理，比如審查委員會(huì)、主架構(gòu)師或架構(gòu)委員會(huì)來嚴(yán)格定義每個(gè)系統(tǒng)組件應(yīng)當(dāng)做什么，如何執(zhí)行。相同類型的功能可能會(huì)按需在多個(gè)組件中分別定義與記錄，而每個(gè)組件所使用的語言與工具集有可能是集中確定與統(tǒng)一的，也可能不是。SOA可能使用任何類型的SDLC、組織架構(gòu)或符合這種管理的開發(fā)模型；敏捷、瀑布、看板管理或者一些組合形式都是可用而不違反SOA原則的。
此外，現(xiàn)代化的DevOps和云部署對SOA當(dāng)然很有效，在這種系統(tǒng)中縮減組件數(shù)量并非必需。但在這些系統(tǒng)中，就算在最好的情況下，一些較大的組件也可能太過復(fù)雜而難以實(shí)現(xiàn)自動(dòng)化，在最壞的情況下甚至完全無法實(shí)現(xiàn)。
舉個(gè)例子，自動(dòng)化部署的一個(gè)標(biāo)準(zhǔn)可能得需要100%通過一套自動(dòng)化測試。這將確保現(xiàn)有的功能在新版本中仍舊可用（沒有回歸），而新功能也按照預(yù)期實(shí)現(xiàn)。隨著功能交互越來越多，看似不相關(guān)的開發(fā)工作意外破壞現(xiàn)有功能某些方面的可能性有所增加。
此外一些測試可能很敏感，由于壞境或網(wǎng)絡(luò)因素而出現(xiàn)失敗個(gè)例。在100個(gè)測試案例中，5%的隨機(jī)測試出現(xiàn)1%的失敗率不會(huì)對普通發(fā)布造成大的阻礙。而在成千上萬的測試中，同樣的幾率可能會(huì)造成較大影響，很多時(shí)候會(huì)造成至少一個(gè)隨機(jī)故障。因此，即便要發(fā)布的版本沒有什么實(shí)際的錯(cuò)誤，也會(huì)因?yàn)闊o法通過這條標(biāo)準(zhǔn)而無法部署。
直接對比——建立購物車
我們來看一個(gè)在線購物網(wǎng)站。這個(gè)網(wǎng)站會(huì)有一些不同的功能，比如產(chǎn)品目錄、用戶帳號還有購物車等等。
使用SOA的開發(fā)公司一般會(huì)將購物網(wǎng)站拆分成主要的業(yè)務(wù)邏輯組，并將每個(gè)部分作為獨(dú)立應(yīng)用分別開發(fā)，最后集成到一起。
舉個(gè)例子，整個(gè)購物車及其所有功能是由一大群人所開發(fā)的一個(gè)應(yīng)用，他們需要了解整個(gè)購物車的工作機(jī)制，以便能夠修改。在這個(gè)應(yīng)用中，是代碼負(fù)責(zé)顯示物品、增加或移除購物車商品、查看庫存、處理運(yùn)費(fèi)選項(xiàng)、處理稅率計(jì)算、處理匯率、在更改時(shí)更新顯示并將最終的訂單細(xì)節(jié)發(fā)到用戶郵箱里（還有其他等等）。用來顯示購物車商品的代碼包括在購物車應(yīng)用中，可能與在瀏覽目錄視圖中用來顯示商品名稱的代碼截然不同，從而造成需要維護(hù)的兩套代碼相似但不相同，還可能造成大應(yīng)用UX上的某些不一致。
使用微服務(wù)架構(gòu)的開發(fā)公司會(huì)將購物車切分成較小的任務(wù)導(dǎo)向服務(wù)。不再是購物車應(yīng)用了，而可能是稅率計(jì)算服務(wù)、添加/移除商品服務(wù)、運(yùn)費(fèi)服務(wù)、匯率服務(wù)和最終訂單撰寫服務(wù)。購物車功能可能也會(huì)用到一些常用的服務(wù)——它們會(huì)用在購物應(yīng)用的很多地方，比如顯示商品服務(wù)、顯示產(chǎn)品圖片服務(wù)、查看庫存服務(wù)、用戶支付偏好服務(wù)以及郵件服務(wù)。而“購物車”、“產(chǎn)品目錄、“用戶賬戶”之間并沒有分界，通用代碼被封裝成各種服務(wù)，待需要時(shí)用在各種功能中。
當(dāng)公司向中心授權(quán)組織請求展示產(chǎn)品時(shí)，必須修改展示來源，還得將瀏覽統(tǒng)計(jì)添加到購物應(yīng)用中。在SOA架構(gòu)中，產(chǎn)品目錄應(yīng)用和購物車應(yīng)用必須獨(dú)立各自更新，以體現(xiàn)變更。
需要對兩個(gè)應(yīng)用進(jìn)行重測試，以確保變更沒有影響其他功能，然后再重新部署。如果在這兩個(gè)有改動(dòng)的應(yīng)用中還有其他功能有所變更，這一過程可能會(huì)進(jìn)一步拖延（取決于開發(fā)進(jìn)度的實(shí)現(xiàn)情況），而無法發(fā)布。一旦重新部署，負(fù)責(zé)展示的新機(jī)制速度可能明顯要比舊機(jī)制慢，從而成為瓶頸。
延遲會(huì)導(dǎo)致客戶投訴，然后問題被報(bào)告給管理層。有管理者決定要通過向整個(gè)產(chǎn)品目錄應(yīng)用與購物車應(yīng)用部署額外實(shí)例，以處理額外的負(fù)載，應(yīng)對延遲問題（如果有適當(dāng)?shù)谋O(jiān)控與部署規(guī)則，這可能是自動(dòng)執(zhí)行的）。由于整個(gè)應(yīng)用需要擴(kuò)展，整個(gè)過程需要大量的額外處理能力與存儲(chǔ)空間，在未執(zhí)行額外部署的情況下，很多功能可能只能勉強(qiáng)運(yùn)行。
而在微服務(wù)這里，只需進(jìn)行一項(xiàng)改變——更新產(chǎn)品展示服務(wù)。這項(xiàng)服務(wù)可以獨(dú)立進(jìn)行快速的更改、測試與部署，而不會(huì)影響到大系統(tǒng)中的其他部分。此外，一旦發(fā)現(xiàn)瓶頸（很可能是通過自動(dòng)化監(jiān)控），無需向產(chǎn)品目錄功能或者購物車服務(wù)所使用的其他服務(wù)部署更多實(shí)例，就能（可能是自動(dòng)的）部署這項(xiàng)服務(wù)的額外實(shí)例，從而限制了支持額外部署所需的資源。
以上所有都是建立在想要發(fā)布一個(gè)大型在線商店，向各地各類人等售賣各類產(chǎn)品的假設(shè)上。如果假設(shè)你只想向美國境內(nèi)的客戶販賣一種商品，并且只使用UPS作為物流的話。大量架構(gòu)與復(fù)雜的在線商店都是沒有必要的。
雖然仍需追蹤用戶信息、提供購物車與結(jié)算功能、展示產(chǎn)品信息與圖片，甚至一些評論評價(jià)，但每一項(xiàng)功能所需都比復(fù)雜的在線商店要少得多。產(chǎn)品分類需求、計(jì)算不同運(yùn)費(fèi)選項(xiàng)的需求、系統(tǒng)處理增加/移除延時(shí)差異的需求還有所有其他綜合商城所需的功能都不再需要。
在這種情況下，使用SOA將購物車、用戶賬戶與產(chǎn)品展示組件與網(wǎng)站相集成可能要比使用微服務(wù)架構(gòu)（像上面描述的那樣有更為細(xì)致的組件定義）更有意義。在這種簡單的設(shè)置中，不僅每個(gè)較大的組件被降低到復(fù)雜程度可控的范圍內(nèi)，而且實(shí)現(xiàn)這類網(wǎng)站所需的開發(fā)與其他員工的人數(shù)都會(huì)很少，無需將小型獨(dú)立團(tuán)隊(duì)進(jìn)行拓展。
相似卻不相同
微服務(wù)與SOA有很多相同之處。兩者都屬于典型的、包含松耦合分布式組件的系統(tǒng)結(jié)構(gòu)。但是兩種架構(gòu)背后的意圖是不同的：SOA嘗試將應(yīng)用集成，一般采用中央管理模式來確保各應(yīng)用能夠交互運(yùn)作。微服務(wù)嘗試部署新功能，快速有效地?cái)U(kuò)展開發(fā)團(tuán)隊(duì)。它著重于分散管理、代碼再利用與自動(dòng)化執(zhí)行。
總結(jié)：
哪種適合你的公司呢？完全取決于你的選擇。
第三十四屆CIO班招生
北達(dá)軟EXIN網(wǎng)絡(luò)空間與IT安全基礎(chǔ)認(rèn)證培訓(xùn)
北達(dá)軟EXIN DevOps Professional認(rèn)證培訓(xùn)
責(zé)編：pingxiaoli
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請及時(shí)通知本站，予以刪除。
搶沙發(fā)
