Microservices VS. SOA

什麼是微服務？

微服務是一種架構設計模式。在微服務架構中，業務邏輯被分解爲一系列小的、鬆耦合的、分佈式組件，組合起來造成大型的應用。每一個組件都被稱爲一個微服務，每一個微服務負責一個任務或功能。每一個微服務可能被其它一個或多個微服務調用，來執行特定的任務，好比用一種統一的方式來處理搜索、圖片展現，或其它須要在應用的不一樣場景下開發或維護多個版本的狀況。

使用微服務架構還能造成一種機制來提升新手的生產率，減小新功能推向市場的時間。每一個微服務有一個有邊界的代碼庫，以及關聯的工具集；開發者不須要了解整個大型的複雜系統就能上手，只須要知道與其微服務相關的部分就好。 

微服務能夠被很快開發出來，由於他們可使用手邊最適合的語言和工具集，不須要擔憂應用其它組件的技術選型，也不用擔憂其餘開發者對這些語言和工具是否瞭解。

爲了充分發揮小團隊輕便靈活的特色，團隊須要有自治權，他們要快速作決定，而且屏蔽外部的監管。爲了達到這個目的，整個工做組應該包含了從產品管理到發佈和運營的全部相關人員。因爲微服務組件是鬆耦合的，經過API進行通訊，對於大部分決定來講，高度的自治權並不影響整個應用的功能。只要微服務向外開發了本身的API，並能被API調用執行對應的功能，整個系統就能運行良好。

因爲一個微服務架構中有這麼多獨立的組件，在一個彈性的網絡環境（好比公有云或私有云）中使用現代的DevOps方式，成爲了保證整個系統在大多數狀況下穩定運行的重要保證。尤爲是在不少狀況下，健康和負載的自動監控，以及附加實例的自動部署變得相當重要了。

 

什麼是SOA？

SOA（Service Oriented Architecture）是一種集成多個組件（一般是粒度更大的應用）的方式，他們組合起來能夠造成一個彼此協做的系統。每一個組件專門從頭至尾地執行一個完整的業務邏輯，一般涉及多個特定的任務和功能共同完成一個更大的動做。組件是鬆耦合的，但這不是必要條件。

雖然沒有嚴格的需求，但SOA是典型的集中式管理：一個審覈委員會，一個首席架構師或架構委員，嚴格定義了系統每一個組件應該作什麼，以及如何去作。若是組件使用的語言和工具集不是集中定義和統一的話，一樣類型的功能可能會被分開定義或寫在多個組件中。SOA對軟件生命週期管理（SDLC）的模式和組織架構都沒有嚴格的限制，開發模式方面：敏捷（agile），瀑布（waterfall），看板（kanban），或者幾種模式的組合，都不違背SOA的原則。

並且，雖然DevOps和雲計算等新技術對於SOA頗有用，但因爲這種系統的組件數量很少，因此並非本質需求。可是這些系統中一些更大的組件可能會至關複雜，自動化很是困難，甚至是不切實際的。

好比，自動化部署成功的標準多是100%地經過一系列自動化測試。這保證了現有的功能在新的版本中依然正常工做，而新的功能達到預期的目標。隨着功能的交互愈來愈多，現有功能的某些方面，極可能會被看起來並不相關的開發工做意外打散。

並且，一些測試可能會因爲環境或網絡問題失敗。好比，若是100個測試的失敗率是5%，失敗的時間比率是1%，並不會影響正常的發佈。但若是測試的數量成千上萬，相同的比例產生的影響就不容小覷了。所以，就算候選發佈版本並無問題，也常常會在失敗在不知足部署條件上。

直接對比：以電商網站爲例

下面以一個電商網站爲例，來對比SOA和微服務架構。電商網站一般有不少功能模塊，基本的模塊包括：產品目錄，用戶帳戶，購物車等。

一個基於SOA技術的開發團隊，一般會將這個網站按業務邏輯拆分爲幾個分別的應用，而後集成到一塊兒。

好比，整個購物車及其全部功能會被放到一個應用中，負責這個應用開發的團隊中，每一個人都要對整個購物車的業務瞭如指掌才行。應用內的代碼要實現諸如產品展現，從購物車中添加和刪除條目，庫存查詢，送貨處理，計稅處理，帳單處理，展現更新，以及將最後的訂單詳情發給用戶等功能。在購物車應用內的產品展現，與產品目錄應用中的產品實現的功能很是相似，但代碼因爲分屬2個應用，由不一樣的團隊維護，可能徹底不一樣。相似的功能卻要維護兩份徹底不一樣的代碼顯然並不合理，並且在大型應用中極可能形成不一致的問題。

而基於微服務架構的團隊，會將購物車拆分爲更小的面向任務的服務，好比：一個計稅服務，一個添加/刪除條目的服務，一個送貨服務，一個帳單服務，以及一個造成最終訂單的服務。購物車還會用到一些通用服務，好比：產品展現服務，產品圖片展現服務，庫存查詢服務，用戶支付選擇服務，以及郵件服務。這些通用的代碼會被封裝爲服務，不論是『購物車』，『產品目錄』仍是『用戶帳戶』可使用調用這些服務。

假設公司決定經過一個第三方爲產品的圖片加上license，那麼圖片的地址都要更改，瀏覽的數據統計也要被加到應用中。在SOA架構中，這個更改會同時影響到產品目錄應用和購物車應用。兩個應用都要從新測試，才能被部署，若是其中一個應用的更新不能進入部署，就會影響整個應用的更新部署。就算部署成功了，很顯然新的圖片服務機制比原來要慢了，可能會成爲瓶頸。

你們意識到這個問題後，可能會經過部署更多實例的方法來解決，固然產品展現應用和購物車應用都要增長實例（若是有合適的監控和部署方案的話，這個過程多是自動的）。這意味着整個應用都要被擴展了，雖然不少功能並不須要額外的資源。

而在微服務的世界中，這種狀況只須要更新一個服務：產品圖片展現服務。在不影響系統其它部分的條件下，修改、測試和部署一個服務是很快的。並且某個服務出現了瓶頸的話，能夠獨立地擴展，避免了資源的浪費。

以上假設都基於你要發佈一個大型的電子商務網站，用戶量很大，而且分佈地域很廣。若是你只賣一個產品，而且顧客限定爲美國地區使用UPS的顧客，許多電商網站的基礎設施和複雜度都不在你的考慮範圍內。

你依然要跟蹤用戶信息，提供購物車和結帳功能，並且要有一個頁面展現產品信息，圖片，以及一部分用戶評論，可是全部這些功能都要比大型電商簡單不少。不須要考慮產品目錄，送貨選項，添加或刪除商品，以及全部其它多種商品的電商須要考慮的問題。

這種狀況下，使用SOA的架構更適合，由於每一個組件的複雜度都下降到了可管理的程度，並且實現這種網站所需的開發人員數量也很少，免去了要靠小微型的獨立團隊來擴展規模的問題。

相似可是不一樣

因此微服務和SOA有不少相似之處：兩種系統都由鬆耦合的分佈式組件構成。可是兩種架構背後的意圖是很是不一樣的：SOA意在集成應用，並且使用集中管理模式來確保應用間的交互。而微服務意在更高效地部署新功能和擴展開發團隊，而且組織的非集權化，代碼重用和自動化。

總結以下：

特性	SOA	Microservices
組件大小	大塊的業務邏輯	單獨的任務或小塊的業務邏輯
耦合度	一般是鬆耦合	必須是鬆耦合
組織結構	任意	小型的，跨職能團隊
管理	集中式管理	非集權化管理
目標	保證應用間的相互交互	爲了高效地部署新功能和擴展開發團隊

原文連接：https://www.voxxed.com/blog/2016/01/microservices-versus-soa-practice/