菜菜哥,我最近需要做一個專案,老大讓我用微服務的方式來做

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

我以前在別的公司都是以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統一的協議標準
服務交付手工交付自動化快速交付
適用場景企業內部網際網路應用
管理著重中央管理著重分散管理
擴充套件難擴充套件單個服務很容易橫向擴充套件