菜菜哥，我最近需要做一個項目，老大讓我用微服務的方式來做

那挺好呀，微服務現在的確很流行

我以前在別的公司都是以SOA的方式，SOA也是面向服務的方式呀

的確，微服務和SOA有相同之處

面向服務的架構（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	統一的協議標準
服務交付	手工交付	自動化快速交付
適用場景	企業內部	互聯網應用
管理	著重中央管理	著重分散管理
擴展	難擴展	單個服務很容易橫向擴展

完

關注后回復：“大禮包”和“福利”，領取驚喜

長按識別二維碼關注

在看點一下 創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的为什么我会了SOA，你们还要逼我学微服务？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。