微服務與SOA的實踐應用對比

關於微服務是什麼，面向服務的體系結構（SOA）又是什麼，二者之間有何關聯真是衆說紛紜、困惑頗多。不少人都加入了這場討論，從ThoughtWorks的Martin Fowler到Cap Gemini的Steve Jones全都參與了進來。

微服務是什麼？

微服務是一種架構設計模式。在微服務架構中，業務邏輯被拆分紅一系列小而鬆散耦合的分佈式組件，共同構成了較大的應用。每一個組件都被稱爲微服務，而每一個微服務都在總體架構中執行着單獨的任務，或負責單獨的功能。每一個微服務可能會被一個或多個其餘微服務調用，以執行較大應用須要完成的具體任務；系統還爲任務執行——好比搜索或顯示圖片任務，或者其餘可能須要屢次執行的任務提供了統一的解決處理方式，並限制應用內不一樣地方生成或維護相同功能的多個版本。

使用微服務架構還提供這樣一種機制：增長新加入開發者的生產效率，並減小新功能的推廣時長。每一個微服務的代碼庫與相關工具集都頗有限；開發者無需再去了解龐大而複雜的系統，只需理解本身所作的那部分微服務相關子集，便能貢獻生產力。因爲無需考慮應用的現有部分使用了什麼語言或工具集，或者較大應用的其餘開發者是否瞭解這些語言和工具，只需使用當前任務最趁手的工具，所以微服務開發起來很是迅速。

爲了充分利用速度優點，讓小團隊開發成爲可能，團隊須要自主權；他們必須能迅速做出決定，避免過分監管。要想支持這一點，工做團隊應當包括全部相關人員，從產品經理到發佈運行人員。因爲微服務組件是鬆散耦合並經過API通信的，各方在大多決定時擁有高度自主權並不會影響應用的總體功能。只要微服務能發佈API，並能用這些API執行所需的功能，總體系統就能運做良好。

因爲在一個微服務架構中有許多獨立的組件，在彈性網絡（好比公共或私有云）上使用現代化的DevOps對於確保總體系統在大多數狀況下正常運轉就顯得尤其重要。特別是像與額外實例的自動部署相關聯的健康與負載自動監控（爲了儘量減小未充分利用的實例）這樣的東西在不少狀況下就變得相當重要。

SOA是什麼？

服務導向式架構（SOA）是集成多個較大組件（通常是應用）的一種機制，它們將總體構成一個彼此協做的套件。通常來講，每一個組件會從始至終執行一塊完整的業務邏輯，一般包括完成總體大action所需的各類具體任務與功能。組件通常都是鬆耦合的，但這並不是SOA架構模式的要求。

儘管沒有嚴格要求，SOA通常使用某種集中式管理，好比審查委員會、主架構師或架構委員會來嚴格定義每一個系統組件應當作什麼，如何執行。相同類型的功能可能會按需在多個組件中分別定義與記錄，而每一個組件所使用的語言與工具集有多是集中肯定與統一的，也可能不是。SOA可能使用任何類型的SDLC、組織架構或符合這種管理的開發模型；敏捷、瀑布、看板管理或者一些組合形式都是可用而不違反SOA原則的。

此外，現代化的DevOps和雲部署對SOA固然頗有效，在這種系統中縮減組件數量並不是必需。但在這些系統中，就算在最好的狀況下，一些較大的組件也可能太過複雜而難以實現自動化，在最壞的狀況下甚至徹底沒法實現。

舉個例子，自動化部署的一個標準可能得須要100%經過一套自動化測試。這將確保現有的功能在新版本中仍舊可用（沒有迴歸），而新功能也按照預期實現。隨着功能交互愈來愈多，看似不相關的開發工做意外破壞現有功能某些方面的可能性有所增長。

此外一些測試可能很敏感，因爲壞境或網絡因素而出現失敗個例。在100個測試案例中，5%的隨機測試出現1%的失敗率不會對普通發佈形成大的阻礙。而在成千上萬的測試中，一樣的概率可能會形成較大影響，不少時候會形成至少一個隨機故障。所以，即使要發佈的版本沒有什麼實際的錯誤，也會由於沒法經過這條標準而沒法部署。

直接對比——創建購物車

咱們來看一個在線購物網站。這個網站會有一些不一樣的功能，好比產品目錄、用戶賬號還有購物車等等。

使用SOA的開發公司通常會將購物網站拆分紅主要的業務邏輯組，並將每一個部分做爲獨立應用分別開發，最後集成到一塊兒。

舉個例子，整個購物車及其全部功能是由一大羣人所開發的一個應用，他們須要瞭解整個購物車的工做機制，以便可以修改。在這個應用中，是代碼負責顯示物品、增長或移除購物車商品、查看庫存、處理運費選項、處理稅率計算、處理匯率、在更改時更新顯示並將最終的訂單細節發到用戶郵箱裏（還有其餘等等）。用來顯示購物車商品的代碼包括在購物車應用中，可能與在瀏覽目錄視圖中用來顯示商品名稱的代碼大相徑庭，從而形成須要維護的兩套代碼類似但不相同，還可能形成大應用UX上的某些不一致。

使用微服務架構的開發公司會將購物車切分紅較小的任務導向服務。再也不是購物車應用了，而多是稅率計算服務、添加/移除商品服務、運費服務、匯率服務和最終訂單撰寫服務。購物車功能可能也會用到一些經常使用的服務——它們會用在購物應用的不少地方，好比顯示商品服務、顯示產品圖片服務、查看庫存服務、用戶支付偏好服務以及郵件服務。而「購物車」、「產品目錄、「用戶帳戶」之間並無分界，通用代碼被封裝成各類服務，待須要時用在各類功能中。

當公司向中心受權組織請求展現產品時，必須修改展現來源，還得將瀏覽統計添加到購物應用中。在SOA架構中，產品目錄應用和購物車應用必須獨立各自更新，以體現變動。

須要對兩個應用進行重測試，以確保變動沒有影響其餘功能，而後再從新部署。若是在這兩個有改動的應用中還有其餘功能有所變動，這一過程可能會進一步拖延（取決於開發進度的實現狀況），而沒法發佈。一旦從新部署，負責展現的新機制速度可能明顯要比舊機制慢，從而成爲瓶頸。

延遲會致使客戶投訴，而後問題被報告給管理層。有管理者決定要經過向整個產品目錄應用與購物車應用部署額外實例，以處理額外的負載，應對延遲問題（若是有適當的監控與部署規則，這多是自動執行的）。因爲整個應用須要擴展，整個過程須要大量的額外處理能力與存儲空間，在未執行額外部署的狀況下，不少功能可能只能勉強運行。

而在微服務這裏，只需進行一項改變——更新產品展現服務。這項服務能夠獨立進行快速的更改、測試與部署，而不會影響到大系統中的其餘部分。此外，一旦發現瓶頸（極可能是經過自動化監控），無需向產品目錄功能或者購物車服務所使用的其餘服務部署更多實例，就能（多是自動的）部署這項服務的額外實例，從而限制了支持額外部署所需的資源。

以上全部都是創建在想要發佈一個大型在線商店，向各地各種人等售賣各種產品的假設上。若是假設你只想向美國境內的客戶販賣一種商品，而且只使用UPS做爲物流的話。大量架構與複雜的在線商店都是沒有必要的。

雖然仍需追蹤用戶信息、提供購物車與結算功能、展現產品信息與圖片，甚至一些評論評價，但每一項功能所需都比複雜的在線商店要少得多。產品分類需求、計算不一樣運費選項的需求、系統處理增長/移除延時差別的需求還有全部其餘綜合商城所需的功能都再也不須要。

在這種狀況下，使用SOA將購物車、用戶帳戶與產品展現組件與網站相集成可能要比使用微服務架構（像上面描述的那樣有更爲細緻的組件定義）更有意義。在這種簡單的設置中，不只每一個較大的組件被下降到複雜程度可控的範圍內，並且實現這類網站所需的開發與其餘員工的人數都會不多，無需將小型獨立團隊進行拓展。

類似卻不相同

微服務與SOA有不少相同之處。二者都屬於典型的、包含鬆耦合分佈式組件的系統結構。可是兩種架構背後的意圖是不一樣的：SOA嘗試將應用集成，通常採用中央管理模式來確保各應用可以交互運做。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。

總結：

功能	SOA	微服務
組件大小	大塊業務邏輯	單獨任務或小塊業務邏輯
耦合	一般鬆耦合	老是鬆耦合
公司架構	任何類型	小型、專一於功能交叉的團隊
管理	着重中央管理	着重分散管理
目標	確保應用可以交互操做	執行新功能，快速拓展開發團隊

哪一種適合你的公司呢？徹底取決於你的選擇。

原文連接: Microservices Versus SOA in Practice

譯文轉自：http://geek.csdn.net/news/detail/51826

深刻閱讀：淺析深究什麼是SOA？