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

無論是SOA還是微服務架構，都是系統發展到一定程度衍生而出的一種解決方案，都是為了解決系統存在的弊端而產生的架構方案。當系統一開始採用集中化部署的時候，隨著系統模組越來越多，自然而然就產生了拆分的方案。

無論是SOA還是微服務架構都是根據業務進行拆分的結果，但是他們又有著很多不同。

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

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

整體上來說，SOA 的服務粒度要粗一些，而微服務的服務粒度要細一些。例如，對一個大型企業來說，“員工管理系統”就是一個 SOA 架構中的服務；而如果採用微服務架構，則“員工管理系統”會被拆分為更多的服務，比如“員工資訊管理”“員工考勤管理”“員工假期管理”和“員工福利管理”等更多服務。

至於微服務的粒度要到什麼程度，仁者見仁，智者見智，有的小夥伴說直到服務不能拆分為止，其實我認為這種想法是錯的，一個微服務的拆分粒度，還是要根據你的具體業務來劃分，根據你的依賴模組關係來劃分，不要盲目拆分成太多顆粒度小的服務，這樣在治理上會給團隊帶來很多困擾。舉一個簡單例子：員工管理系統中，如果考勤管理和假期管理之間業務關係非常密切，而且有很多操作需要事務性原子操作，你可以考慮將這兩個微服務合併。

無論是SOA還是微服務，每個獨立的系統都可以採用不同的程式語言來開發，只要對外提供的介面協議符合標準就可以。在開發方面，由於微服務會採用劃分粒度更小的策略，所以實際情況中服務的數量會比SOA架構方式要多很多，微服務的架構理念要求“快速交付”，相應地要求採取自動化測試、持續整合、自動化部署等敏捷開發相關的最佳實踐。如果沒有這些基礎能力支撐，微服務規模一旦變大（例如：超過 20個微服務），整體就難以達到快速交付的要求，這也是很多企業在實行微服務時踩過的一個明顯的坑，就是系統拆分為微服務後，部署的成本呈指數上升。

微服務適合那些需要快速交付，比較輕量級的網際網路應用。現代網際網路變化迅速，每個系統都需要快速嘗試，快速交付，這也是產生微服務架構的主要原因之一。由於每個服務都可以單獨部署，所以在那些大併發的情況下，更容易橫向擴充套件，就算是某個服務down掉，也不會影響其他的服務正常執行。而SOA由於ESB的存在，一旦ESB掛掉，會影響到所有系統正常執行。

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