引言

　　應(yīng)用集成技術(shù)是市場(chǎng)上被廣泛使用的，也是充斥著術(shù)語(yǔ)和概念的一個(gè)技術(shù)領(lǐng)域。集成平臺(tái)、消息引擎、消息中間件、集成引擎、集成中間件、企業(yè)服務(wù)總線(ESB)、API網(wǎng)關(guān)、API管理…...很多概念與名詞。到底它們是什么意思?有什么區(qū)別?哪種技術(shù)適合解決哪種集成問(wèn)題?

　　業(yè)務(wù)集成的需求和技術(shù)的演進(jìn)是緊隨業(yè)務(wù)系統(tǒng)的軟件架構(gòu)發(fā)展而發(fā)展的。通過(guò)小結(jié)軟件架構(gòu)的發(fā)展，我們更容易梳理業(yè)務(wù)集成技術(shù)的演進(jìn)、更容易看清楚各種集成架構(gòu)的優(yōu)勢(shì)和未來(lái)發(fā)展方向。

軟件架構(gòu)發(fā)展簡(jiǎn)史

　　01大型機(jī)架構(gòu)：上世紀(jì)60-70年代。

　　大型機(jī)負(fù)責(zé)數(shù)據(jù)存儲(chǔ)、業(yè)務(wù)邏輯處理、數(shù)據(jù)展現(xiàn)等所有工作;客戶端只是一個(gè)終端，基本上就是鍵盤(pán)加上顯示器，負(fù)責(zé)輸入、輸出。大型機(jī)架構(gòu)的優(yōu)勢(shì)是簡(jiǎn)單，但顯然可擴(kuò)展性很差。

　　在大型機(jī)時(shí)代，幾乎沒(méi)有集成的需求。

　　02客戶端/服務(wù)器(C/S)架構(gòu)：上世紀(jì)80年代到90年代。

　　服務(wù)器負(fù)責(zé)數(shù)據(jù)存儲(chǔ)和處理，以及服務(wù)器端端業(yè)務(wù)邏輯處理;客戶端(PC)負(fù)責(zé)客戶端邏輯處理、數(shù)據(jù)驗(yàn)證、數(shù)據(jù)展現(xiàn)等工作。

　　客戶端(PC)分擔(dān)了很多工作，且數(shù)量眾多，因此它是一個(gè)分布式架構(gòu)，可擴(kuò)展性提升。但維護(hù)客戶端應(yīng)用，例如升級(jí)等帶來(lái)了很大的管理維護(hù)成本。現(xiàn)在很多企業(yè)核心應(yīng)用，例如ERP、HIS都是當(dāng)時(shí)在這個(gè)架構(gòu)下開(kāi)發(fā)出來(lái)的，基本都是單體架構(gòu)應(yīng)用，業(yè)務(wù)邏輯間耦合度非常高。應(yīng)用之間需要做業(yè)務(wù)的共享交換，主要通過(guò)點(diǎn)對(duì)點(diǎn)方式集成，也催生了集成技術(shù)，尤其是以消息交換為基礎(chǔ)的、以消息隊(duì)列技術(shù)為載體的集成方式。在這個(gè)時(shí)期，HL7組織開(kāi)發(fā)了HL7 V2.x的醫(yī)療消息交換標(biāo)準(zhǔn)。

　　03三層架構(gòu)：上世紀(jì)90年代中后期至今。

　　三層架構(gòu)是展現(xiàn)層(用戶界面)、應(yīng)用層(業(yè)務(wù)邏輯)和數(shù)據(jù)層(數(shù)據(jù))三層架構(gòu)。

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

　　04面向服務(wù)架構(gòu)(SOA)：上世紀(jì)90年代末期至今。

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

　　每個(gè)服務(wù)都封裝有數(shù)據(jù)和邏輯(代碼)，以提供獨(dú)立的功能，服務(wù)之間高度松耦合。而采用XML作為數(shù)據(jù)格式、以WSDL標(biāo)準(zhǔn)描述服務(wù)、以SOAP協(xié)議作為交互方式，面向服務(wù)架構(gòu)使不同技術(shù)棧的差異對(duì)服務(wù)透明，使服務(wù)在任何技術(shù)平臺(tái)上都可以使用。

　　隨著SOA架構(gòu)的逐步采納，企業(yè)環(huán)境里有了越來(lái)越多的服務(wù)，企業(yè)服務(wù)總線(ESB)發(fā)展起來(lái)。它是一個(gè)中心化的軟件組件平臺(tái)，將企業(yè)環(huán)境中的服務(wù)注冊(cè)在總線上，并協(xié)同這些服務(wù)。ESB通常借助消息引擎、業(yè)務(wù)流程引擎、數(shù)據(jù)轉(zhuǎn)換引擎，執(zhí)行服務(wù)路由、服務(wù)協(xié)同和服務(wù)間的數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換。

　　更近一步，先進(jìn)的ESB還融合了接口引擎的技術(shù)，有能力將非SOA架構(gòu)的應(yīng)用接口封裝為服務(wù)并注冊(cè)到總線，使其可以和其它服務(wù)一樣被調(diào)用和協(xié)同。這些恰恰都是集成的目的，因此ESB成為一個(gè)重要的集成技術(shù)。

　　HL7在此期間，也推出了基于參考信息模型(RIM)的HL7 CDA臨床文檔標(biāo)準(zhǔn)用于文檔交換和HL7 V3消息標(biāo)準(zhǔn)用于消息交換，它們都是基于XML的。IHE也推出了基于SOA架構(gòu)的業(yè)務(wù)協(xié)同服務(wù)標(biāo)準(zhǔn)。

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

　　05微服務(wù)架構(gòu)(MSA)：2010年代開(kāi)始至今。

　　微服務(wù)架構(gòu)類似SOA，強(qiáng)調(diào)業(yè)務(wù)封裝和復(fù)用、業(yè)務(wù)解耦，往往和SOA發(fā)生混淆。但今天的業(yè)務(wù)環(huán)境已經(jīng)和10多年前不可同日而語(yǔ)了：

　　業(yè)務(wù)迭代進(jìn)化速度上，越來(lái)越快;

　　業(yè)務(wù)范圍上，傳統(tǒng)的企業(yè)內(nèi)部服務(wù)的圍墻被突破了，越來(lái)越多的業(yè)務(wù)需要直接和上下游供應(yīng)鏈打通，服務(wù)延伸到企業(yè)之外，直接面向客戶。例如以前患者只能去醫(yī)療機(jī)構(gòu)看病，醫(yī)療機(jī)構(gòu)也只有患者的院中數(shù)據(jù)，現(xiàn)在不但有互聯(lián)網(wǎng)醫(yī)院，醫(yī)院也需要院前、院后的患者數(shù)據(jù)和例如基因測(cè)序公司來(lái)的組學(xué)數(shù)據(jù)來(lái)支撐精準(zhǔn)醫(yī)學(xué);

　　業(yè)務(wù)量上，隨著傳統(tǒng)業(yè)務(wù)圍墻的打破，業(yè)務(wù)量越來(lái)越大，例如互聯(lián)網(wǎng)醫(yī)院和醫(yī)療物聯(lián)網(wǎng)帶來(lái)了大量的業(yè)務(wù)和數(shù)據(jù)。傳統(tǒng)可擴(kuò)展性已經(jīng)難于滿足，需要提供更靈活的、更細(xì)顆粒度的業(yè)務(wù)彈性;

　　部署模式上，云部署、容器化部署越來(lái)越主流。

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

　　微服務(wù)架構(gòu)站在SOA的肩膀上，并且具有如下特點(diǎn)：

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

　　不同于嚴(yán)格分工、各司其職的的需求分析-設(shè)計(jì)-開(kāi)發(fā)-測(cè)試-部署的瀑布模式(Waterfall)，微服務(wù)架構(gòu)允許團(tuán)隊(duì)合作的持續(xù)開(kāi)發(fā)、持續(xù)部署模式(CI/CD)，可以更快的響應(yīng)業(yè)務(wù)需求，具有更好的敏捷性;

　　而云原生、容器化的特性又幫助微服務(wù)架構(gòu)獲得了去中心、高度的伸縮性和適應(yīng)互聯(lián)網(wǎng)時(shí)代的快速迭代能力;

　　重新組合微服務(wù)可以快速構(gòu)建新的應(yīng)用、滿足新的業(yè)務(wù);

　　適合打造軟件即服務(wù)(SaaS)類型的應(yīng)用。

　　因此越來(lái)越多的企業(yè)采用微服務(wù)架構(gòu)戰(zhàn)略支撐他們業(yè)務(wù)創(chuàng)新和數(shù)字化轉(zhuǎn)型。HL7 在2014年推出了采用微服務(wù)架構(gòu)的FHIR標(biāo)準(zhǔn)，并參考持續(xù)開(kāi)發(fā)持續(xù)部署的方式，以成熟度模型為依據(jù)不斷產(chǎn)生、優(yōu)化FHIR資源和API。

　　微服務(wù)架構(gòu)構(gòu)建了一個(gè)跨業(yè)務(wù)域的、跨企業(yè)的、去中心的或多中心的架構(gòu)，其中的API提供分子級(jí)的服務(wù)獨(dú)立性， 快速增加、快速迭代、分布部署。不過(guò)，這讓API的發(fā)現(xiàn)、訪問(wèn)、版本管理、安全管理、流量管理、測(cè)試等變得很復(fù)雜，例如應(yīng)用訪問(wèn)這么多不同服務(wù)端點(diǎn)的微服務(wù)，如果后臺(tái)微服務(wù)的端點(diǎn)改了怎么辦?如果微服務(wù)升級(jí)怎么辦?因此API網(wǎng)關(guān)應(yīng)運(yùn)而生。

　　API網(wǎng)關(guān)為API提供全生命周期的管理：

　　API的創(chuàng)建、發(fā)現(xiàn)與測(cè)試

　　API版本管理

　　API安全管理

　　協(xié)議和數(shù)據(jù)轉(zhuǎn)換管理

　　API流量管理

　　API統(tǒng)計(jì)分析

　　API管理器在API網(wǎng)關(guān)基礎(chǔ)上提供開(kāi)發(fā)、管理、運(yùn)維門(mén)戶， 進(jìn)而成為基于API集成的集成架構(gòu)。它不需要中心化的消息引擎或服務(wù)總線，本質(zhì)上是一個(gè)去中心化、應(yīng)用于更緊密業(yè)務(wù)集成度的互操作方式。

　　(未完待續(xù))

　　作者簡(jiǎn)介

　　喬鵬，InterSystems技術(shù)總監(jiān)。自2004年加入InterSystems(系聯(lián)軟件)，歷任售前工程師、技術(shù)經(jīng)理、技術(shù)總監(jiān)等職務(wù)，精通公司旗下Caché數(shù)據(jù)庫(kù)，Ensemble集成平臺(tái)，HealthShare統(tǒng)一健康檔案，IRIS數(shù)據(jù)平臺(tái)等明星產(chǎn)品，對(duì)于數(shù)據(jù)庫(kù)、互操作性平臺(tái)、數(shù)據(jù)中臺(tái)、醫(yī)療相關(guān)標(biāo)準(zhǔn)以及集成平臺(tái)解決方案，有著深刻的理解和十多年的行業(yè)經(jīng)驗(yàn)，參與主導(dǎo)過(guò)百余家醫(yī)院或者區(qū)域平臺(tái)的信息化建設(shè);同時(shí)他能夠?qū)DR、臨床決策支持、商業(yè)智能、機(jī)器學(xué)習(xí)等數(shù)據(jù)利用產(chǎn)品和方案有廣泛的認(rèn)識(shí)和豐富的實(shí)踐經(jīng)驗(yàn)。