SOA和微服務關系
SOA團隊 2020-03-16
關于SOA和微服務架構，網上有一篇文章談到微服務和SOA之間只差了一個ESB，可以把微服務當做去除了ESB的SOA。ESB是SOA架構中的中心總線，設計圖形應該是星形的，而微服務是去中心化的分布式軟件架構。
對于以上觀點筆者不是很認同，首先要看到SOA和微服務架構是一個層面的東西，而對于ESB和微服務網關又是一個層面的東西，一個談到是架構風格和方法，一個談的是實現工具或組件。因此把兩個層面的內容放到一起談不太對，下面通過對這兩個層面的對比分析來談一下SOA和微服務架構的聯系和區別：
■ 架構風格對比
SOA定義：SOA是一種架構方法，將傳統的單片式應用打破，分解為離散的、自治的業務服務，利用標準提升他們的互操作性，從而可以更好地共享、重用和組裝，快速構建復合的應用從而滿足業務需求的變化。
微服務架構定義：微服務是一種架構風格，一個大型復雜軟件應用由一個或多個松耦合微服務組成。微服務完全獨立自治，可以獨立部署，并通過輕量的HTTP型API進行交互。
從定義上看，對于SOA強調了兩個重點，一個是找到離散，自治，粗粒度和可重用的服務能力，其次是服務本身可以靈活的組合和編排適應業務變化。而微服務架構更多的是各個微服務模塊能夠獨立自治并在獨立的進程中運行，同時微服務之間能夠通過輕量的服務接口進行交互和協同。再展開來看如下：
● 對于服務本身的自治，離散，無狀態特征兩種架構模式都需要。
● SOA強調粗粒度，而微服務架構不會過分強調，由于模塊劃分細了，本身想粗粒度更加難。
● SOA強調可復用，而微服務架構不太強調，要考慮到在分層架構模型中UI到服務層也需要全部走服務接口
對于SOA找到服務只是第一步，強調服務復用性和粗粒度的原因也是后續這些服務要用到服務組合和編排里面去，而對于微服務架構沒有過分強調這點，服務是否涉及到能夠完全靈活編排并不是微服務架構考慮的重點，一考慮這個問題往往使這個微服務架構變重。
再回來看，微服務架構強調單體應用要打散為多個獨立自治，可以在獨立進程中運行和管理的微服務模塊，這個內容本身是屬于SOA思想在系統內的徹底內化以及組件化架構思想的推進，而傳統SOA更多的關注的是系統間的協同和服務重用 ，因此并沒有過分強調這點。
由于在微服務架構中沒有了服務組合編排這層的太多考慮，但是本身這個事情是要做的，因此很多是單獨定義了上層的業務協同或應用類的微服務模塊來完成。即在代碼中完成了服務組合的編排的事情，但是仍然可以看到要更好的完成這個工作，在底層微服務模塊基礎上最好能夠有提供領域服務能力的模塊來實現服務的組合和組裝。正式由于這個原因，個人認為領域服務設計思想在微服務架構中有重要的地位。
基于以上思考，從SOA和微服務架構的對比可以理解為：
微服務架構 = 80%的SOA服務架構思想 + 100%的組件化架構思想 + 80%的領域建模思想
正是由于這個原因絕對不能簡單的將微服務架構理解為簡單的做到組件化和數據庫拆分，使用了Http Rest接口，或者說使用了類似Spring Cloud等微服務框架就是微服務架構。
另外，SOA還有一個核心思想就是強調了縱向的豎井式建設模式變化為了分層構建模式，而分層的構建重點就是下面的組件層，再到服務層，再到上面的應用層。這也是在談SOA的時候講的平臺+應用構建模式，和在談微服務架構的時候講的中臺+前臺是一個道理，都在強調分層構建思路。
■ ESB和微服務網關對比
ESB服務總線定義：ESB總線從SOA架構風格發展而來，是傳統中間件技術與XML、Web服務等技術結合的產物。它是一種總線方式的連接中樞，以管理和簡化應用之間的集成拓撲結構，以廣為接受的開放標準為基礎來支持應用之間在消息、事件和服務級別上動態的互連互通，是一種在松散耦合的服務和應用之間標準的集成方式。
微服務網關定義：微服務網關或API網關本身是將微服務域中所有微服務需要對外暴露的API接口統一接口并對外開放，在外部進行接口訪問的時候實現路由轉發（服務代理），過濾（日志，安全，流控）等核心能力。
ESB服務總線可以理解為將傳統的單點集成轉化為總線式集成的核心部件，它是企業內部業務系統間業務協同和數據集成的高速公路，通過將所有的服務注冊和接入，來實現對所有服務運行的管理和監控，在這個過程中提供了服務注冊，適配器，協議轉換，消息格式轉換，消息集成，數據映射，簡單服務編排，安全認證，日志，流控等多種能力。
而對于微服務架構下一樣，仍然需要對微服務架構進行統一管理，只是在微服務架構下都是標準的Http Rest接口和AMQP消息接口了，對于傳統的服務適配和協議轉換等沒有了，同時對于服務的編排這種重的能力也不再需要。那么更多的將體現在對服務的管理能力上。這種管理能力包括了服務的統一注冊和發現，服務安全，服務集群和路由，服務限流，日志等能力上。
在談微服務架構的核心組件的時候，有文章會把服務注冊和發現，微服務網關，服務限流和容錯能力并列，而實際上我們完全可以將上述能力全部做為微服務網關應該具備的能力。這些能力有些是在引擎層面的，有些是在管控層面的，都必須要具備。
基于以上分析，我們可以這樣理解ESB和微服務網關：
微服務網關 = 傳統ESB + 去掉了復雜服務適配和協議轉換 +去掉了服務編排 + 提升了限流容錯能力
關于微服務架構是否就一定是去中心化的？一個重要的判斷依據就是看我們是否使用了微服務網關。從微服務網關的定義上可以看到微服務網關本身也是一種中心化，總線式的集成方式，這點和ESB是完全相同。
如果微服務間的接口僅僅局限在微服務域內部，那么完全可以只采用注冊中心即可，而沒有用到微服務網關，此時我們說這個微服務架構是去中心化的。但如果微服務域需要對外對外發布接口服務能力，此時就可能需要使用到微服務或API網關，這里又有兩種不同的情況：
1. 如果微服務網關只提供了類似服務注冊和發現能力，實際訪問仍然是點對點的服務調用，這種模式下還是可以理解為整個微服務架構是去中心化的。
2. 如果微服務網關提供了完全的對被調用系統的安全隔離，包括提供了對每次消息調用的日志追溯能力，那么這個微服務網關就是一個不可繞過的中心節點，此時整個微服務架構也就不再是去中心化的架構了。
可以看到，在傳統架構里面只有ESB服務總線，而在微服務架構里面除了中心化的微服務網關，還有去中心化的服務注冊中心，這個本身也是和傳統架構的一個重要區別。即：對于ESB總線的能力，在微服務架構里面可以選擇微服務網關和微服務注冊中心兩種替代方式。
一句話總結SOA和微服務架構的關系：微服務不再強調傳統SOA架構里面比較重的ESB企業服務總線，同時SOA的思想進入到單個業務系統內部實現真正的組件化。
遠行科技
遠行云商
