爲何有了SOA，咱們還用微服務？

面向服務的架構（SOA）是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）進行拆分，並經過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構建在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互。它是一種設計方法，其中包含多個服務，服務之間經過相互依賴最終提供一系列的功能。

微服務架構:其實和 SOA 架構相似,微服務是在 SOA上作的昇華，微服務架構強調的一個重點是「業務須要完全的組件化和服務化」，原有的單個業務系統會拆分爲多個能夠獨立開發、設計、運行的小應用。這些小應用之間經過服務完成交互和集成。

基於SOA架構的系統，模塊在進行劃分的時候，顆粒度比較粗，好比一個會員系統SOA，可能包含會員基本信息管理，會員關係管理，會員資產管理等模塊，這些模塊統一規劃在會員管理服務，部署的時候也在相同的進程中。若是按照微服務的理念來作架構設計的話，會員關係管理可能會是一個獨立部署的服務，其餘模塊相似。是否須要獨立，架構師須要根據這個模塊的業務來決定，須要考察這個模塊是否有獨立的必要性。

有的時候，一個系統的領域邊界劃分在SOA和微服務中可能相同。SOA和微服務本質上有着相同的架構思想，可是微服務根據業務形態又引入了組件化和領域建模的架構理念，在多數的應用場景中比SOA有着更易維護，擴展方便的優勢。

不管是SOA仍是微服務架構，都是系統發展到必定程度衍生而出的一種解決方案，都是爲了解決系統存在的弊端而產生的架構方案。當系統一開始採用集中化部署的時候，隨着系統模塊愈來愈多，天然而然就產生了拆分的方案。
不管是SOA仍是微服務架構都是根據業務進行拆分的結果，可是他們又有着不少不一樣。

服務通訊

在SOA系統架構中，服務之間的調用採用ESB（企業服務總線）來進行通訊。ESB負責服務定義、服務路由、消息轉換、消息傳遞，整體上是重量級的實現。簡單來講ESB就是一根管道，用來鏈接各個服務節點。

微服務強調使用統一的協議和格式，例如，RESTful 協議、RPC 協議，無須 ESB 這樣的重量級實現。也有的系統爲了統一管理微服務系統，會部署一個統一的網關係統，網關是系統的惟一入口。從面向對象設計的角度看，它與外觀模式相似。網關封裝了系統內部架構，爲每一個客戶端提供一個定製的API。它可能還具備其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。網關方式的核心要點是，全部的客戶端和消費端都經過統一的網關接入微服務，在網關層處理全部的非業務功能，每一個服務都須要去服務管理中心去主動註冊，這樣才能實現服務的自動發現。

服務劃分粒度

總體上來講，SOA 的服務粒度要粗一些，而微服務的服務粒度要細一些。例如，對一個大型企業來講，「員工管理系統」就是一個 SOA 架構中的服務；而若是採用微服務架構，則「員工管理系統」會被拆分爲更多的服務，好比「員工信息管理」「員工考勤管理」「員工假期管理」和「員工福利管理」等更多服務。
至於微服務的粒度要到什麼程度，仁者見仁，智者見智，有的小夥伴說直到服務不能拆分爲止，其實我認爲這種想法是錯的，一個微服務的拆分粒度，仍是要根據你的具體業務來劃分，根據你的依賴模塊關係來劃分，不要盲目拆分紅太多顆粒度小的服務，這樣在治理上會給團隊帶來不少困擾。舉一個簡單例子：員工管理系統中，若是考勤管理和假期管理之間業務關係很是密切，並且有不少操做須要事務性原子操做，你能夠考慮將這兩個微服務合併。

SOA鼓勵組件的共享，而微服務嘗試經過「上下文邊界」來最小化共享。

服務交付

不管是SOA仍是微服務，每一個獨立的系統均可以採用不一樣的編程語言來開發，只要對外提供的接口協議符合標準就能夠。在開發方面，因爲微服務會採用劃分粒度更小的策略，因此實際狀況中服務的數量會比SOA架構方式要多不少，微服務的架構理念要求「快速交付」，相應地要求採起自動化測試、持續集成、自動化部署等敏捷開發相關的最佳實踐。若是沒有這些基礎能力支撐，微服務規模一旦變大（例如：超過 20個微服務），總體就難以達到快速交付的要求，這也是不少企業在實行微服務時踩過的一個明顯的坑，就是系統拆分爲微服務後，部署的成本呈指數上升。

若是企業內部快速交付的基礎設施比較薄弱，採用微服務架構方式後期也許會遇到部署成本的問題。

適用場景

微服務適合那些須要快速交付，比較輕量級的互聯網應用。現代互聯網變化迅速，每一個系統都須要快速嘗試，快速交付，這也是產生微服務架構的主要緣由之一。因爲每一個服務均可以單獨部署，因此在那些大併發的狀況下，更容易橫向擴展，就算是某個服務down掉，也不會影響其餘的服務正常運行。而SOA因爲ESB的存在，一旦ESB掛掉，會影響到全部系統正常運行。

SOA相比較微服務，更適合那些訪問量較小，可是業務體系龐大，複雜的企業級系統。當一個企業級的系統發展到必定程度，SOA會應運而生，並且這個系統還會延續很長時間，期間還會採用不一樣的技術棧來開發不一樣的系統，這些系統會不斷集成進來，若是想要推倒重來或者進行大規模的優化，人力物力上根本得不償失，因此這樣的系統只能以兼容的方式繼續，而承擔各個異構系統通訊的重要組件就是ESB。

SOA和微服務本質上是兩種不一樣的架構設計理念，即便他們在服務這個概念和劃分思想上有交集。因爲是兩種不一樣的架構模式，因此在應用上並不存在孰優孰劣，只有是否合適之分。 具體採用哪一種架構設計，最終仍是要取決於你的應用場景和目的。SOA更適合須要與許多其餘應用程序集成的大型複雜企業應用程序環境。這就是說，小型應用程序不適合SOA架構，由於它們不須要消息中間件組件。而微服務架構，在另外一方面，是更適合於較小和良好的分割，基於Web的系統。若是你開發的是互聯網應用，而且沒有歷史遺留問題，請優先考慮採用微服務架構。

功能	SOA	微服務
系統劃分	大塊業務邏輯	單獨任務或小塊業務邏輯
系統通訊	ESB	統一的協議標準
服務交付	手工交付	自動化快速交付
適用場景	企業內部	互聯網應用
管理	着重中央管理	着重分散管理
擴展	難擴展	單個服務很容易橫向擴展

更多精彩文章

• 分佈式大併發系列
• 架構設計系列
• 趣學算法和數據結構系列
• 設計模式系列