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

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

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

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

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

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

再好點就是定義了接口標準，比如全部走標準的WS服務接口進行集成，或者根據不同的場景定義了2到3種可選的集成方式。在這種情況下接口本身做到標準化和規范化，但是存在的主要問題還是接口本身的管控和治理，即沒有一個統一的管控和治理中心，能夠實現對企業內部所有的接口統一的接入，開通，授權，日志監控，問題排查等統一的監控和管控。

點對點集成下，接口很難復用，完全是有一個接口需求就做一個接口，造成大量重復開發和聯調工作量。

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

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

發展到第二階段，當前談論比較多的就是接口平臺或集成平臺。在這個階段一個最大的轉變就是原來的點對點集成模式轉變為了基于接口平臺的總線Hub式集成模式。所有的業務系統間接口都不直接交互，而是都直接注冊和接入到集成平臺，然后再由集成平臺發布一個統一的接口服務地址供外部業務系統調用。

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

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

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

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

能力開放和OpenAPI平臺在互聯網談的比較多，但是這也將是企業內部集成發展的一個必然趨勢，不僅僅是企業內部業務系統能力超對外的開放，比如電商，B2B等。其次也是企業內部業務系統間的能力開放。

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

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

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

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