其實服務化架構已經可以解決大部分企業的需求了，那麼我們為什麼要研究微服務呢？先說說它們的區別；

• 首要目標不同：SOA首先要解決的是異構應用的服務化；微服務強調的是服務拆分儘可能小，最好是獨立的原子服務。
• 服務依賴：傳統的SOA服務，由於需要重用已有的資產，存在大量的服務間依賴；微服務的設計理念是服務自治、功能單一獨立，避免依賴其他服務產生耦合，耦合會帶來更高的複雜度。
• 服務規模：傳統SOA服務粒度比較大，多數會採用獎多個服務合併打成war包的方案，因此服務例項數比較有限；微服務強調儘可能拆分，同時很多服務會獨立部署，這將導致服務規模急劇膨脹，對服務治理和運維帶來新的挑戰。
• 架構差異：微服務化之後，服務數量的激增會引起架構質量屬性的編號，例如企業整合匯流排ESB（實匯流排）逐漸被P2P的虛擬匯流排替換；未來保證高效能、低延時，需要高效能的分散式服務框架保證微服務架構的實施。
• 服務治理：傳統基於SOA governance（治理）的靜態治理轉型為服務執行態微治理、實時生效。
• 敏捷繳費：服務由小研發團隊負責微服務設計、開發、測試、部署、線上治理、灰度釋出和下線，運維整個生命週期支撐，實現真正的DevOps。

總結：量變引起質變，這就是微服務架構和SOA服務化架構的最大差異。

• 微服務架構強調業務系統需要徹底的元件化和服務化，一個元件就是一個產品，可以獨立對外提供服務

• 微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排

• 微服務強調每個微服務都有自己獨立的執行空間，包括資料庫資源。

• 微服務架構本身來源於網際網路的思路，因此元件對外發布的服務強調了採用HTTP Rest API的方式來進行

• 微服務的切分粒度會更小

總結:微服務架構是 SOA 架構思想的一種擴充套件，更加強調服務個體的獨立性、拆分粒度更小。

MVC架構：當業務規模很小時，獎所有功能都部署在同一個程序中，通過雙機或者前置負載均衡器實現負載分流；此時，用於分離前後臺邏輯的MVC架構是關鍵。

RPC架構：當垂直應用越來越多，應用之間互動不可避免，將核心和公共業務抽取出來，作為獨立的服務，實現前後臺邏輯分離。此時，用於提高業務複用及拆分的RPC框架是關鍵。

SOA架構：隨著業務發展，服務數量越來越多，服務生命週期管控和執行態的治理成為瓶頸，此時用於提升服務質量的SOA服務治理是關鍵。

微服務架構：隨著敏捷開發、持續交付、DevOps理論的發展和實踐，以及基於Docker等輕量級容器(LXC)部署應用和服務的成熟，微服務架構開始流行，逐漸成為應用架構的未來演進方向。通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊敏捷繳費，應用的交付週期將縮短，運維成本也將大幅下降。