傳統架構與微服務架構的區別
系統架構需要遵循的三個標準
- 提高敏捷性：及時響應業務需求，促進企業發展
- 提升用戶體驗：提升用戶體驗，減少用戶流失
- 降低成本：降低增加產品、客戶或業務方案的成本
傳統的開發模式
先來看看傳統的 WEB 開發方式，通過對比比較容易理解什麼是 微服務架構。和 微服務 相對應的，這種方式一般被稱爲 單體式開發（Monolithic）。
既所有的功能打包在一個 WAR 包裏，基本沒有外部依賴（除了容器），部署在一個 JavaEE 容器（Tomcat，JBoss，WebLogic）裏，包含了 DO/DAO，Service，UI 等所有邏輯。
優點
- 開發簡單，集中式管理
- 基本不會重複開發
- 功能都在本地，沒有分佈式的管理和調用消耗
缺點
- 效率低：開發都在同一個項目改代碼，相互等待，衝突不斷
- 維護難：代碼功功能耦合在一起，新人不知道何從下手
- 不靈活：構建時間長，任何小修改都要重構整個項目，耗時
- 穩定性差：一個微小的問題，都可能導致整個應用掛掉
- 擴展性不夠：無法滿足高併發下的業務需求
微服務架構
目的
有效的拆分應用，實現敏捷開發和部署
開發和交付中的伸縮立方
X軸： 運行多個負載均衡器之後的運行實例 Y軸： 將應用進一步分解爲微服務（分庫） Z軸： 大數據量時，將服務分區（分表）
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，階段性選擇適合的。