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

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

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

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

第一階段：完全的點對點集成

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

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

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

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

第二階段：類似接口平臺或集成平臺

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

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

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

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

第三階段：能力開放和OpenAPI平臺

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

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

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

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

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