首 頁從軟件架構發展談業務集成技術演進與展望（下）
引言
應用集成技術是市場上被廣泛使用的，也是充斥著術語和概念的一個技術領域。集成平臺、消息引擎、消息中間件、集成引擎、集成中間件、企業服務總線(ESB)、API網關、API管理… ...很多概念與名詞。到底它們是什么意思?有什么區別?哪種技術適合解決哪種集成問題?
業務集成的需求和技術的演進是緊隨業務系統的軟件架構發展而發展的。通過小結軟件架構的發展，我們更容易梳理業務集成技術的演進、更容易看清楚各種集成架構的優勢和未來發展方向。
從軟件架構發展談業務集成技術演進與展望(上)
業務集成范式和特點
至此，我們現在在市場上常見的集成相關術語都全了。雖然各個廠商使用不同的名詞，但可以大致梳理一下：
消息隊列=消息引擎=消息中間件
API網關=API管理器
接口引擎=集成引擎=集成中間件
而集成平臺是對于使用各種架構作為應用集成產品的統稱。
同時，從上面的分析也可以看到常見的集成范式(套路)：
點對點：
點對點集成不需要任何特定的技術和數據規范，由被集成的雙方確定接口方式并開發實現。
消息交換：
消息交換基于消息引擎，應用在低業務集成度的跨數據管理域的業務系統間。在醫療行業通常消息是基于臨床事件的，描述臨床事件的上下文，并在臨床事件發生時通過消息引擎路由給消息接收方。典型的醫療行業消息交換標準就是HL7 的V2和V3消息。
文檔交換：
在醫療行業，有別于基于臨床事件的消息，文檔是階段性、小結性的完整醫療信息匯總。它也是應用在低業務集成度的跨數據管理域的業務環境中的，不過通常是不同的醫療機構間。
文檔交換可以通過消息引擎，也可以使用其他方式。
文檔標準常見的有HL7 CDA、C-CDA。
服務：
服務是封裝好并暴露出的一組內聚的應用功能。所以基于服務交互的互操作，需要雙方規范互操作的業務流程和角色。服務交互通常基于面向服務架構，通過服務總線交互。也應用在低業務集成度、跨數據管理域的業務環境中。
服務基于規范的業務流程和角色設定，而并不是所有的醫療流程都已經或能夠規范，因此服務交互的適用范圍有限。
最常見的國際服務標準就是IHE。
API：
有別于消息和文檔，API可以只傳輸必要的信息，而不是完整的上下文。與服務類似，但它不需要中心化的消息引擎或服務總線，本質上是一個去中心化，應用于更緊密業務集成度的互操作方式。
業務集成架構和特點
有哪些主要的應用集成架構呢?大致有這么幾種：
點對點集成
基于消息隊列(消息中間件)的集成
基于集成引擎的集成
基于ESB的集成
基于API網關的集成
下面這張圖顯示各種架構(除了點對點)的能力和它們之間的技術重疊情況。
01基于消息隊列/消息引擎/消息中間件的集成方案
消息引擎是非常有價值的基礎技術架構，很多應用都需要基于消息隊列處理，例如保證先進先出、異步處理、處理長時間運行的任務、削峰填谷等。因此很多集成場景也需要基于消息隊列和消息路由。這類方案適用于消息交換和文檔交換范式。
但消息引擎僅僅是集成需要的一個底層基礎技術架構，完整的集成方案應該整合好其它技術，例如解決連接問題的適配器、流程建模、數據轉換等，也就是說基于消息引擎的方案需要做很好的二次開發和封裝才能開發出一個適用的集成平臺或集成方案。
同時，我們看到市場上不少基于消息引擎的“半成品”集成方案。這類方案的特點是僅有消息引擎，通過消息路由規則來替代流程建模;同時要求各被集成的應用直接連接消息引擎來收發消息。這意味著：
高昂的開發成本：不論各業務系統本身是否已經提供有接口，它們都需要現場使用消息引擎提供的連接技術，如dll，開發出一個模塊用來連接消息引擎并收發消息、再和自己的應用做對接。
性能和穩定性風險：對于開發本身，要求來自不同技術棧的開發人員按消息引擎提供的技術棧進行開發，面臨很高的性能和穩定性風險。
能力缺失：顯然，沒有數據校驗能力、數據豐富與轉換能力、復雜的流程建模能力…
如果把集成平臺/集成方案看作一臺整車，那消息引擎只是一個零件。因此，這類“半成品”集成方案/產品是應該謹慎采用的。
02基于集成引擎的集成方案
這個架構通過適配器以其既有接口能力連接業務系統，因此對業務系統的改造要求很低。適配器有很多類型：
技術協議適配器可以連接各種技術協議，如TCP、HTTP、SOAP、REST、SQL
數據協議適配器支持各種數據協議，如HL7 V2、DICOM、X12
應用適配器可以連接各種應用，如SAP、IBM WebSphere MQ
語言適配器可以調用各種語言編寫的代碼，如Java、.net、python
集成引擎可以滿足多種互操作范式，包括消息交換和文檔交換。通常都具有：
消息引擎：用于基于消息路由和業務流程的交換，保證先進先出、異步處理等。但一般是內部使用，而不會直接暴露給集成系統直接使用。業務系統還是通過適配器連接。
業務流程引擎：創建和運行業務流程模型，實現業務流程自動化。相對路由規則，它提供更復雜流程處理的能力，例如循環處理、數據豐富(按流程從不同數據源補齊數據)。
規則引擎：建立并執行規則邏輯，給出邏輯輸出。通常規則用于消息路由和業務流程。
數據轉換引擎：建立數據在各種模型間的轉換關系，并使用它們對數據進行轉換。
集成引擎提供完整的工具集簡化了集成工作，它也是目前市場采用最多的架構方案。但其中心化的架構影響了其彈性，同時為避免成為單點故障和性能瓶頸，需要其提供高可用能力和良好的性能。
03基于ESB的集成方案
企業服務總線是一個中心化的架構，通過封裝、注冊、協同調用和監控服務，以面向服務架構應用在業務集成領域，且多數用于企業內部的應用集成。
很多ESB產品都具有集成引擎的核心能力，例如適配器、流程建模、數據轉換等。在集成架構上，基于ESB和基于集成引擎二者相似度非常高，甚至可能就是不同廠商叫的不同的名字，差異在于集成引擎不一定是基于SOA架構的。
ESB的缺點在于其中心化的架構，一來要避免成為瓶頸，需要其有強大的性能;二來其架構較重，應對微服務多少有些力不從心。因此通常用于業務內部的應用集成。
04基于API網關的集成方案
當前處在一個企業(包括醫院)拆業務圍墻的階段。API和API網關更能幫助企業突破傳統IT圍墻，構建全新的去中心化或多中心化的業務IT環境。
在企業生態中的微服務只需要關注業務實現，不用考慮統一認證與授權、安全傳輸等等問題，從而更從容應對跨業務邊界的應用場景、 更容易容器化和集群化。API網關會處理這些問題，而且還可以做數據轉換、路由、協議轉換等。API網關可以靈活部署，例如為不同的應用部署不同的API網關，從而也降低了對API網關本身高性能的要求。
微服務是一個去中心化的架構，但API網關是中心化的，雖然可以部署多個API網關，但其仍有淪為小ESB的風險。另外API網關對于現有的非服務化的IT資產無能為力。
展望
相信隨著軟件架構的發展，集成技術也會不斷發展。但立足于當前的技術，在集成架構和方案上，仍能看到一些趨勢。
01融合多種集成架構的集成平臺
從上面分析可見，面對當前多樣化的企業信息化環境，上述各種集成架構恐怕都無法單獨滿足所有集成需求。融合多種集成架構的集成平臺產品能夠更好地應對多種集成場景。
這樣的集成平臺可以梳理和集成現有業務，在保證業務穩定運行的前提下，逐步將現有不具備彈性的業務進行服務化或微服務化，從而安全、平穩地實現數字化轉型。
02數據與業務集成融合
數據的價值在于決策。隨著數字化轉型，企業IT架構需要更真實、更及時、更全面地表達現實世界(數據全貌)和更完整的流程(流程全貌)，將開放性分析能力納入數據和流程，提供基于實時數據的完整洞悉(insight)，并將預測結果甚至是決策結果直接反饋回業務流程。
當今負責數據全貌的是數據中心，承載業務流程的是ESB，它們是不同的產品和架構，業務流程的產生數據要定期同步到數據中心，也造成數據中心的及時性成為問題。
如果將數據中心比作數據存蓄的湖，集成平臺比作數據流動的江，那我們需要江湖一體的架構，以提高數據實時性和流程決策閉環能力。在數據層面，要能處理、容納各種模型的數據，支持數據編織(Data Fabric)。同時這個架構下要有強大的分析、決策能力，包括BI、自然語言處理、機器學習等。
03業務創新平臺
業務創新依賴現有業務基礎。使用ESB梳理現有企業信息、流程資產，擁抱新架構將數字資產微服務化，并通過創建新的服務、組合現有服務快速創新。融合行業互操作和數據標準，提供開箱即用的行業價值。擁有這些能力，將幫助現有架構演化為企業的業務創新平臺。
當然，這些已經不僅是集成架構的未來，而是整個數字化架構的未來。
相關閱讀：
作者簡介
喬鵬，InterSystems技術總監。自2004年加入InterSystems(系聯軟件)，歷任售前工程師、技術經理、技術總監等職務，精通公司旗下Caché數據庫，Ensemble集成平臺，HealthShare統一健康檔案，IRIS數據平臺等明星產品，對于數據庫、互操作性平臺、數據中臺、醫療相關標準以及集成平臺解決方案，有著深刻的理解和十多年的行業經驗，參與主導過百余家醫院或者區域平臺的信息化建設;同時他能夠對CDR、臨床決策支持、商業智能、機器學習等數據利用產品和方案有廣泛的認識和豐富的實踐經驗。
