面向服務(wù)的架構(gòu)（SOA）是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）進行拆分，并通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進行定義的，它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進行交互。它是一種設(shè)計方法，其中包含多個服務(wù)，服務(wù)之間通過相互依賴最終提供一系列的功能。

微服務(wù)架構(gòu):其實和 SOA 架構(gòu)類似,微服務(wù)是在 SOA上做的升華，微服務(wù)架構(gòu)強調(diào)的一個重點是“業(yè)務(wù)需要徹底的組件化和服務(wù)化”，原有的單個業(yè)務(wù)系統(tǒng)會拆分為多個可以獨立開發(fā)、設(shè)計、運行的小應(yīng)用。這些小應(yīng)用之間通過服務(wù)完成交互和集成。

基于SOA架構(gòu)的系統(tǒng)，模塊在進行劃分的時候，顆粒度比較粗，比如一個會員系統(tǒng)SOA，可能包含會員基本信息管理，會員關(guān)系管理，會員資產(chǎn)管理等模塊，這些模塊統(tǒng)一規(guī)劃在會員管理服務(wù)，部署的時候也在相同的進程中。如果按照微服務(wù)的理念來做架構(gòu)設(shè)計的話，會員關(guān)系管理可能會是一個獨立部署的服務(wù)，其他模塊類似。是否需要獨立，架構(gòu)師需要根據(jù)這個模塊的業(yè)務(wù)來決定，需要考察這個模塊是否有獨立的必要性。

有的時候，一個系統(tǒng)的領(lǐng)域邊界劃分在SOA和微服務(wù)中可能相同。SOA和微服務(wù)本質(zhì)上有著相同的架構(gòu)思想，但是微服務(wù)根據(jù)業(yè)務(wù)形態(tài)又引入了組件化和領(lǐng)域建模的架構(gòu)理念，在多數(shù)的應(yīng)用場景中比SOA有著更易維護，擴展方便的優(yōu)點。

小c：沒太聽明白，SOA和微服務(wù)有什么相同和不同嗎？

小d：相同點和不同點都很多

無論是SOA還是微服務(wù)架構(gòu)，都是系統(tǒng)發(fā)展到一定程度衍生而出的一種解決方案，都是為了解決系統(tǒng)存在的弊端而產(chǎn)生的架構(gòu)方案。當(dāng)系統(tǒng)一開始采用集中化部署的時候，隨著系統(tǒng)模塊越來越多，自然而然就產(chǎn)生了拆分的方案。

無論是SOA還是微服務(wù)架構(gòu)都是根據(jù)業(yè)務(wù)進行拆分的結(jié)果，但是他們又有著很多不同。

服務(wù)通信

在SOA系統(tǒng)架構(gòu)中，服務(wù)之間的調(diào)用采用ESB（企業(yè)服務(wù)總線）來進行通信。ESB負(fù)責(zé)服務(wù)定義、服務(wù)路由、消息轉(zhuǎn)換、消息傳遞，總體上是重量級的實現(xiàn)。簡單來說ESB就是一根管道，用來連接各個服務(wù)節(jié)點。

微服務(wù)強調(diào)使用統(tǒng)一的協(xié)議和格式，例如，RESTful 協(xié)議、RPC 協(xié)議，無須 ESB 這樣的重量級實現(xiàn)。也有的系統(tǒng)為了統(tǒng)一管理微服務(wù)系統(tǒng)，會部署一個統(tǒng)一的網(wǎng)關(guān)系統(tǒng)，網(wǎng)關(guān)是系統(tǒng)的唯一入口。從面向?qū)ο笤O(shè)計的角度看，它與外觀模式類似。網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個客戶端提供一個定制的API。它可能還具有其它職責(zé)，如身份驗證、監(jiān)控、負(fù)載均衡、緩存、請求分片與管理、靜態(tài)響應(yīng)處理。網(wǎng)關(guān)方式的核心要點是，所有的客戶端和消費端都通過統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能，每個服務(wù)都需要去服務(wù)管理中心去主動注冊，這樣才能實現(xiàn)服務(wù)的自動發(fā)現(xiàn)。

服務(wù)劃分粒度

服務(wù)劃分粒度整體上來說，SOA 的服務(wù)粒度要粗一些，而微服務(wù)的服務(wù)粒度要細(xì)一些。例如，對一個大型企業(yè)來說，“員工管理系統(tǒng)”就是一個 SOA 架構(gòu)中的服務(wù)；而如果采用微服務(wù)架構(gòu)，則“員工管理系統(tǒng)”會被拆分為更多的服務(wù)，比如“員工信息管理”“員工考勤管理”“員工假期管理”和“員工福利管理”等更多服務(wù)。

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

SOA鼓勵組件的共享，而微服務(wù)嘗試通過“上下文邊界”來最小化共享。

服務(wù)交付

無論是SOA還是微服務(wù)，每個獨立的系統(tǒng)都可以采用不同的編程語言來開發(fā)，只要對外提供的接口協(xié)議符合標(biāo)準(zhǔn)就可以。在開發(fā)方面，由于微服務(wù)會采用劃分粒度更小的策略，所以實際情況中服務(wù)的數(shù)量會比SOA架構(gòu)方式要多很多，微服務(wù)的架構(gòu)理念要求“快速交付”，相應(yīng)地要求采取自動化測試、持續(xù)集成、自動化部署等敏捷開發(fā)相關(guān)的最佳實踐。如果沒有這些基礎(chǔ)能力支撐，微服務(wù)規(guī)模一旦變大（例如：超過 20個微服務(wù)），整體就難以達到快速交付的要求，這也是很多企業(yè)在實行微服務(wù)時踩過的一個明顯的坑，就是系統(tǒng)拆分為微服務(wù)后，部署的成本呈指數(shù)上升。

如果企業(yè)內(nèi)部快速交付的基礎(chǔ)設(shè)施比較薄弱，采用微服務(wù)架構(gòu)方式后期也許會遇到部署成本的問題。

適用場景

微服務(wù)適合那些需要快速交付，比較輕量級的互聯(lián)網(wǎng)應(yīng)用?，F(xiàn)代互聯(lián)網(wǎng)變化迅速，每個系統(tǒng)都需要快速嘗試，快速交付，這也是產(chǎn)生微服務(wù)架構(gòu)的主要原因之一。由于每個服務(wù)都可以單獨部署，所以在那些大并發(fā)的情況下，更容易橫向擴展，就算是某個服務(wù)down掉，也不會影響其他的服務(wù)正常運行。而SOA由于ESB的存在，一旦ESB掛掉，會影響到所有系統(tǒng)正常運行。

SOA相比較微服務(wù)，更適合那些訪問量較小，但是業(yè)務(wù)體系龐大，復(fù)雜的企業(yè)級系統(tǒng)。當(dāng)一個企業(yè)級的系統(tǒng)發(fā)展到一定程度，SOA會應(yīng)運而生，而且這個系統(tǒng)還會延續(xù)很長時間，期間還會采用不同的技術(shù)棧來開發(fā)不同的系統(tǒng)，這些系統(tǒng)會不斷集成進來，如果想要推倒重來或者進行大規(guī)模的優(yōu)化，人力物力上根本得不償失，所以這樣的系統(tǒng)只能以兼容的方式繼續(xù)，而承擔(dān)各個異構(gòu)系統(tǒng)通信的重要組件就是ESB。

小a：聽你這么一講，我好想明白了很多，下次出去面試就又多了一分把握

小b：每種技術(shù)都有它自己的適用場景，不要被微服務(wù)的吹噓迷失了方向

SOA和微服務(wù)本質(zhì)上是兩種不同的架構(gòu)設(shè)計理念，即使他們在服務(wù)這個概念和劃分思想上有交集。由于是兩種不同的架構(gòu)模式，所以在應(yīng)用上并不存在孰優(yōu)孰劣，只有是否合適之分。具體采用哪種架構(gòu)設(shè)計，最終還是要取決于你的應(yīng)用場景和目的。SOA更適合需要與許多其他應(yīng)用程序集成的大型復(fù)雜企業(yè)應(yīng)用程序環(huán)境。這就是說，小型應(yīng)用程序不適合SOA架構(gòu)，因為它們不需要消息中間件組件。而微服務(wù)架構(gòu)，在另一方面，是更適合于較小和良好的分割，基于Web的系統(tǒng)。如果你開發(fā)的是互聯(lián)網(wǎng)應(yīng)用，并且沒有歷史遺留問題，請優(yōu)先考慮采用微服務(wù)架構(gòu)。

版權(quán)說明：本文轉(zhuǎn)載于《架構(gòu)師修行之路》，并不代表北大青鳥立場，如有問題可以留言哦！