做了多年的SOA項(xiàng)目咨詢和實(shí)施，可以看到企業(yè)內(nèi)部業(yè)務(wù)系統(tǒng)間的集成主要還是三個(gè)階段，在傳統(tǒng)EAI和ESB總線階段，更多解決的是從點(diǎn)對(duì)點(diǎn)蜘蛛網(wǎng)集成到總線式集成的轉(zhuǎn)變;而到了當(dāng)前微服務(wù)架構(gòu)階段，更多的則是從總線集成到能力開放的思想過渡。

當(dāng)談集成的時(shí)候往往涉及到數(shù)據(jù)的交換和數(shù)據(jù)在多個(gè)業(yè)務(wù)系統(tǒng)中落地，這雖然降低了業(yè)務(wù)系統(tǒng)之間的耦合性，但是由于數(shù)據(jù)多點(diǎn)落地也帶來數(shù)據(jù)實(shí)時(shí)性和一致性方面的問題。而到了微服務(wù)階段，更加強(qiáng)調(diào)按需通過能力接口實(shí)時(shí)使用數(shù)據(jù)，而不是將數(shù)據(jù)通過接口同步到自己系統(tǒng)中。

因此集成的發(fā)展本身就是從接口集成到能力開放的一個(gè)發(fā)展過程。同時(shí)集成的思路也是從中心化總線式集成逐步到去中心化集成方式過渡。

企業(yè)應(yīng)用集成可以分為如下三個(gè)階段，下面分別進(jìn)行說明。

第一階段：完全的點(diǎn)對(duì)點(diǎn)集成

業(yè)務(wù)系統(tǒng)之間完成通過點(diǎn)到點(diǎn)的方式進(jìn)行集成，形成蜘蛛網(wǎng)式的集成架構(gòu)。在這個(gè)階段本身又存在幾個(gè)發(fā)展過程，最初級(jí)的時(shí)候就是接口完全不標(biāo)準(zhǔn)，各種實(shí)現(xiàn)技術(shù)，各種規(guī)格定義都存在，同時(shí)對(duì)于安全，日志等管控也很弱，導(dǎo)致最多的問題就是后續(xù)問題排查很麻煩。

再好點(diǎn)就是定義了接口標(biāo)準(zhǔn)，比如全部走標(biāo)準(zhǔn)的WS服務(wù)接口進(jìn)行集成，或者根據(jù)不同的場(chǎng)景定義了2到3種可選的集成方式。在這種情況下接口本身做到標(biāo)準(zhǔn)化和規(guī)范化，但是存在的主要問題還是接口本身的管控和治理，即沒有一個(gè)統(tǒng)一的管控和治理中心，能夠?qū)崿F(xiàn)對(duì)企業(yè)內(nèi)部所有的接口統(tǒng)一的接入，開通，授權(quán)，日志監(jiān)控，問題排查等統(tǒng)一的監(jiān)控和管控。

點(diǎn)對(duì)點(diǎn)集成下，接口很難復(fù)用，完全是有一個(gè)接口需求就做一個(gè)接口，造成大量重復(fù)開發(fā)和聯(lián)調(diào)工作量。

同時(shí)點(diǎn)對(duì)點(diǎn)集成商，本身技術(shù)也導(dǎo)致難以復(fù)用，比如一個(gè)JMS消息集成，一個(gè)大文件傳輸集成等，往往都需要各個(gè)業(yè)務(wù)系統(tǒng)去準(zhǔn)備實(shí)現(xiàn)相同的技術(shù)組件。這塊本身也是無謂的工作量增加和技術(shù)投入。

第二階段：類似接口平臺(tái)或集成平臺(tái)

發(fā)展到第二階段，當(dāng)前談?wù)摫容^多的就是接口平臺(tái)或集成平臺(tái)。在這個(gè)階段一個(gè)最大的轉(zhuǎn)變就是原來的點(diǎn)對(duì)點(diǎn)集成模式轉(zhuǎn)變?yōu)榱嘶诮涌谄脚_(tái)的總線Hub式集成模式。所有的業(yè)務(wù)系統(tǒng)間接口都不直接交互，而是都直接注冊(cè)和接入到集成平臺(tái)，然后再由集成平臺(tái)發(fā)布一個(gè)統(tǒng)一的接口服務(wù)地址供外部業(yè)務(wù)系統(tǒng)調(diào)用。

一個(gè)集成平臺(tái)基本會(huì)支撐傳統(tǒng)消息，數(shù)據(jù)，文件，WS服務(wù)等各種模式的集成能力。

集成平臺(tái)的建設(shè)和實(shí)施一般就會(huì)進(jìn)一步地約定接口技術(shù)標(biāo)準(zhǔn)和規(guī)范，約定接口開發(fā)標(biāo)準(zhǔn)，接口服務(wù)的接入標(biāo)準(zhǔn)和消費(fèi)標(biāo)準(zhǔn)，同時(shí)對(duì)于注冊(cè)接入的接口在安全，日志，異常監(jiān)控，路由，消息發(fā)布訂閱等多方面給予更強(qiáng)的能力支撐。這些都在統(tǒng)一的集成平臺(tái)完成，真正提升了SOA治理和管控能力。

在集成平臺(tái)階段往往又分兩種場(chǎng)景，一種是傳統(tǒng)的數(shù)據(jù)交換平臺(tái)，重點(diǎn)是數(shù)據(jù)交換，所有數(shù)據(jù)全部落地;一種是服務(wù)共享平臺(tái)，提倡的是服務(wù)接口實(shí)時(shí)消費(fèi)和使用，數(shù)據(jù)盡量不落地。當(dāng)前更多的是服務(wù)共享平臺(tái)模式，但是同時(shí)存在接口服務(wù)數(shù)據(jù)落地和不落地兩種消費(fèi)場(chǎng)景。

第三階段：能力開放和OpenAPI平臺(tái)

能力開放和OpenAPI平臺(tái)在互聯(lián)網(wǎng)談的比較多，但是這也將是企業(yè)內(nèi)部集成發(fā)展的一個(gè)必然趨勢(shì)，不僅僅是企業(yè)內(nèi)部業(yè)務(wù)系統(tǒng)能力超對(duì)外的開放，比如電商，B2B等。其次也是企業(yè)內(nèi)部業(yè)務(wù)系統(tǒng)間的能力開放。

第二階段往往是A超B提交接口需求，B系統(tǒng)考慮實(shí)現(xiàn)一個(gè)接口服務(wù)。而真正到了能力開放階段，更多的是以B系統(tǒng)為主去考慮究竟需要暴露和開放哪些能力出去。這是一個(gè)關(guān)鍵順序的變化。

集成平臺(tái)階段可以看到服務(wù)的注冊(cè)接入和服務(wù)的消費(fèi)兩個(gè)過程往往是高度耦合在一起的，有接口需求B系統(tǒng)才會(huì)做接口服務(wù)，A系統(tǒng)馬上就去消費(fèi)。而到了OpenAPI平臺(tái)階段服務(wù)接入和服務(wù)消費(fèi)兩個(gè)過程是松耦合的，即能力即使在沒有消費(fèi)方的情況下也可以先接入并發(fā)布到能力庫，而各業(yè)務(wù)系統(tǒng)隨時(shí)也可查看服務(wù)目錄庫和服務(wù)市場(chǎng)發(fā)起服務(wù)訂購請(qǐng)求和消費(fèi)。

在OpenAPI平臺(tái)階段更加強(qiáng)調(diào)了以業(yè)務(wù)系統(tǒng)為主的能力開放。同時(shí)也更加強(qiáng)調(diào)了各個(gè)業(yè)務(wù)系統(tǒng)基于OpenAPI平臺(tái)的自服務(wù)流程，即整個(gè)過程里面并不需要太多的集成商工作參與，所有需要的標(biāo)準(zhǔn)和規(guī)約也都全部固化到了類似服務(wù)接入，服務(wù)訂購，服務(wù)開通等自服務(wù)流程中。

傳統(tǒng)集成平臺(tái)更多的是SOAP WS，Rest，JMS消息各種方式并存，而到了OpenAPI平臺(tái)由于是以能力開放和發(fā)布為主，基本可以全部統(tǒng)一為輕量的Rest服務(wù)接口服務(wù)模式。