微服務是一種架構設計模式。在微服務架構中，業務邏輯被分解為一系列小的、鬆耦合的、分散式元件，組合起來形成大型的應用。每個元件都被稱為一個微服務，每個微服務負責一個任務或功能。每個微服務可能被其它一個或多個微服務呼叫，來執行特定的任務，比如用一種統一的方式來處理搜尋、圖片展示，或其它需要在應用的不同場景下開發或維護多個版本的情況。

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

微服務可以被很快開發出來，因為他們可以使用手邊最適合的語言和工具集，不需要擔心應用其它元件的技術選型，也不用擔心其他開發者對這些語言和工具是否瞭解。

為了充分發揮小團隊輕便靈活的特點，團隊需要有自治權，他們要快速做決定，並且遮蔽外部的監管。為了達到這個目的，整個工作組應該包含了從產品管理到釋出和運營的所有相關人員。由於微服務元件是鬆耦合的，通過API進行通訊，對於大部分決定來說，高度的自治權並不影響整個應用的功能。只要微服務向外開發了自己的API，並能被API呼叫執行對應的功能，整個系統就能執行良好。

由於一個微服務架構中有這麼多獨立的元件，在一個彈性的網路環境（比如公有云或私有云）中使用現代的DevOps方式，成為了保證整個系統在大多數情況下穩定執行的重要保證。尤其是在很多情況下，健康和負載的自動監控，以及附加例項的自動部署變得至關重要了。

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意在整合應用，而且使用集中管理模式來確保應用間的互動。而微服務意在更高效地部署新功能和擴充套件開發團隊，並且組織的非集權化，程式碼重用和自動化。

總結如下：

原文出處：靈雀雲

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