3什么是集成平臺?

　　集成平臺的基礎功能就是在不打破現有應用的邊界(不改造、少改造應用)的前提下，提供跨應用的業務流程整合和閉環。它當然要解決點對點集成的問題，因此適配各種接口方式、管理同步/異步通訊、數據格式轉換、術語注冊與轉換、處理通訊故障等，都是需要的能力。集成平臺，作為一個技術平臺，為應用集成工程師提供生產力工具。下面就展開說說集成平臺需要什么功能。

圖 典型的集成平臺功能架構

　　集成平臺要解決以下基礎能力：

　　● 互聯互通(打通應用的連接性);

　　● 數據建模和數據轉換;

　　● 流程建模和執行：協同、甚至再造應用間的業務流程，例如業務閉環。

　　另外，集成平臺在這些領域往往也被寄予眾望：

　　● 將舊有架構的應用現代化!-- SOA、EDA、DDD(主題域驅動設計)、MSA...

　　● 基于已有應用與數據資產的復合應用開發

　　3.1 集成平臺需要什么功能?

　　集成平臺并非是一種技術或一個方法論，而是整合后的一系列與應用集成相關的技術和特性的工具箱。

　　上面提到了集成平臺要解決應用的互聯互通、數據建模和數據轉換、流程建模和執行這些基礎需求。集成平臺通常包含這些基礎技術/特性以應對基礎需求：

　　連接適配器：連接適配器是可復用的，高度可配置的，對各種技術、協議、應用的連接組件。真實業務場景中，各個業務應用都可能提供了不同的技術接口、不同的數據協議， 因此一個豐富的適配器庫是保證對接口普適性連接能力的重要因素。

　　另外，適配器通常有確保連接、發送的能力，例如連接應用網絡異常時需要的重連、重發能力，而不是修改調用方應用使其具有這樣的能力。專業的集成平臺產品通常內嵌了行業互操作標準適配器，提供對于這些互操作標準協議的開箱即用的連接、校驗、轉換、路由的能力，從而極大降低開發和實施成本，提高方案的敏捷性。連接適配器也是集成平臺提供廣泛連接性的主要方式。

　　元數據管理：對上下文、消息進行建模和約束管理等能力。這是集成平臺對數據建模和數據轉換的能力支撐之一。因為上下文和消息的復雜性，多模型建模的能力尤為重要。

　　數據轉換引擎：用于對數據/消息模型進行轉換，這也是集成平臺對數據建模和數據轉換的能力支撐之一。數據轉換涉及多種數據模型的相互轉換，包括XML、分隔符分隔的字符串、JSON、對象模型等，圖形化的轉換能力尤為重要。

　　消息引擎/消息總線：用于建立消息路由規則，通過消息引擎在應用之間可靠地傳遞消息。路由規則是集成平臺提供的流程建模能力之一，用于簡單的流程場景。路由規則通常可以基于消息類型和消息內容進行設置，也就是需要它有拆包分析消息數據的能力。而消息引擎需要具有同步發送、異步發送、重發、編輯后重發等能力。要確保消息發送，還需要消息持久化的能力。

　　業務流程引擎：對業務流程進行建模，是集成平臺提供的重要的流程建模能力。業務流程引擎通常提供圖形化的流程建模工具、使用流程建模語言，從而提供比路由規則更靈活的流程模型，例如流程分支控制、延遲控制、流程異常捕獲與處理，提高流程自動化程度、更適合對業務流程的再造，例如將人工智能加入業務流程。

　　消息可視化追蹤和消息倉庫：將集成平臺上的跨應用傳遞的消息按業務組織、以可視化的方式展現每筆業務流程歷史(包括流程尚未結束的業務)的全貌，通常包括時間、請求消息內容、響應消息內容、狀態、錯誤與跟蹤信息等，方便集成工程師快速發現、定位和解決流程問題。實現消息追蹤，需要持久化消息，并且可以查詢檢索，例如通過SQL。而消息倉庫可以存儲消息，并提供更豐富的消息分析能力。

　　3.2 與集成平臺混淆的概念

　　對集成平臺特性的不同理解也造成了市面上對于集成平臺以偏概全或不準確的誤讀，例如集成平臺就是消息引擎、集成平臺就是ESB、集成平臺就是中間件...... 這里試著討論集成平臺功能的同時，將這些不同技術、概念與集成平臺區分開。

　　3.2.1. 中間件

　　中間件是很多產品的統稱，是處于源和目標中間的技術構件，因此稱為中間件。例如消息中間件(消息引擎、消息總線)、API中間件(API網關)、事務中間件(TPMs)、企業應用集成中間件(ESB)、Web應用中間件(web應用服務器)、數據流中間件……

　　和應用集成相關的，通常是消息中間件、企業應用集成中間件、API中間件，它們都是廣義集成平臺的能力組成部分。因此中間件不是集成平臺。

　　3.2.2. 消息引擎

　　消息引擎，往往也被稱之為消息中間件，是提供消息通道的中間件技術，可以應用在很多架構下，例如流式處理。因為其消息隊列管理能力，尤其是消息先進先出、消息路由等能力，通常集成平臺都會把消息引擎作為組件，用于消息處理順序控制和發送控制。

　　消息引擎本身只處理消息機制，它不主動向目標系統發送消息，即消息引擎并不解決連接性問題。集成平臺通常是通過適配器將消息主動地、按目標方要求的通訊協議，連接到并發送給目標方的。因此消息引擎單獨做不了應用集成的事情!

　　另外，市面上很多消息引擎產品，其中一些不支持消息持久化，無法保證消息的發送成功、無法重發;一些不支持消息校驗，無法檢索分析消息;另一些不支持發布/訂閱模式、或多個訂閱用戶。

　　3.2.3. 接口引擎

　　雖然廣義上，接口引擎具有更多能力，但狹義上，接口引擎是通過適配器解決接口連接性的技術，它的目標是使用應用/技術現有的接口能力，建立對其的連接，有可能是單向的、也可能是雙向的。因此，接口引擎只解決應用/技術接入的問題，它通常是集成平臺解決應用接入的技術組件。

　　3.2.4. 企業服務總線(ESB)

　　這里的服務是面向服務架構(SOA)語境下的服務。什么是服務，和前面提到的接口有什么區別?

　　接口是指基于某種協議的交互規范的實現，例如基于SOAP的接口;而在面向服務架構里，服務相對于單體應用架構而言的，它是按功能封裝的應用組件，可以被別的服務(應用組件)調用、因此可以復用，例如HIS的患者查詢服務。接口是服務實現方式，例如HIS的患者查詢服務SOAP接口，服務是業務概念、接口是技術概念。

　　企業服務總線是隨面向服務架構(SOA)發展起來的，用于封裝、注冊、協同調用和監控服務。SOA封裝的服務，實踐中最多的是Web服務：基于XML的數據模型、基于WSDL的服務定義、基于SOAP的服務接口。但理論上服務并不一定是SOAP服務，也可以是HTTP服務、TCP服務、文件服務……

　　ESB既然要協同調用服務，通常都具有集成平臺的核心能力，例如流程建模、數據轉換、適配器等。這是最容易和集成平臺混淆的概念，甚至一些大廠在不同場景下把其產品同時稱之為集成平臺或ESB，差異在于集成平臺不必要基于SOA架構、不必要封裝服務。

4集成方案與評價

　　應用集成項目的效果和實施有很大關系，且和底層采用的集成平臺技術相關。評價它的因素太多了，例如性能(消息吞吐量)、高可用、持續集成能力、建設成本......

　　而我們這里關注集成三要素和集成平臺基礎能力，這些集成的核心需求來考察集成方案。

圖 集成三要素與集成平臺基礎能力

　　即無論什么樣的方案，都需要留意是否關注在集成三要素上，是否解決了3個核心問題。為分析市場上常見的集成方案，我們把不基于集成平臺的常見集成方案也納入進來。

　　4.1 基于點對點接口

　　不依賴于集成平臺。應用需要大量的接口改造工作，復雜度隨被集成應用的數量呈指數增長。因為通過各自應用的改造，事件和完整的跨業務邊界流程被割裂在各個應用中，沒有地方可以一覽應用間的流程，可以說缺少流程和上下文梳理。雖然它目前仍是應用集成的主流方式，但其固有缺點使其很難持續部署在日益復雜的多應用業務場景下。

　　4.2 基于中間表的數據交換

　　使用中間表的方案是上面點對點接口的一種特例，其思路是通過SQL這一種接口單向打通應用：將需要傳遞的信息放在中間表里，數據用戶在業務流程節點上去中間表獲取信息。這種方式的流程自動化程度通常較低，適合的業務場景也比較有限。例如醫生站下達了檢驗醫囑，醫囑并不會推送給檢驗系統;患者拿著檢驗申請單到檢驗科，檢驗系統通過掃申請單二維碼獲取申請單編號，并在這時去醫生站開放到檢驗醫囑中間表獲取完整的醫囑信息。“事件”、“流程”是在患者人工參與下完成的：人工傳遞醫囑，將前段業務流程(醫生下達檢驗醫囑)和后段業務流程(檢驗科處理醫囑流程)關聯起來;“患者到達檢驗科窗口”是后段流程(檢驗科處理醫囑流程)觸發事件。

　　4.3 基于消息交換

　　“基于消息交換”是主流的集成方案，通常是利用消息路由作為“流程”的承載機制，通過消息路由規則解決集成三要素中的“流程”問題。而消息本身就要承載另外二個要素：事件和上下文了。因此對于消息標準的選擇是影響方案的關鍵因素之一。

　　這類方案要關注：

　　● 是否解決了應用連接問題。如果僅是一個消息引擎，而要求被集成的業務系統都需要被改造以連接到消息引擎去發送消息、輪詢消息引擎獲得自己需要接收的消息，那么這個方案的成本就非常高了!

　　● 是否有平臺統一的消息標準。每個業務系統對相同的業務對象 - 例如患者 - 要求不同的數據，如果在平臺上沒有做標準化，會在平臺上傳遞太多的消息類型，而且都是殘缺的信息，這些消息的管理成本太高、而消息的數據價值很低。作為上下文載體的消息，其對業務的抽象能力非常重要。

　　4.3.1 基于行業互操作消息標準

　　行業互操作消息標準對業務事件和上下文都有梳理。例如，在對事件的梳理和實現上：

　　HL7 V2的消息名稱代表了業務場景和業務事件。例如ADT_A01消息，ADT代表患者管理業務：入院(Admission)、出院(Discharge)、轉院(Transfer)，A01是患者入院事件。

　　HL7 V3也類似，但其結構層層封裝，遠比HL7 V2復雜。例如PRPA_IN101001UV01, PRPA是業務場景(PR：Practice)的患者管理域(PA：Patient Administration)，IN是交互(interaction)規范。而其內部定義了這個交互對應的事件：

　　而消息路由規則承載了“流程”：

　　目前在醫療互操作標準中，HL7組織發行的標準采納范圍最廣、影響范圍最大。HL7的歷史很長、標準眾多，如果我們要參考或采用其標準，必須要了解它發行的這些標準的用途和差異。國內市場上，所謂基于HL7 V3消息的方案不少，但大多數對HL7 V3標準的遵循質量并不高。

圖 HL7組織不同標準的采納度隨時間的變化及趨勢，棗紅色柱狀代表當前時間。

　　需要注意的是，行業的互操作標準對于應用集成來說非常重要，但其標準往往來自于對既往業務的總結。實際中總有超出現有標準覆蓋的業務，因此基于標準消息的方案也要考慮可擴展性。 例如 HL7 V2具有非常簡單和靈活的可擴展性，通常通過自定義的Z字段擴展;而HL7 V3由于其RIM方法論，相當難于擴展。這也是圖中大家看到的HL7 V3全球采納度遠不及V2的原因之一。

　　對于標準通過擴展也不能滿足的業務，就依靠底層的建模與轉換能力和方案的豐滿程度了。

　　4.3.2 自定義消息

　　當需求變化時，消息結構自主可控，這是用戶自定義消息的核心優勢。自定義消息很考驗經驗 - 需要對業務對象和流程抽象。如果不能覆蓋主要的用例，意味著消息結構可能需要經常變更，從而影響方案和接口的穩定性。

　　這個方案有一個比較流行的分支：

　　對消息體不建模、路由時不做拆包處理 - 任何的消息體內容都可以傳，從而避免因為需求變化而更新消息模型(schema)的工作。它不做消息校驗和基于消息內容的路由，僅根據消息類型、甚至定死的路由目標設置進行路由。方案最大好處是平臺建設方“無事一身輕”：平臺僅提供基于消息類型的路由機制;而各個應用需要改造以發送、接收、校驗和處理消息，工作量較大。

　　4.4 基于文檔交換

　　文檔通常是小結性的信息，發生在業務階段性節點上，例如“出院小結”發生在出院時，它不是細顆粒度“事件”。所以文檔交換并不是主流的集成方案，通常作為基于消息或服務的方案的補充。文檔結構是對“上下文”的定義，通常采用的有互聯互通文檔、HL7 CDA文檔或用戶自定義文檔。基于文檔交換的“流程”特別簡單，通常是：注冊、查詢、獲取。而應用需要具有使用文檔流程服務的能力。

　　4.5 基于服務總線(ESB)

　　將應用的功能在ESB上封裝為服務，并通過ESB來協同這些服務，就是基于服務總線的集成方案，它也是主流的集成方案。服務本身封裝了事件、上下文。ESB協調這些服務調用的流程，通常是通過業務流程建模能力實現的，它提供比消息路由規則更直觀、更靈活、更豐富的流程建模和管理能力，甚至可以被業務專家直接使用。

　　需要注意的是，有服務不等于用服務總線。例如一些方案中，集成廠商扔出一份“服務”文檔，要求各個應用廠商建設“服務接口”，但后臺并沒有ESB，不做服務注冊、數據轉換等，這其實是一種點對點方案。還有一些解決方案僅有注冊、發布固定服務的能力，例如自定義的SOAP服務。并不能注冊別的服務-例如TCP或HTTP的服務，或新的服務。這樣的方案連接能力不足。

　　4.5.1 基于行業互操作服務標準

　　醫療行業，IHE、互聯互通成熟度標準，都抽象和定義了服務標準，例如下面IHE常見的幾個服務的場景、角色和事件(事務)：

　　可能大家注意到了，上面沒提三要素之一的上下文。通常這些服務標準也規范了服務的請求和響應模型，例如IHE使用HL7 V3消息或FHIR消息;而互聯互通服務使用互聯互通消息標準。

　　基于服務總線的集成方案，通常需要具有持續的服務注冊與發布的能力。這也是評價方案的因素之一。

　　4.5.2 用戶自定義服務

　　由廠商基于經驗或項目需求定義服務，并使用ESB注冊、發布服務。對服務的規范能力和設計彈性是這類方案的關鍵。

　　另外，方案是否提供良好的連接能力，也是自定義服務方案的評價因素。

　　4.6 基于事件驅動(發布/訂閱)

　　繞了這么久，終于提到了開篇所說的FHIR訂閱范式。

　　事件驅動(EDA)是SOA的繼承者，其核心特征是通過事件生成能力和事件(及表達事件的上下文)的發布/訂閱，打破緊耦合的服務調用，以松耦合架構實現更靈活的服務調用流程。通過對事件的靈活定義和發布/訂閱機制，EDA應對業務變更只需要增加、調整訂閱關系，而無需修改固定的業務流程模型或消息路由規則。

　　基于事件驅動的集成方案現在越來越廣泛地被采用，為用戶提供了可持續集成的靈活架構，對集成廠商而言也降低了業務變化時的開發實施成本!

　　事件生成能力和靈活性、發布/訂閱便捷性是評價方案的關鍵。另外，事件驅動是以SOA為基礎的，它仍要基于ESB封裝服務和協同前道業務流程，而且對服務標準化程度和調用方式也提出了要求 - 例如應該盡可能使用異步服務調用方式，而不是同步調用。

　　FHIR訂閱基于W3的WebSub，提供FHIR的訂閱資源Subscription 和訂閱主題資源 SubscriptionTopic，本身就是一個API時代的事件驅動實現。

5 應用集成的發展

　　應用集成隨應用的軟件開發架構的進化而進化。FHIR 的6個互操作范式涵蓋了上面提到的消息、服務、文檔，另外三個—— API、訂閱和資源倉庫正體現了近年軟件架構上的發展。

　　5.1 基于API的應用集成

　　上面提到的應用集成方案基本都是中心化的，應對主流的單體架構應用。而軟件開發架構發展的一個趨勢是去中心化，例如微服務架構。

　　微服務架構是站在SOA肩膀之上的軟件架構，去中心理念、開發的敏捷性、部署的彈性、快速迭代能力讓其近年幾乎和各行各業的數字化轉型畫上了等號。微服務架構通過按主題域驅動設計(Domain-Driven Design) ，將業務進行細顆粒度的劃分，使用API打破了應用邊界。

　　既然微服務架構下，應用邊界都被突破了，基于應用邊界的應用集成顯然對微服務架構應用不再必要了，轉而需要對這些微服務進行集成。這涉及到微服務的發現與注冊、微服務的編排、微服務路由、微服務流控、微服務安全、微服務監控等諸多領域，架構復雜度相當高。

　　市面的API網關一定程度上可以應對“API”集成，通常有API發布、API協同調用、數據轉換、API轉換等能力，讓其能涵蓋API的調用”流程“，而對目前API的主要載體RESTful API的連接能力當然不在話下。同時，API網關也不必中心化部署，適合微服務軟件架構向外暴露服務。

　　在醫療行業，FHIR提供了一套支持資源CRUD的API，并且提供了用戶自定義API的擴展能力。雖然FHIR API不等于微服務，但它賦予了基于FHIR的應用間使用API進行互操作(集成)的能力，再借助其行業語義級的資源模型和事件定義能力，讓FHIR API成為行業中一種可行的互操作范式。

　　需要注意的是，API網關不是集成平臺，API集成嚴格上也不能叫做應用集成。只有在微服務架構的應用間，它才能充分發揮作用。而在多種架構應用并存的今天，僅靠API網關顯然解決不了應用集成的需求。在微服務架構應用全面、大規模部署前，應用集成仍需要集成平臺的支撐、API網關來補充。相信微服務架構未來會越來越重要，但并不會一統天下。

　　5.2 基于FHIR資源倉庫的應用集成

　　微服務架構中，服務可以非常彈性的部署、快速的迭代，但數據并不容易 - 高效地同步或復制數據是個難題。能否在微服務架構上，讓數據保持邏輯上的集中存儲以解決這個難題?

　　FHIR的第5個互操作范式 - 資源倉庫，基于這個思路，為基于FHIR API的應用集成帶來了一個有趣的分支。FHIR的資源倉庫為這種方案提供一個統一行業語義的、邏輯的數據中心，而且其中的數據是可以讀寫操作的。之所以說是邏輯數據中心，是因為不同FHIR資源可以存在多個FHIR倉庫中，互相之間通過資源引用 - 例如URL - 關聯在一起，而不必把所有資源數據物理上保存在一起。

　　FHIR資源模型提供上下文語義和事件定義，FHIR服務器提供統一的語義層和連接層，API網關以及FHIR生態中的CDS hooks、訂閱等提供流程層面的支持。而“生長”在FHIR資源倉庫上的應用，天生就是互聯互通的!

　　這個方案不知道有誰已經真的實施了，但的確開拓了具備行業天生互聯互通能力的應用開發架構的新思路。

　　當我們討論未來的時候，其實未來已來。數據編織、數字孿生、組裝式應用、超級自動化......已經出現在我們身邊，也深刻影響著應用架構和應用集成。對應用集成的發展，讓我們拭目以待!

　　相關鏈接：漫談應用集成的現在與未來(上)

　　作者簡介

　　喬鵬，InterSystems技術總監。自2004年加入InterSystems(系聯軟件)，歷任售前工程師、技術經理、技術總監等職務，精通公司旗下Caché數據庫，Ensemble集成平臺，HealthShare統一健康檔案，IRIS數據平臺等明星產品，對于數據庫、互操作性平臺、數據中臺、醫療相關標準以及集成平臺解決方案，有著深刻的理解和十多年的行業經驗，參與主導過百余家醫院或者區域平臺的信息化建設;同時他能夠對CDR、臨床決策支持、商業智能、機器學習等數據利用產品和方案有廣泛的認識和豐富的實踐經驗。