先看“產業智能官”的結論（僅供參考）：工業互聯網PAAS架構中，傳統軟件應用雲化、集成，用ESB架構，包括CAX\MES\CRM\ERP；創新型應用APP採用微服務架構，並通過ESB與傳統軟件集成，包括工藝參數優化、質量檢測、預測性維護。

2018年是工業互聯網元年，微服務更是在工信部等部委發佈的企業上工業互聯網雲平臺相關文件中頻頻提到，“微服務”這一誕生於消費互聯網的技術術語逐漸被傳統工業人所熟知。

微服務為什麼就火了

微服務是近幾年技術社群討論很多的一種軟件架構方式，可以說是SOA的現代版本、時尚版本。微服務採用工程師們熟悉的RESTful接口，而不是笨重的WebService，也不需要一大堆昂貴的中間件。與此對比，ESB架構中SOA這幾年叫得不是那麼響亮了。為什麼呢？

第一，這幾年消費互聯網大火，大家忙著做移動APP或微信公眾號呢，哪有精力搞別的？

第二，大家這幾年忙著上雲平臺呢，要不也要折騰一下大數據、Hadoop吧，這才是緊跟潮流；

第三，這幾個傳統大廠商都不吃香了，都裁員呢，他們那一套還能信？現在要講互聯網化呢，最時髦的是去IOE呀

By Loïc Corbasson, created with en:OOo Draw (ODG source file available on request) – self-made, based on SOA Meta Model.jpg by David S. Linthicum, GFDL, https://commons.wikimedia.org/w/index.php?curid=3271972

總之，就是那一套不吃香了。就是在它吃香的時候，跟中小企業也沒多大關係。一是貴，產品貴，實施貴；二是中小企業也沒有那麼複雜的應用呀，SOA的投入產出不划算；第三，推動SOA需要打破企業內部壁壘（我部門原來有套應用，滿足自己的需求就行了。現在還要對你們提供服務接口？那接口出問題豈不是給自己找麻煩？），歷史證明這樣的事情都是吃力不討好的。

那微服務為什麼流行起來了呢？按理說它們都是讓軟件更加模塊化，使相互之間保持松耦合，從而優化系統架構呀。是的，可以說，它們在核心理念上沒有根本的不同。但為什麼現在講微服務，不講SOA了呢？我自己分析了幾個原因，跟大家分享：

第一，目前移動APP開發越來越重要。就算是html的客戶端，也大量採用了html5技術。在這種情況下，工程師們都習慣通過RESTful接口與後端通訊，甚至他們把職位也簡單的劃分為前端工程師和後端工程師。這導致REST服務成了剛需。原來的軟件可以拒絕提供Web Service接口，但現在的則不能不提供RESTful接口。人人都用，用量很大。這為微服務化提供了天然的契機。

第二，性能也越來越重要。為什麼？只要服務一慢，APP的用戶體驗就差呀。原來的SOA體系不怎麼提性能。

一方面是故意不說，你想WebService各種打包解包就要消耗多少CPU週期和網絡帶寬，性能肯定不是優勢。

二是如果性能不好，正好買大廠商的昂貴的服務器和lincense呀。但工程師們不吃這一套。明明很簡單就可以實現高性能，為什麼要搞那麼複雜？把微服務集群化、搞搞讀寫分離不就好了嗎？

第三，替換比利舊重要。SOA很多的應用場景都是在對已有應用的打通，比如你買了SAP的軟件，又買了另一家的軟件，還有以前投資定製開發的軟件。這些軟件都很貴，要像祖宗一樣供起來的，輕易不敢改動，改動成本很高。所以要儘量保留，要通過SOA的方式對接在一起。而搞微服務的那些人呢？他們的理念是“Design for replacement”，設計的每個微服務都要非常容易被拋棄、被替換。擁抱不斷變化的業務，快讀迭代開發。那些舊的包袱他們壓根不想搭理，天天想的是怎麼替掉它們算了。

所以，總結起來，就是企業IT技術的全盤互聯網化。只要是大的互聯網公司已經檢驗過的，就是好的，比如開源軟件、分佈式架構、雲、hadoop，以及最新的人工智能技術。

微服務架構的優點與缺點

1. 優點

• 每個服務足夠內聚，足夠小，代碼容易理解、開發效率提高
• 服務之間可以獨立部署，微服務架構讓持續部署成為可能;
• 每個服務可以各自進行x擴展和z擴展，而且，每個服務可以根據自己的需要部署到合適的硬件服務器上;
• 容易擴大開發團隊，可以針對每個服務(service)組件開發團隊;
• 提高容錯性(fault isolation)，一個服務的內存洩露並不會讓整個系統癱瘓;
• 系統不會被長期限制在某個技術棧上。

2. 缺點

《人月神話》中講到：沒有銀彈，意思是隻靠一把錘子是蓋不起摩天大樓的，要根據業務場景選擇設計思路和實現工具。我們看下為了換回上面提到的好處，我們付出(trade)了什麼?

• 開發人員要處理分佈式系統的複雜性;開發人員要設計服務之間的通信機制，對於需要多個後端服務的user case，要在沒有分佈式事務的情況下實現代碼非常困難;涉及多個服務直接的自動化測試也具備相當的挑戰性;
• 服務管理的複雜性，在生產環境中要管理多個不同的服務的實例，這意味著開發團隊需要全局統籌(PS：現在docker的出現適合解決這個問題)
• 應用微服務架構的時機如何把握?對於業務還沒有理清楚、業務數據和處理能力還沒有開始爆發式增長之前的創業公司，不需要考慮微服務架構模式，這時候最重要的是快速開發、快速部署、快速試錯。

ESB 所解決的核心問題：

1. 系統集成：站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步往往需要引入一些產品，比如技術規範、服務管理規範；

這一步解決的核心問題是【有序】

2. 系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實現業務的快速再生，目的：把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速複用；這一步解決的核心問題是【複用】

3. 業務的服務化：站在企業的角度，把企業職能抽象成可複用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。

這一步解決的核心問題是【高效】

微服務+ESB的融合

原來SOA架構中推行的那些東西：ESB、BPEL、CEP，這些還都有沒有用？或者是不是有替代者？

比如，ESB是解決服務消費者和服務提供者之間的點對點連接關係的。點對點連接當然不如大家都連到一個“總線”上，這樣就會實現物理位置、傳輸協議等多個方面對透明。這在微服務架構中有用嗎？

By Silver Spoon – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=8278078

首先說位置透明。如果採用RESTful協議，每個服務都有一個URL，比如：http://api.company.com/crm/orders，或者：http://crm.company.com/orders。這個時候，我們通過域名就能解析到具體的物理地址。所以說，有了URL，就能訪問到服務，為什麼還要去接到一個總線上？而且大家通常都是http，也不需要做協議轉換呀。互聯網已經提供了DNS這種基礎設施，把它用好就行了呀？

但實際上，具體的服務可能跑在很多服務器上，就像api.company.com這個域名下，可能有crm、oa等很多個系統的服務接口，不可能都在一臺物理服務器上。這個時候，就需要把實際的請求路由到真實的服務器上，起到這個作用的系統，我們把它叫做API網關，它跟基於http的負載均衡器工作起來差不多。

API網關大部分是對外的，也就是處於內部網絡跟外部網絡之間。比如，無數的APP客戶端都要通過API網關訪問內部的服務。因此，對它的安全性、健壯性也就有了很高的要求。此外，如果系統性能有問題，網關也需要知道是哪個服務慢了，這就需要性能監控、日誌等功能。因此，凡是搞微服務架構，幾乎肯定要用到API網關。

API網關與ESB有相似之處，但又有很大不同。基於DNS，API網關的存在幾乎是透明的，應用不需要明確的知道一箇中間件的存在，並跟它對接（實際在網絡傳輸層面，還是要做一些配置和優化的，比如，在服務側要允許來自API網關的大量訪問）。這就體現出了REST的優勢，因為它充分利用了互聯網已有的基礎設施。

所以，看上去我們不需要ESB了。ThoughtWorks的首席科學家Matin Fowler也不贊同在微服務架構中繼續用ESB。他的考慮是說沒有必要把一些邏輯集中在像ESB這樣的中介結構中，這樣與系統儘量解耦的初衷是背離的。

然而，事情似乎沒有那麼簡單。在工業互聯網中有許多需求ESB更容易滿足。

應用微服務架構設計時可能遇到的關鍵問題(內部服務通信、分佈式數據管理)通過ESB輕鬆解決。

服務的消費者和提供者之間，除了通過服務接口調用耦合以外，還有通過事件EVEN的方式更加高效。ESB中的事件機制對於做UI編程的人來說很熟悉，一個UI組件發出事件，對此事件感興趣的其他方可以獲取事件中的信息，並運行相應的邏輯。ESB的事件機制譬如，訂單處理發出事件，物流管理可以接受事件並處理。這是一種很乾淨的系統耦合方法。

這種耦合機制當然也可以用服務調用的等價方式來實現，比如物流微服務每隔一定的時間就去輪詢一訂單微服務。這仍然沒有改變模塊間的依賴關係，但效率上降低了。ESB事件通訊的處理效率更高。這也是ESB在系統架構中採用消息中間件（MOM）的一個重要場景。

那麼，需要發出事件的微服務，就需要跟一個消息中間件對接，發送消息進去；而其他的消費者，就從消息中間件中不斷地取信息。這個中間件的存在對於雙方都是知道的，這就有點像一個ESB了。

看一個ESB與微服務融合的做法：有了ESB消息，我們發現某些邏輯，如果從微服務裡抽取出來，似乎更好。就如訂單處理邏輯，可以由物流服務去監聽訂單服務，以便及時安排物流。也可以把它們之間解耦，讓ESB中的一個BPEL邏輯去調度。物流微服務只是被動的接受調用就可以了。表面上看，這只是把一段邏輯從物流微服務中剝離出來了。但剝離的好處，是更加容易維護這些流程邏輯（甚至可以通過圖形界面來維護）。

擔心ESB中的邏輯太集中，又成了大塊的軟件？由統一的部門維護導致協作成本太高？

我覺得這是個權衡利弊取捨的問題。把很多公共的、全局的功能放在ESB層面上去實現，會大大簡化微服務的實現，讓它們更加專注於處理好自己的事情。

再看一個ESB與微服務融合的做法：數據同步。

一個很重要的場景，就是微服務之間的數據複製。微服務之間是不共享數據庫的，實現最大程度的低耦合。但在實際中，一個微服務可能要訪問另一個微服務的部分數據的只讀版本，這樣可以大大提高性能。在這種情況下，微服務之間的數據複製就是一個必須要解決的問題，而且最好統一解決，不是由每個微服務各自去解決。藉助ESB的數據自動同步，就是其中一個解決方案。

我們理解，在自由主義者心中，我們不想要任何的“樞紐”，我們希望整個世界是分佈式，自由連接的，沒有一箇中央機構能夠控制所有的事情。

在實際工業情況下，我們還沒有辦法做到完全的分佈式，還必須依賴一些公共的基礎設施，比如如果幾個DNS的根服務器出了問題，全球的互聯網都會出問題。

公有云也把很多企業的IT設施都集中到了一些大型的機房，從而導致了成本的大幅度降低。

所以，集中是有它的好處的。基於ESB，可以更好的做服務的治理以及一些高級應用，比如可以做CEP（複雜事件處理）、可以支持事件Event，可以做全局的安全設計等。分佈固然有分佈的好處，但類似路由器這樣的樞紐，在架構中還是有其必要性的。

按照《失控》的理論，我們還有一個“湧現”和分層的理解角度。所有的微服務是基礎，而微服務之間的互動是湧現出來的特徵。就如大腦的意識是神經元的連接湧現出來的，以及網絡協議中TCP層的能力是由IP層的支持的。在上一個層次中，我們通常有能力做一些在下一層次做不到的事情，比如宏觀的流程，比如微服務的治理。

最後總結一下

微服務的整合，仍然需要ESB\BPEL\WORKFLOW\MQ\EVEN\CEP中間件。我們仍然可以從過去ESB中汲取一些有用的營養。

By Axelangeli – Own work, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=15958179

還是給這個工業PAAS一個名稱吧:MSB

參考資料：宮文學Richard-在微服務架構中，我們還需要ESB嗎? IT技術分享-主流架構模型-SOA 架構和

工業互聯網

產業智能官 AI-CPS

加入知識星球“產業智能研究院”：先進產業OT（工藝+自動化+機器人+新能源+精益）技術和新一代信息IT技術（雲計算+大數據+物聯網+區塊鏈+人工智能）深度融合，在場景中構建狀態感知-實時分析-自主決策-精準執行-學習提升的機器智能認知計算系統；實現產業轉型升級、DT驅動業務、價值創新創造的產業互聯生態鏈。

版權聲明：產業智能官（ID：AI-CPS）推薦的文章，除非確實無法確認，我們都會註明作者和來源。涉權煩請聯繫協商解決。聯繫、投稿郵箱：[email protected]

閱讀更多 產業智能官 的文章

關鍵字: 軟件 互聯網 架構