需求調(diào)研概述

　　最近在外調(diào)研，重點(diǎn)還是想談下企業(yè)對(duì)業(yè)務(wù)系統(tǒng)間的集成需求和ESB平臺(tái)本身的能力需要方面的一些思考和記錄，傳統(tǒng)我們談最多的還是ESB服務(wù)總線覆蓋了數(shù)據(jù)集成，業(yè)務(wù)集成和流程集成完整集成場(chǎng)景，同時(shí)提供了相應(yīng)的適配，協(xié)議轉(zhuǎn)換，文件傳輸?shù)确矫娴哪芰Α?/p>

　　對(duì)于多年實(shí)施ESB下來(lái)，最大的一個(gè)感受還是ESB服務(wù)總線首先要解決的仍然是業(yè)務(wù)系統(tǒng)間的集成問(wèn)題，其次才是解決服務(wù)復(fù)用，共享和能力開放層面的問(wèn)題。

　　這兩者在技術(shù)實(shí)現(xiàn)上有一個(gè)最大的區(qū)別體現(xiàn)在，談集成的時(shí)候往往數(shù)據(jù)落地，也不一定需要實(shí)時(shí)；而談服務(wù)和能力開放的時(shí)候則往往是數(shù)據(jù)不落地，實(shí)時(shí)發(fā)起調(diào)用。因此談集成的時(shí)候往往仍然無(wú)法很好地解決數(shù)據(jù)多點(diǎn)落地后在同一時(shí)點(diǎn)不一致的問(wèn)題，而談到數(shù)據(jù)不落地場(chǎng)景則會(huì)造成業(yè)務(wù)系統(tǒng)傳統(tǒng)開發(fā)方法巨大變化，在前面PaaS平臺(tái)的組件化開發(fā)架構(gòu)中我已經(jīng)多次提到，在這里就不再重復(fù)。

　　ESB服務(wù)總線提供統(tǒng)一的服務(wù)目錄庫(kù)，統(tǒng)一的服務(wù)接入，服務(wù)訂購(gòu)，服務(wù)鑒權(quán)和服務(wù)運(yùn)行監(jiān)控能力。其中一個(gè)核心就是服務(wù)運(yùn)行監(jiān)控，運(yùn)行日志和異常分析，告警和預(yù)警等。這是ESB平臺(tái)的一個(gè)關(guān)鍵需求，就是在接口服務(wù)運(yùn)行出現(xiàn)問(wèn)題的時(shí)候能夠快速地定位和診斷，而不是由于接入了ESB總線導(dǎo)致問(wèn)題分析定位更加困難。這是ESB平臺(tái)服務(wù)治理管控中一個(gè)最基本的需求。

　　大家都知道，ESB服務(wù)總線最適合的仍然是處理大并發(fā)，小數(shù)據(jù)量的業(yè)務(wù)服務(wù)實(shí)時(shí)調(diào)用，而對(duì)于大數(shù)據(jù)量的類似數(shù)據(jù)集成和傳輸類服務(wù)調(diào)用往往性能就下降明顯。對(duì)于大數(shù)據(jù)集成本身也不是ESB總線的強(qiáng)項(xiàng)，正是由于這個(gè)原因類似Oracle等產(chǎn)品推出了ODI解決方法，將WS和傳統(tǒng)ETL進(jìn)一步集成，實(shí)現(xiàn)大數(shù)據(jù)傳輸流和消息控制流的分離，很好的解決了這個(gè)問(wèn)題。如果不使用這種方式，可以借鑒使用的只有類似分頁(yè)，緩存，二進(jìn)制流傳輸?shù)确矫鎭?lái)解決大數(shù)據(jù)傳輸?shù)膯?wèn)題。當(dāng)然對(duì)于BI類數(shù)據(jù)集成和數(shù)據(jù)采集，則完全沒有必要走ESB服務(wù)總線來(lái)處理，單純的ESB服務(wù)總線往往并不具備傳統(tǒng)數(shù)據(jù)交換平臺(tái)的能力。

　　微服務(wù)架構(gòu)下涉及到微服務(wù)網(wǎng)關(guān)，當(dāng)然對(duì)于重型的ESB產(chǎn)品你也可以當(dāng)做微服務(wù)網(wǎng)關(guān)的來(lái)用，類似Oracle SOA套件也專門有一個(gè)API Gateway的模塊來(lái)實(shí)現(xiàn)Rest接口的接入和發(fā)布。對(duì)于Rest接口比SOAP接口更加輕量化，但是當(dāng)前最大的問(wèn)題仍然還是在接口契約本身的嚴(yán)謹(jǐn)性和后續(xù)的管理上，實(shí)際上在企業(yè)信息化建設(shè)中，如果涉及到眾多建設(shè)廠商間的溝通協(xié)同，采用Rest接口往往并不是一個(gè)好的選擇。

　　對(duì)于整個(gè)ESB服務(wù)總線，要實(shí)現(xiàn)所有的集成場(chǎng)景，考慮下整體規(guī)劃架構(gòu)仍然和我多年前的思考仍然是一致的，即ESB服務(wù)總線要管理整個(gè)的服務(wù)目錄，但是底層本身又包括了大數(shù)據(jù)傳輸組件，大文件傳輸組件，消息集成組件，而這些組件最終都又以服務(wù)集成的方式集成到了ESB服務(wù)總線上面。對(duì)于ESB服務(wù)總線本身則更多地承載實(shí)時(shí)業(yè)務(wù)服務(wù)的集成和服務(wù)暴露。

　　集成需求總結(jié)

　　下面對(duì)近期調(diào)研和訪談的企業(yè)對(duì)ESB總線和集成平臺(tái)需求的一個(gè)初步整理。實(shí)際上對(duì)于ESB服務(wù)總線究竟解決了企業(yè)哪些問(wèn)題，我在前面很多文章都有過(guò)系統(tǒng)性的專門描述，因此這篇為零散需求記錄。

　　在跨系統(tǒng)交互和集成上，企業(yè)最大的問(wèn)題是數(shù)據(jù)問(wèn)題，即數(shù)據(jù)不一致和數(shù)據(jù)延遲導(dǎo)致的跨系統(tǒng)業(yè)務(wù)協(xié)同上出現(xiàn)問(wèn)題。因此大部分企業(yè)會(huì)思考對(duì)基礎(chǔ)數(shù)據(jù)進(jìn)行統(tǒng)一管理并提供統(tǒng)一能力，即我們常說(shuō)的主數(shù)據(jù)管理，主數(shù)據(jù)管理可以明確地解決業(yè)務(wù)系統(tǒng)和問(wèn)題，也容易和業(yè)務(wù)部門和業(yè)務(wù)人員溝通為何要上MDM，而對(duì)于MDM實(shí)施本身涉及到集成，即還需要同時(shí)進(jìn)行接口服務(wù)的統(tǒng)一管理。

　　當(dāng)前還是大部分企業(yè)會(huì)思考對(duì)于MDM和ESB統(tǒng)一進(jìn)行建設(shè)，如上圖可以看到MDM+ESB作為整個(gè)應(yīng)用集成架構(gòu)規(guī)劃的雙核心。那么兩者究竟是什么關(guān)系？

　　對(duì)于主數(shù)據(jù)平臺(tái)來(lái)說(shuō)，本身是可以獨(dú)立建設(shè)的，即使沒有集成平臺(tái)也可以單獨(dú)建主數(shù)據(jù)。而對(duì)于SOA集成平臺(tái)，不僅僅是解決主數(shù)據(jù)相關(guān)接口集成問(wèn)題，而是解決整個(gè)信息化應(yīng)用系統(tǒng)間接口交互和集成

　　主數(shù)據(jù)平臺(tái)的建設(shè)，難點(diǎn)不在于系統(tǒng)，而是在于主數(shù)據(jù)系統(tǒng)的實(shí)施，而實(shí)施本身的難點(diǎn)本身又在于歷史數(shù)據(jù)的清理和初始化入庫(kù)。這個(gè)本身需要業(yè)務(wù)部門，包括相關(guān)的業(yè)務(wù)系統(tǒng)高度配合才可能完成。

　　當(dāng)前對(duì)于企業(yè)集成的需求，即使我們使用的是ESB服務(wù)總線，但是仍然可以看到集成的需求包括了服務(wù)集成和數(shù)據(jù)集成兩個(gè)部分，或者把ESB總線當(dāng)做數(shù)據(jù)總線來(lái)用，或者在集成平臺(tái)項(xiàng)目中會(huì)包括類似ETL的數(shù)據(jù)集成能力。大部分的企業(yè)集成，在第一階段仍然是解決數(shù)據(jù)集成問(wèn)題，而不是服務(wù)集成和應(yīng)用集成。

　　數(shù)據(jù)集成在前面很多文章講過(guò)，數(shù)據(jù)集成表示數(shù)據(jù)會(huì)在多個(gè)業(yè)務(wù)系統(tǒng)多點(diǎn)落地，這樣本身可以降低業(yè)務(wù)系統(tǒng)之間的耦合性，但是帶來(lái)的問(wèn)題是數(shù)據(jù)會(huì)存在不一致性和時(shí)延，那么這些問(wèn)題就必須有很好的管控機(jī)制和補(bǔ)償機(jī)制去處理，否則即使系統(tǒng)間集成了照樣影響到業(yè)務(wù)協(xié)同。

　　數(shù)據(jù)集成：通過(guò)接口服務(wù)或ETL進(jìn)行傳輸傳輸集成，數(shù)據(jù)會(huì)在多個(gè)業(yè)務(wù)系統(tǒng)落地服務(wù)集成：在業(yè)務(wù)場(chǎng)景需要協(xié)同的情況下，實(shí)時(shí)調(diào)用服務(wù)接口進(jìn)行數(shù)據(jù)獲取，數(shù)據(jù)不落地

　　服務(wù)集成的實(shí)時(shí)性最高，當(dāng)然對(duì)業(yè)務(wù)系統(tǒng)，集成平臺(tái)本身的可靠性，性能要求也更高，本身接口服務(wù)的調(diào)用并發(fā)量也會(huì)指數(shù)級(jí)增長(zhǎng)。因此并不是服務(wù)集成就一定比數(shù)據(jù)集成好，而是應(yīng)該實(shí)際問(wèn)題實(shí)際分析。

　　當(dāng)我們采用數(shù)據(jù)集成的時(shí)候，仍然存在兩種場(chǎng)景，即定時(shí)地進(jìn)行數(shù)據(jù)同步，還有一種就是實(shí)時(shí)的調(diào)用接口服務(wù)進(jìn)行數(shù)據(jù)導(dǎo)入，那么在我們實(shí)施的時(shí)候更加建議采用第二種折中方式。即既保證了數(shù)據(jù)同步的實(shí)時(shí)性，本身又降低了后續(xù)業(yè)務(wù)之間的耦合程度。

　　在交流的一些企業(yè)里面，我們經(jīng)常也會(huì)聽到說(shuō)原來(lái)已經(jīng)實(shí)施過(guò)ESB總線或類似的集成平臺(tái)，但是實(shí)施效果并不好，而這個(gè)實(shí)施效果不好注意體現(xiàn)在以下幾個(gè)方面。

　　1. 業(yè)務(wù)價(jià)值無(wú)法顯性化：ESB屬于技術(shù)平臺(tái)，導(dǎo)致ESB總線的業(yè)務(wù)價(jià)值很難顯性化，IT部門可能認(rèn)可平臺(tái)重要性，但是企業(yè)業(yè)務(wù)部門往往對(duì)平臺(tái)并沒有直觀的認(rèn)識(shí)。而沒有業(yè)務(wù)驅(qū)動(dòng)力的平臺(tái)建設(shè)本身又是難事。

　　2. 管控治理沒有跟上：對(duì)于ESB服務(wù)總線究竟是簡(jiǎn)單的買產(chǎn)品還是賣實(shí)施在我博客上也討論過(guò)多次，從乙方角度肯定是希望賣產(chǎn)品最簡(jiǎn)單，但是單純的賣產(chǎn)品，整個(gè)SOA實(shí)施方法論，SOA治理管控規(guī)范體系無(wú)法真正在企業(yè)落地。往往是乙方實(shí)施商一離場(chǎng)，甲方接口服務(wù)又恢復(fù)原樣，導(dǎo)致仍然出現(xiàn)接口管理混亂的情況。這個(gè)原因不是在于ESB總線產(chǎn)品問(wèn)題，更多的還是實(shí)施管控治理方面的問(wèn)題。

　　3. 技術(shù)平臺(tái)功能單一：前面已經(jīng)講過(guò)了企業(yè)的集成需求很多，有接口服務(wù)實(shí)時(shí)集成，也有數(shù)據(jù)集成，文件集成，ETL數(shù)據(jù)傳輸，還包括MDM主數(shù)據(jù)平臺(tái)的建設(shè)。一涉及到集成需求企業(yè)往往就認(rèn)為都是ESB總線能夠解決的問(wèn)題，但是實(shí)際上ESB總線很難解決上面所有問(wèn)題，而是應(yīng)該一個(gè)完整的整體解決方案才能夠解決。因此對(duì)于這點(diǎn)我們?cè)谧鯯OA項(xiàng)目實(shí)施的時(shí)候也需要和企業(yè)提前溝通清楚。

　　ESB總線平臺(tái)的建設(shè)，一個(gè)方面是選擇產(chǎn)品，但是更加重要的還是服務(wù)實(shí)施，服務(wù)管控治理規(guī)范流程的建立，而對(duì)于這方面遠(yuǎn)行科技本身經(jīng)過(guò)10多年的大平臺(tái)和大項(xiàng)目現(xiàn)場(chǎng)實(shí)施，我們?cè)谶@方面也是積累了豐富的現(xiàn)場(chǎng)實(shí)施和管控經(jīng)驗(yàn)，而這些才是確保SOA實(shí)施項(xiàng)目能夠成功的關(guān)鍵。

　　不同集成場(chǎng)景下的需求應(yīng)對(duì)

　　今天談下企業(yè)內(nèi)應(yīng)用系統(tǒng)間的集成需求，雖然我們前面談了很多的企業(yè)中臺(tái)建設(shè)，微服務(wù)架構(gòu)，基于DevOps的面向云原生的持續(xù)集成和持續(xù)交付解決方案，但是我們還是要看到，對(duì)于任何一個(gè)企業(yè)這個(gè)轉(zhuǎn)型過(guò)程都不可能一蹴而就，而是一個(gè)長(zhǎng)期逐步演進(jìn)的過(guò)程。那么對(duì)于這些已經(jīng)存在的遺留系統(tǒng)和遺留架構(gòu)，我們還是得支持各種場(chǎng)景的集成場(chǎng)景和集成需求。

　　首先看下對(duì)于企業(yè)內(nèi)部系統(tǒng)間已經(jīng)通過(guò)Web Service來(lái)實(shí)現(xiàn)的接口集成，不論是SOAP的WS服務(wù)接口，還是基于Http Rest Web Service服務(wù)接口，這些都是當(dāng)前主流的服務(wù)集成和服務(wù)發(fā)布方法。

　　也是我們常說(shuō)的采用ESB服務(wù)總線或API網(wǎng)關(guān)進(jìn)行的服務(wù)集成和服務(wù)能力開放。要注意對(duì)于ESB服務(wù)總線往往會(huì)同時(shí)具備了對(duì)Http Rest接口服務(wù)的適配和集成能力，但是當(dāng)前的API網(wǎng)關(guān)產(chǎn)品就很少再去兼容SOAP WS服務(wù)的。

　　對(duì)于才有ESB服務(wù)總線進(jìn)行服務(wù)集成的時(shí)候，我們前面已經(jīng)講過(guò)很多次，服務(wù)總線的優(yōu)點(diǎn)在于大并發(fā)，小報(bào)文，低時(shí)長(zhǎng)的服務(wù)訪問(wèn)和調(diào)用，對(duì)于這種情況往往可以達(dá)到很高的TPS性能值和服務(wù)訪問(wèn)吞吐量。而ESB服務(wù)總線最怕的就是長(zhǎng)耗時(shí)長(zhǎng)連接，大報(bào)文大數(shù)據(jù)量的服務(wù)調(diào)用。

　　長(zhǎng)耗時(shí)+大報(bào)文都會(huì)導(dǎo)致我們?cè)诜?wù)請(qǐng)求和解析報(bào)文，進(jìn)行序列化和反序列化的時(shí)候大量?jī)?nèi)存消耗。為了應(yīng)對(duì)這個(gè)問(wèn)題，可以看到我們有時(shí)候會(huì)采用一些分頁(yè)，數(shù)據(jù)報(bào)文壓縮等方式來(lái)提升性能，但是如果涉及到很大數(shù)據(jù)量的底層數(shù)據(jù)庫(kù)表間數(shù)據(jù)同步，即使我們做了上述處理仍然會(huì)造成很大的消耗。

　　因此對(duì)于這些大數(shù)據(jù)量集成還需要引入其它集成方式或工具。

　　大數(shù)據(jù)集成工具

　　即對(duì)于ESB服務(wù)總線來(lái)說(shuō)本身就不太適用于應(yīng)用系統(tǒng)間底層數(shù)據(jù)庫(kù)表間的大數(shù)據(jù)集成操作。這個(gè)更多的還是得通過(guò)ETL工具來(lái)解決，但是ETL工具如何和我們的WS服務(wù)做集成和協(xié)同，類似Oralce就給給出了ODI的解決方案來(lái)解決這個(gè)問(wèn)題。

　　即ODI=Web Serice + ELT數(shù)據(jù)集成

　　這個(gè)方案的特點(diǎn)就是數(shù)據(jù)請(qǐng)求和數(shù)據(jù)調(diào)度任務(wù)的發(fā)起不再是傳統(tǒng)ETL的定時(shí)方式，而是通過(guò)調(diào)用Web Service服務(wù)發(fā)起，而且在發(fā)起的時(shí)候這個(gè)服務(wù)本身還能夠輸入具體的參數(shù)信息，更加方便靈活。但是具體數(shù)據(jù)的傳遞仍然是走傳統(tǒng)的ETL方式進(jìn)行，減少了對(duì)這部分報(bào)文在ESB管道上傳輸帶來(lái)的性能壓力。

　　大文件集成工具

　　還有一個(gè)場(chǎng)景就是企業(yè)內(nèi)的文件傳輸和文件集成，這個(gè)也需要分場(chǎng)景，具體來(lái)說(shuō)如果僅僅是一個(gè)業(yè)務(wù)服務(wù)比如合同信息上傳服務(wù)涉及到的文件附件傳輸，而且這個(gè)文件傳輸我們希望做到實(shí)時(shí)觸發(fā)傳輸，那么我們可以使用類似ESB服務(wù)總線的FTP文件適配器來(lái)解決這個(gè)問(wèn)題。

　　但是如果我們面對(duì)的是大量文件的批處理和端到端傳輸，那么通過(guò)ESB總線就很難去解決這個(gè)問(wèn)題，特別是對(duì)于文件傳輸過(guò)程的端到端管理和監(jiān)控能力，ESB總線更加難以達(dá)到。

　　而面對(duì)這個(gè)場(chǎng)景，對(duì)于當(dāng)前的Oracle SOA套件體系給出的解決方案是MFT文件傳輸平臺(tái)，通過(guò)這個(gè)平臺(tái)來(lái)實(shí)現(xiàn)文件的端到端傳輸和管理，而且支持文件傳輸安全，加密，文件壓縮，斷點(diǎn)續(xù)傳等能力。

　　消息中間件能力

　　對(duì)于任何ESB總線，我們可以看到天生就自帶了強(qiáng)大的消息中間件能力，類似IBM的MB總線自帶MQ能力，Oracle的OSB總線自帶Weblogic JMS能力，Tibico的ESB總線自帶EMS消息中間件能力等。其核心原因就在于對(duì)于ESB服務(wù)總線本身既需要支持服務(wù)的同步集成和實(shí)時(shí)調(diào)用，也需要支持類似消息模式的異步集成能力。

　　我們可以看下對(duì)于當(dāng)前的API網(wǎng)關(guān)產(chǎn)品，實(shí)際上已經(jīng)沒有這部分的能力。所以API網(wǎng)關(guān)產(chǎn)品往往并不能解決消息集成和消費(fèi)發(fā)布訂閱。那么你在搭建新的技術(shù)平臺(tái)的時(shí)候，如果你選擇了API網(wǎng)關(guān)，往往還需要選擇另外一個(gè)開源的消息中間件來(lái)解決消息集成場(chǎng)景。

　　對(duì)于消息集成一方面是異步集成能力，更加重要的就是我們常說(shuō)的消息1對(duì)多，消息的發(fā)布訂閱場(chǎng)景。這個(gè)功能大大的簡(jiǎn)化了我們集成的復(fù)雜性，原來(lái)的多點(diǎn)集成轉(zhuǎn)變?yōu)榱嘶谙⒅虚g件的多點(diǎn)分發(fā)，而對(duì)于源端系統(tǒng)來(lái)說(shuō)只需要將數(shù)據(jù)分發(fā)到消息中間件即可，具體的朝目標(biāo)端的分發(fā)和重試機(jī)制完全由消息中間件自己來(lái)完成。

　　面向云端和云環(huán)境的服務(wù)集成能力

　　這個(gè)即是我們經(jīng)常談到能力開放平臺(tái)或OpenAPI開放平臺(tái)，或需要和公有云的對(duì)接平臺(tái)。實(shí)際上你可以看到當(dāng)前和各個(gè)公有云，外部的相關(guān)SaaS應(yīng)用對(duì)接基本都是類似OpenAPI平臺(tái)和基于Http接口的對(duì)接方式。因此你的集成平臺(tái)只需要支持這種辦統(tǒng)招文憑方式的對(duì)接，支持對(duì)基于Http Rest集成方式下的安全管理和監(jiān)控能力即可。

　　同時(shí)在和外部對(duì)接的時(shí)候需要考慮在企業(yè)的DMZ區(qū)單獨(dú)部署一套ESB總線，如果外部對(duì)接的場(chǎng)景足夠簡(jiǎn)單，比如全部都是Http Rest服務(wù)接口，那么我們也完全可以在DMZ區(qū)部署一套API網(wǎng)關(guān)產(chǎn)品即可。如果對(duì)于API網(wǎng)關(guān)你都覺得復(fù)雜，最簡(jiǎn)單的方式還可以部署一套Nginx服務(wù)來(lái)做代理路由。

　　因此對(duì)于云端的集成大家不要覺得復(fù)雜，基本能力仍然是我們常說(shuō)的ESB總線或API網(wǎng)關(guān)的能力，只是在我們進(jìn)行云端集成的時(shí)候，需要在安全性設(shè)計(jì)和實(shí)現(xiàn)上花更多的功夫。

　　遠(yuǎn)行的CSB云服務(wù)總線解決方案

　　前面談了企業(yè)內(nèi)的各種集成需求和集成場(chǎng)景，可以看到包括了服務(wù)集成，大數(shù)據(jù)集成，大文件集成，消息集成等多種場(chǎng)景，而這些在遠(yuǎn)行當(dāng)前CSB服務(wù)總線產(chǎn)品中可以全部提供，也就是一個(gè)產(chǎn)品可以提供上面所有的能力，而且大數(shù)據(jù)傳輸，大文件傳輸本身又和服務(wù)做了集成和協(xié)同，全面覆蓋了企業(yè)內(nèi)的集成場(chǎng)景和需求。同時(shí)還有一個(gè)關(guān)鍵點(diǎn)就是遠(yuǎn)行的CSB服務(wù)總線產(chǎn)品完全覆蓋當(dāng)前主流的API網(wǎng)關(guān)產(chǎn)品提供的全部功能和能力，可以對(duì)HttpRest服務(wù)接口的服務(wù)注冊(cè)接入，設(shè)計(jì)，安全，流控，運(yùn)行監(jiān)控的全生命周期管理。

　　對(duì)于存在大量遺留系統(tǒng)需要集成，逐步進(jìn)行IT架構(gòu)轉(zhuǎn)型的企業(yè)，遠(yuǎn)行服務(wù)總線能夠提供的這種一攬子的解決方案往往更加具備優(yōu)勢(shì)和價(jià)值。

　　企業(yè)集成的發(fā)展的三個(gè)階段

　　做了多年的SOA項(xiàng)目咨詢和實(shí)施，可以看到企業(yè)內(nèi)部業(yè)務(wù)系統(tǒng)間的集成主要還是三個(gè)階段，具體描述如下：

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

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

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

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

　　發(fā)展到第二階段，當(dāng)前說(shuō)的比較多的就是接口平臺(tái)或集成平臺(tái)。在這個(gè)階段一個(gè)最大的轉(zhuǎn)變就是原來(lái)的點(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è)過(guò)程往往是高度耦合在一起的，有接口需求B系統(tǒng)才會(huì)做接口服務(wù)，A系統(tǒng)馬上就去消費(fèi)。而到了OpenAPI平臺(tái)階段服務(wù)接入和服務(wù)消費(fèi)兩個(gè)過(guò)程是松耦合的，即能力即使在沒有消費(fèi)方的情況下也可以先接入并發(fā)布到能力庫(kù)，而各業(yè)務(wù)系統(tǒng)隨時(shí)也可查看服務(wù)目錄庫(kù)和服務(wù)市場(chǎng)發(fā)起服務(wù)訂購(gòu)請(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è)過(guò)程里面并不需要太多的集成商工作參與，所有需要的標(biāo)準(zhǔn)和規(guī)約也都全部固化到了類似服務(wù)接入，服務(wù)訂購(gòu)，服務(wù)開通等自服務(wù)流程中。

　　傳統(tǒng)集成平臺(tái)更多的是SOAP WS，Rest，JMS消息各種方式并存，而到了OpenAPI平臺(tái)由于是以能力開放和發(fā)布為主，基本可以全部統(tǒng)一為輕量的Rest服務(wù)接口服務(wù)模式。因此在OpenAPI平臺(tái)的能力開放模式下，底層的集成引擎往往會(huì)采用更加輕量的API網(wǎng)關(guān)來(lái)實(shí)現(xiàn)，而不再需要偏重的ESB總線引擎。