開始之前，我們先簡單看下單體架構、SOA與微服務之間的區別，如下圖所示：
簡單來講，對於單體架構，其就像一個超大容器，容器內集中包含了該應用的所有軟件組件，並且組件與組件之間緊密耦合。
而對於SOA架構來說，其本質上也是服務的集合，服務與服務之間彼此調用，這種調用可能涉及到簡單的數據處理或者有超過多個服務之間相互協作共同完成某種業務操作，在SOA中我們需要考慮服務之間應如何相互通信。
最後說到微服務，或者我們稱之爲微服務架構，這是一種架構風格，聚焦業務領域，將應用通過一個個小而自治的服務組織起來。
說到SOA與微服務，兩者均依賴於服務作爲其主要組件，但不同架構下的服務特徵卻有很大的不同，下面我們看下SOA與微服務之間的主要區別都有哪些？
對於SOA來說，其定義了四種基本類型的服務
Business Services： 業務類服務
- 粗粒度服務，主要定義關鍵業務操作
- 通常可以通過XML或者BPEL語言來表示
Enterprise Services： 企業級服務
- 實現業務類服務所定義的相關功能
- 主要依賴於應用級服務和架構級服務來滿足業務需求
Application Services： 應用級服務
- 細粒度服務，聚焦特定的應用上下文
- 特定的用戶接口界面可直接調用這些服務
Infrastructure Services： 基礎架構級服務
- 主要負責非功能性操作，比如：認證、授權、安全、日誌等等
- 可由應用級服務或者企業級服務直接調用。
微服務則減少了服務的分類，僅包含了兩種類型服務
Functional Services： 功能性服務
- 支持特定的業務操作
- 服務聚焦對外服務，服務之間不共享
Infrastructure Services： 基礎架構級服務
- 和SOA一樣，基礎架構級服務側重於審計、安全和日誌類等基礎類支持服務
- 基礎架構級服務並不對外開放
| SOA | MSA |
|---|---|
| 遵循儘可能多的共享 | 僅可能少的共享 |
| 更多的強調業務功能的重用 | 側重邊界上下文：bounded context |
| 遵從共同的標準和公約 | 側重於協作，強調自治 |
| 服務之間採用ESB通信 | 簡單消息系統 |
| 支持多種協議 | 更青睞於簡單消息通信，比如：HTTP REST |
| 多線程，阻塞IO，開銷大 | 通常是單線程，事件驅動，非阻塞IO處理機制 |
| 最大化應用服務的可重用性 | 側重解耦 |
| 通常使用傳統的關係型數據庫 | 除了傳統的關係型數據庫，更常見NO SQL等新型關係型數據庫的運用 |
| 系統級的更改可能會導致整個系統的修改 | 系統級修改僅需構造新的服務來滿足 |
| DevOps/持續交付成爲可能，但並非主流 | 着眼於DevOps/持續交付 |
SOA與微服務（MSA）主要區別總結
-
服務粒度 ：微服務強調的是服務功能的純粹性和單一性，而對於SOA 來說，其服務組件可大可小，比如從很小的應用服務或者很大的企業級服務，比如在SOA中，我們用一個很大的產品或者子系統來表示一個服務
-
組件共享：組件共享是SOA架構的核心原則，而MSA則通過邊界上下文Bounded Context來儘可能的減少這種共享的可能性。邊界上下文涉及到組件的耦合性以及組件內部的數據的獨立性。SOA通常依賴於多個服務來滿足實現業務需求，在這種場景下，SOA系統通常較之MSA響應慢
-
中間件 vs API服務網關：MSA架構通常包含我們所熟知的服務網關，而SOA通常則包含消息中間件組件，消息中間件組件一般具備消息路由、協議轉換等功能，而MSA的服務網關則主要扮演服務提供方與服務消費者的橋樑作用。
-
遠程服務調用：SOA主要依賴於AMQP, MSMQ,SOAP等服務訪問協議，而MSA則主要依賴於 REST和JMS, MSMQ等簡單消息協議
-
異構的互操作性：SOA通過消息中間件組件使得多個不同協議的相互傳遞的成爲可能，而SOA則簡化了服務間的訪問協議，如果你希望通過不同的協議來集成多個異構環境，你則需要考慮使用SOA架構，相反，如果你希望通過同樣的協議來訪問訪問，那麼MSA可能是一個更好的選擇。
最後，總結一句，不能簡單的來講孰優孰劣，而是應該結合您當前正在構建的應用系統來綜合考慮。SOA更適合大型、複雜的業務應用程序，比如應用需要許多異構環境的相互交互，換句話講，相對較小的應用程序並不適合SOA，因爲它們不需要消息傳遞中間件組件。而微服務則更適合較小的、業務分區良好的、基於WEB應用，在這些應用中，開發人員可以有更大的控制權。
原文鏈接：