引言

　　應用集成技術是市場上被廣泛使用的，也是充斥著術語和概念的一個技術領域。集成平臺、消息引擎、消息中間件、集成引擎、集成中間件、企業服務總線(ESB)、API網關、API管理…...很多概念與名詞。到底它們是什么意思?有什么區別?哪種技術適合解決哪種集成問題?

　　業務集成的需求和技術的演進是緊隨業務系統的軟件架構發展而發展的。通過小結軟件架構的發展，我們更容易梳理業務集成技術的演進、更容易看清楚各種集成架構的優勢和未來發展方向。

軟件架構發展簡史

　　01大型機架構：上世紀60-70年代。

　　大型機負責數據存儲、業務邏輯處理、數據展現等所有工作;客戶端只是一個終端，基本上就是鍵盤加上顯示器，負責輸入、輸出。大型機架構的優勢是簡單，但顯然可擴展性很差。

　　在大型機時代，幾乎沒有集成的需求。

　　02客戶端/服務器(C/S)架構：上世紀80年代到90年代。

　　服務器負責數據存儲和處理，以及服務器端端業務邏輯處理;客戶端(PC)負責客戶端邏輯處理、數據驗證、數據展現等工作。

　　客戶端(PC)分擔了很多工作，且數量眾多，因此它是一個分布式架構，可擴展性提升。但維護客戶端應用，例如升級等帶來了很大的管理維護成本。現在很多企業核心應用，例如ERP、HIS都是當時在這個架構下開發出來的，基本都是單體架構應用，業務邏輯間耦合度非常高。應用之間需要做業務的共享交換，主要通過點對點方式集成，也催生了集成技術，尤其是以消息交換為基礎的、以消息隊列技術為載體的集成方式。在這個時期，HL7組織開發了HL7 V2.x的醫療消息交換標準。

　　03三層架構：上世紀90年代中后期至今。

　　三層架構是展現層(用戶界面)、應用層(業務邏輯)和數據層(數據)三層架構。

　　這里的三層架構不僅指軟件功能的層次，而且指軟件運行的基礎架構的層次。由于在軟件功能和基礎架構上的分層和分布式設計，三層架構應用通常有很好的可擴展性和可維護性，雖然仍是單體架構應用，但它降低了業務邏輯的耦合度和基礎架構層次間的耦合度。另一方面，三層架構讓整體復雜程度上升了。分層架構和不斷涌現的技術實現，如.net、java、EJB…...使這些應用間的互相調用變得越來越復雜了，接口引擎或集成引擎應運而生，并在這個時期發展壯大起來。它們要解決這么多技術平臺的連接問題，適配器是主要手段。

　　04面向服務架構(SOA)：上世紀90年代末期至今。

　　前面的所有架構，基本都是單體架構模式 – 也就是孤島模式，業務耦合度高而難以拆分，代碼復用性低。不同應用中有大量功能重復的業務邏輯代碼和數據，例如醫療行業的患者管理，幾乎每個科室系統都有。這不但造成了需要同步的數據越來越多，更造成了數據互相沖突、運行效率降低、運行成本增加。代碼跨業務、跨語言、跨平臺復用成為快速滿足業務發展的需求與趨勢。以服務的方式封裝和復用軟件組件，然后可以敏捷地重新組織這些服務快速形成新的應用，SOA帶來了軟件架構上的革命。

　　每個服務都封裝有數據和邏輯(代碼)，以提供獨立的功能，服務之間高度松耦合。而采用XML作為數據格式、以WSDL標準描述服務、以SOAP協議作為交互方式，面向服務架構使不同技術棧的差異對服務透明，使服務在任何技術平臺上都可以使用。

　　隨著SOA架構的逐步采納，企業環境里有了越來越多的服務，企業服務總線(ESB)發展起來。它是一個中心化的軟件組件平臺，將企業環境中的服務注冊在總線上，并協同這些服務。ESB通常借助消息引擎、業務流程引擎、數據轉換引擎，執行服務路由、服務協同和服務間的數據結構轉換。

　　更近一步，先進的ESB還融合了接口引擎的技術，有能力將非SOA架構的應用接口封裝為服務并注冊到總線，使其可以和其它服務一樣被調用和協同。這些恰恰都是集成的目的，因此ESB成為一個重要的集成技術。

　　HL7在此期間，也推出了基于參考信息模型(RIM)的HL7 CDA臨床文檔標準用于文檔交換和HL7 V3消息標準用于消息交換，它們都是基于XML的。IHE也推出了基于SOA架構的業務協同服務標準。

　　ESB中心化的部署模式意味著低維護成本和高一致性，但敏捷性不夠。

　　05微服務架構(MSA)：2010年代開始至今。

　　微服務架構類似SOA，強調業務封裝和復用、業務解耦，往往和SOA發生混淆。但今天的業務環境已經和10多年前不可同日而語了：

　　業務迭代進化速度上，越來越快;

　　業務范圍上，傳統的企業內部服務的圍墻被突破了，越來越多的業務需要直接和上下游供應鏈打通，服務延伸到企業之外，直接面向客戶。例如以前患者只能去醫療機構看病，醫療機構也只有患者的院中數據，現在不但有互聯網醫院，醫院也需要院前、院后的患者數據和例如基因測序公司來的組學數據來支撐精準醫學;

　　業務量上，隨著傳統業務圍墻的打破，業務量越來越大，例如互聯網醫院和醫療物聯網帶來了大量的業務和數據。傳統可擴展性已經難于滿足，需要提供更靈活的、更細顆粒度的業務彈性;

　　部署模式上，云部署、容器化部署越來越主流。

　　而SOA架構技術上很重：復雜啰嗦的XML、沉重的SOAP協議、中心化的ESB架構，在當今追求敏捷性的今天顯得力不從心，甚至從“賦能者”變成了“拖累者”。

　　微服務架構站在SOA的肩膀上，并且具有如下特點：

　　輕巧的JSON、輕量化的Restful API幫助微服務架構獲得更好的性能，值得注意的是，API不等于微服務，API有可能是單體架構的API;

　　不同于嚴格分工、各司其職的的需求分析-設計-開發-測試-部署的瀑布模式(Waterfall)，微服務架構允許團隊合作的持續開發、持續部署模式(CI/CD)，可以更快的響應業務需求，具有更好的敏捷性;

　　而云原生、容器化的特性又幫助微服務架構獲得了去中心、高度的伸縮性和適應互聯網時代的快速迭代能力;

　　重新組合微服務可以快速構建新的應用、滿足新的業務;

　　適合打造軟件即服務(SaaS)類型的應用。

　　因此越來越多的企業采用微服務架構戰略支撐他們業務創新和數字化轉型。HL7 在2014年推出了采用微服務架構的FHIR標準，并參考持續開發持續部署的方式，以成熟度模型為依據不斷產生、優化FHIR資源和API。

　　微服務架構構建了一個跨業務域的、跨企業的、去中心的或多中心的架構，其中的API提供分子級的服務獨立性， 快速增加、快速迭代、分布部署。不過，這讓API的發現、訪問、版本管理、安全管理、流量管理、測試等變得很復雜，例如應用訪問這么多不同服務端點的微服務，如果后臺微服務的端點改了怎么辦?如果微服務升級怎么辦?因此API網關應運而生。

　　API網關為API提供全生命周期的管理：

　　API的創建、發現與測試

　　API版本管理

　　API安全管理

　　協議和數據轉換管理

　　API流量管理

　　API統計分析

　　API管理器在API網關基礎上提供開發、管理、運維門戶， 進而成為基于API集成的集成架構。它不需要中心化的消息引擎或服務總線，本質上是一個去中心化、應用于更緊密業務集成度的互操作方式。

　　(未完待續)

　　作者簡介

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