SOA 架構與微服務架構的區別

注重重用，微服務注重重寫

SOA 的主要目的是爲了企業各個系統更加容易地融合在一塊兒。

微服務一般由重寫一個模塊開始。要把整個巨石型的應用重寫是有很大的風險的，也不必定必要。咱們向微服務遷移的時候一般從耦合度最低的模塊或對擴展性要求最高的模塊開始。

把它們一個一個剝離出來用敏捷地重寫，能夠嘗試最新的技術和語言和框架，而後 單獨佈署。它一般不依賴其餘服務。微服務中經常使用的 API Gateway 的模式主要目的也不是重用代碼。

而是減小客戶端和服務間的往來。API gateway 模式不等同與 Facade 模式，咱們可使用如 Future 之類的調用，甚至返回不完整數據。

注重水平服務，微服務注重垂直服務

SOA 設計喜歡給服務分層(如 Service Layers 模式)。咱們經常見到一個 Entity 服務層的設計，美其名曰 Data Access Layer。這種設計要求全部的服務都經過這個 Entity 服務層。來獲取數據。這種設計很是不靈活，好比每次數據層的改動均可能影響到全部業務層的服務。而每一個微服務一般有它本身獨立的 Data Store。咱們在拆分數據庫時能夠適當的作些去範式化，讓它不須要依賴其餘服務的數據。

微服務一般是直接面對用戶的，每一個微服務一般直接爲用戶提供某個功能。相似的功能可能針對手機有一個服務，針對機頂盒是另一個服務。在 SOA 設計模式中這種狀況一般會用到 Multi-ChannelEndpoint 的模式返回一個大而全的結果兼顧到全部的客戶端的需求。

注重自上而下，微服務注重自下而上

SOA 架構在設計開始時會先定義好服務合同。它喜歡集中管理全部的服務，包括集中管理業務邏輯，數據，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法來集中管理服務。SOA 架構一般會預先把每一個模塊服務接口都定義好。模塊系統間的通信必須遵照這些接口，各服務是針對他們的調用者。

SOA 架構適用於 TO GAF 之類的架構方法論。

微服務則敏捷得多。只要用戶用獲得，就先把這個服務挖出來。而後針對性的，快速確認業務需求，快速開發迭代。

總結

微服務與 SOA 有不少相同之處。二者都屬於典型的、包含鬆耦合分佈式組件的系統結構。在圍繞着服務的概念建立架構這一方面，微服務提供了一種更清晰、定義更良好的方式。微服務的原則與敏捷軟件開發思想是高度一致的，而它與 SOA 原則的演化的目標也是相同的，則減小傳統的企業服務總線開發的高複雜性。二者之間最關鍵的區別在於，微服務專一於以自治的方式產生價值。可是兩種架構背後的意圖是不一樣的：SOA 嘗試將應用集成，通常採用中央管理模式來確保各應用可以交互運做。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。

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

微服務並非一種新思想的方法。它更像是一種思想的精煉，一種 SOA 的精細化演進，而且更好地利用了先進的技術以解決問題，例如容器與自動化等。因此對於咱們去選擇服務技術框架時，並非非黑即白，而是針對 SOA、MSA 兩種架構設計同時要考慮到兼容性，對於現有平臺狀況架構設計，退則守 SOA，進則攻 MSA，階段性選擇適合的。