學習完整課程請移步 互聯網 Java 全棧工程師

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

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、MSA 兩種架構設計同時要考慮到兼容性，對于現有平臺情況架構設計，退則守 SOA，進則攻 MSA，階段性選擇適合的。