銀行核心系統(tǒng)之應(yīng)用集成

銀行核心系統(tǒng)之應(yīng)用集成

應(yīng)用集成是解決各個(gè)系統(tǒng)之間信息共享中最基礎(chǔ)和最重要的一步。我國(guó)的商業(yè)銀行都擁有繁多、復(fù)雜的應(yīng)用系統(tǒng)，重復(fù)開(kāi)發(fā)的情況嚴(yán)重，而且不能很好地跨系統(tǒng)共享數(shù)據(jù)或功能，不利于金融創(chuàng)新能力的提升。本文主要介紹了應(yīng)用集成的發(fā)展階段，和如何運(yùn)用集成技術(shù)與方式解決系統(tǒng)的煙囪問(wèn)題，以及相比較之下的優(yōu)點(diǎn)與局限性。還請(qǐng)各路專家批評(píng)指正：）

本文適合系統(tǒng)集成人員、應(yīng)用開(kāi)發(fā)人員或接口組人員閱讀，能擴(kuò)展一定知識(shí)面、實(shí)現(xiàn)個(gè)人技術(shù)&業(yè)務(wù)能力的沉淀和提升、從而設(shè)計(jì)出更好的集成解決方案。在實(shí)際工作中，會(huì)遇到各種各樣的問(wèn)題，對(duì)開(kāi)展工作的方式方法或套路還在梳理中，暫不做介紹。

此文的輸出源于在工作中的一些思考、經(jīng)查閱資料后而得出的總結(jié)，文章內(nèi)容不代表公司觀點(diǎn)。在文末有列出參考資料，方便對(duì)某個(gè)分支感興趣的同學(xué)，自行深入學(xué)習(xí)。同時(shí)也希望和更多的朋友一起探討和分享，或直接在留言區(qū)說(shuō)說(shuō)你的看法，一起成長(zhǎng)。一、應(yīng)用集成的基本概念和發(fā)展階段1、基本概念應(yīng)用集成是將基于不同平臺(tái)、用不同方案建立起異構(gòu)應(yīng)用集成的一種方法和技術(shù)。對(duì)銀行信息科技而言，不僅能夠充分發(fā)揮各單一應(yīng)用的價(jià)值，而且還能使銀行的整體運(yùn)作效率得以提高。在《銀行信息系統(tǒng)架構(gòu)》一書(shū)中，關(guān)于應(yīng)用集成是這么說(shuō)的：“從全行角度看，銀行IT系統(tǒng)是一個(gè)有機(jī)的整體，需要不同應(yīng)用之間的信息交互和服務(wù)協(xié)同，那么就要對(duì)應(yīng)用進(jìn)行集成。”對(duì)應(yīng)用集成的結(jié)構(gòu)化描述叫應(yīng)用集成架構(gòu)，可以結(jié)構(gòu)化地描述多個(gè)應(yīng)用之間的關(guān)系，具體的例子在下文中會(huì)細(xì)講，先一起來(lái)看看發(fā)展階段吧。2、發(fā)展階段了解應(yīng)用集成不同發(fā)展階段的定義，有利于銀行認(rèn)識(shí)自己，找出差距，更好地有針對(duì)性的實(shí)施IT規(guī)劃；有利于從業(yè)人員對(duì)本專業(yè)形成正確的認(rèn)知；有利于讓我們自身知識(shí)體系更加豐饒和健全。如何劃分我國(guó)銀行IT系統(tǒng)應(yīng)用集成的發(fā)展階段，有多種說(shuō)法，沒(méi)有一個(gè)業(yè)界公認(rèn)統(tǒng)一的標(biāo)準(zhǔn)。同梁禮方老師說(shuō)的一樣，不能用時(shí)間點(diǎn)來(lái)統(tǒng)一定義。因?yàn)椴煌你y行，成立的時(shí)間不一樣，應(yīng)用系統(tǒng)集成的起步時(shí)間自然不一樣，并且后來(lái)成立的銀行可以參考前面銀行IT建設(shè)的經(jīng)驗(yàn)，雖然起步稍晚，但發(fā)展相對(duì)會(huì)快一點(diǎn)。

從銀行的應(yīng)用集成架構(gòu)模式來(lái)梳理，應(yīng)用集成的發(fā)展階段主要可以分為網(wǎng)狀型架構(gòu)、輪狀型架構(gòu)、總線型架構(gòu)、API平臺(tái)和云服務(wù)總線。

（1）網(wǎng)狀型架構(gòu)網(wǎng)狀型架構(gòu)又稱為"點(diǎn)對(duì)點(diǎn)連接"，指不同的應(yīng)用間處于完全平等的地位，系統(tǒng)間很少有統(tǒng)一的接口規(guī)范以及報(bào)文格式，任意兩個(gè)應(yīng)用間都可以互相連接或服務(wù)調(diào)用。網(wǎng)狀型架構(gòu)實(shí)現(xiàn)了簡(jiǎn)單、基本的信息交互和數(shù)據(jù)傳遞，優(yōu)點(diǎn)是不必太多關(guān)心其他應(yīng)用的影響，交易路徑簡(jiǎn)短，總體效率高。其缺點(diǎn)也是顯而易見(jiàn)的，功能分散、互聯(lián)復(fù)雜、不易管理、缺乏可伸縮性。比如，文件/消息格式、安全策略等集成邏輯是硬編碼到應(yīng)用中；再如，對(duì)IT服務(wù)沒(méi)有形成統(tǒng)一管理，檢索和發(fā)現(xiàn)功能困難，從而阻礙了資源的重用。

從上圖可以看出，當(dāng)時(shí)系統(tǒng)間的關(guān)聯(lián)關(guān)系非?；靵y，整體呈現(xiàn)為網(wǎng)狀結(jié)構(gòu)，像蜘蛛網(wǎng)一般。這是因?yàn)樵谙到y(tǒng)設(shè)計(jì)開(kāi)發(fā)時(shí)，沒(méi)有考慮它們之間的互聯(lián)，所以之后系統(tǒng)建設(shè)時(shí)，會(huì)發(fā)現(xiàn)有的外包采購(gòu)系統(tǒng)與其他系統(tǒng)的報(bào)文結(jié)構(gòu)都不一樣，與這類系統(tǒng)對(duì)接時(shí)，需要把接口的報(bào)文全處理一遍，導(dǎo)致了很多重復(fù)的工作。

隨著銀行信息化的不斷深入，系統(tǒng)數(shù)據(jù)和數(shù)量不斷增加，系統(tǒng)間的相互訪問(wèn)越來(lái)越多、越來(lái)越密切，系統(tǒng)的建設(shè)難度和改造難度也越來(lái)越大。

這就是我們經(jīng)常說(shuō)的牽一發(fā)而動(dòng)全身，也是我們所“深惡痛絕”的網(wǎng)狀型架構(gòu)的由來(lái)。

（2）輪狀型架構(gòu)由于網(wǎng)狀型架構(gòu)存在諸多弊端，為了更有效地利用現(xiàn)有的信息系統(tǒng)和資源，使人、財(cái)、物等資源在企業(yè)內(nèi)部共享，銀行IT建設(shè)開(kāi)始注重系統(tǒng)的內(nèi)部建設(shè)，如統(tǒng)一編碼標(biāo)準(zhǔn)、命名標(biāo)準(zhǔn)、元數(shù)據(jù)定義。

因此，演化出了輪狀型的應(yīng)用集成架構(gòu)模式，也可稱為"集中式"。

集中式典型的做法是將主要業(yè)務(wù)處理的綜合業(yè)務(wù)系統(tǒng)作為中心節(jié)點(diǎn)，系統(tǒng)只需要與中心相連，便可實(shí)現(xiàn)彼此間的交互。其他節(jié)點(diǎn)作為綜合業(yè)務(wù)系統(tǒng)的外掛系統(tǒng)。

即Hub模式，使得系統(tǒng)間連接數(shù)量大幅減少，而且很容易實(shí)現(xiàn)應(yīng)用之間的整合，便于管理大量的連接和系統(tǒng)。（Hub模式：是將所有的運(yùn)輸量集中到一個(gè)中心節(jié)點(diǎn)，然后再向各節(jié)點(diǎn)發(fā)運(yùn)的網(wǎng)絡(luò)模式。）

不過(guò)，基于中心模式的集成架構(gòu)，缺點(diǎn)也很明顯。由于中間節(jié)點(diǎn)既要處理大量的銀行業(yè)務(wù)，又要承擔(dān)應(yīng)用之間的交互，具有較大性能瓶頸。盡管國(guó)內(nèi)少數(shù)銀行仍然采用此種類型的架構(gòu)，但已經(jīng)落伍了。

（3）總線型架構(gòu)隨著SOA的興起，出現(xiàn)了總線型架構(gòu)，它是目前國(guó)內(nèi)銀行中使用最多、最廣泛的一種應(yīng)用集成架構(gòu)模式。

在總線型架構(gòu)中，銀行的主要應(yīng)用都通過(guò)總線連接和交互，總線不處理或很少處理銀行業(yè)務(wù)邏輯，它主要負(fù)責(zé)應(yīng)用之間的互聯(lián)互通等功能，即中介代理。

換句話說(shuō)，總線型架構(gòu)就是在渠道系統(tǒng)與核心、及外圍系統(tǒng)間建立一座橋梁。各系統(tǒng)的接口都注冊(cè)發(fā)布到ESB總線上，由總線發(fā)布統(tǒng)一的、標(biāo)準(zhǔn)的接口，不同應(yīng)用只需要按照總線的規(guī)范與總線進(jìn)行互聯(lián)。

因此對(duì)服務(wù)使用者而言，無(wú)需關(guān)心服務(wù)提供者是基于什么開(kāi)發(fā)技術(shù)或平臺(tái)提供的服務(wù)，不僅避免了因服務(wù)提供者接口的變化而需要同步修改此服務(wù)調(diào)用者的資源，而且也降低了系統(tǒng)間耦合，更方便、高效地實(shí)現(xiàn)了對(duì)新系統(tǒng)的集成，為服務(wù)負(fù)載均衡、服務(wù)管控提供了更專業(yè)的能力。

從而簡(jiǎn)化了銀行信息系統(tǒng)的復(fù)雜性，提高了系統(tǒng)架構(gòu)的靈活性，降低了行內(nèi)信息共享的成本。但隨著系統(tǒng)功能的追加，總線程序逐漸成為一個(gè)復(fù)雜的龐然大物，導(dǎo)致存在隱性風(fēng)險(xiǎn)。

例如，邏輯耦合嚴(yán)重，代碼難以理解，開(kāi)發(fā)人員職責(zé)不清，系統(tǒng)部署困難，回歸測(cè)試、總線的擴(kuò)容升級(jí)、或是在網(wǎng)絡(luò)設(shè)備上的資源投入成本巨大，以及ESB這種“中心化”服務(wù)可能帶來(lái)災(zāi)難性的雪崩效應(yīng)。

加上互聯(lián)網(wǎng)時(shí)代的海量用戶與數(shù)據(jù)，對(duì)系統(tǒng)可擴(kuò)展、高并發(fā)及業(yè)務(wù)響應(yīng)速度等方面都提出了更高的要求。所以，為了進(jìn)一步提高銀行整體科技能力，需要通過(guò)適當(dāng)?shù)姆植际郊軜?gòu)轉(zhuǎn)型，來(lái)降低開(kāi)發(fā)和運(yùn)維的成本，有效的實(shí)現(xiàn)業(yè)務(wù)創(chuàng)新和技術(shù)變革。

（4）API平臺(tái)分布式架構(gòu)是利用網(wǎng)絡(luò)計(jì)算機(jī)設(shè)備，將計(jì)算任務(wù)和數(shù)據(jù)分解，充分利用各計(jì)算機(jī)的計(jì)算能力，彼此協(xié)調(diào)、共同完成一項(xiàng)業(yè)務(wù)功能的技術(shù)架構(gòu)。

在2016年，人行發(fā)布了《金融業(yè)信息化“十三五”發(fā)展規(guī)劃》，明確提出“以安全、可靠、高效、彈性為重點(diǎn)目標(biāo)實(shí)施架構(gòu)轉(zhuǎn)型、探索分布式架構(gòu)和成熟開(kāi)源技術(shù)應(yīng)用，逐步減少或擺脫對(duì)單一技術(shù)產(chǎn)品的依賴”。

所以無(wú)論從技術(shù)發(fā)展還是監(jiān)管要求來(lái)看，銀行核心系統(tǒng)朝著分布式架構(gòu)、云計(jì)算方向發(fā)展已是必然趨勢(shì)。

如果將此前的銀行系統(tǒng)比作煮雞蛋，那蛋殼是渠道系統(tǒng)（如營(yíng)業(yè)廳），蛋清是前置服務(wù)（如人行前置），蛋黃就是銀行核心系統(tǒng)。

那現(xiàn)在銀行IT系統(tǒng)采用了分布式架構(gòu)，從煮雞蛋變成了攤雞蛋餅，底座雞蛋餅的接觸面更大了，里面可以摻著各種各樣的蔬菜、各種各樣的佐料。

就如同銀行不能再像以前一樣，保守地將技術(shù)應(yīng)用限制在自己的體內(nèi)，需要逐步從封閉走向開(kāi)放。

所以為突破對(duì)單一資源依賴、促進(jìn)分布式系統(tǒng)發(fā)展、避免單點(diǎn)故障提高可用性、提高復(fù)用性等方面原因。在應(yīng)用集成的過(guò)程中，核心和基礎(chǔ)組建被抽取出來(lái)作為單獨(dú)的系統(tǒng)對(duì)外提供服務(wù)，形成API平臺(tái)。

銀行通過(guò)API快速開(kāi)放核心能力，并對(duì)API提供安全運(yùn)行和高效管理的成熟軟件，通過(guò)API包裝成符合互聯(lián)網(wǎng)模式的產(chǎn)品或服務(wù)，積極輸出給自身的業(yè)務(wù)場(chǎng)景、或合作伙伴，實(shí)現(xiàn)共贏，加快銀行數(shù)字化轉(zhuǎn)型的速度。

API平臺(tái)對(duì)傳統(tǒng)銀行互聯(lián)網(wǎng)化可分為三大能力，分別是服務(wù)訪問(wèn)、管理組織和運(yùn)維管控。

服務(wù)訪問(wèn)用于提供穩(wěn)定高效且可線性擴(kuò)展的服務(wù)能力，可細(xì)分為協(xié)議轉(zhuǎn)換、認(rèn)證鑒權(quán)、服務(wù)控制；管理組織包括API的發(fā)布和管理、服務(wù)授權(quán)與消費(fèi)；運(yùn)維管控具有多樣的運(yùn)維管理工具，包括日志監(jiān)控、平臺(tái)配置等。

構(gòu)建API平臺(tái)是一項(xiàng)頗具挑戰(zhàn)性的任務(wù)，受制于過(guò)去銀行內(nèi)部系統(tǒng)間報(bào)文結(jié)構(gòu)的慣性，業(yè)務(wù)和技術(shù)部門的分隔也是巨大障礙。國(guó)內(nèi)的先行者，有浦發(fā)銀行的API開(kāi)放平臺(tái)和招商銀行的企業(yè)開(kāi)放平臺(tái)，可以通過(guò)官網(wǎng)了解到。（5）云服務(wù)總線隨著銀行業(yè)信息化的快速發(fā)展，各銀行都認(rèn)識(shí)到云平臺(tái)對(duì)銀行架構(gòu)轉(zhuǎn)型的重要性，紛紛大力建設(shè)云平臺(tái)。就來(lái)說(shuō)說(shuō)能幫助銀行實(shí)現(xiàn)行內(nèi)系統(tǒng)之間、與合作伙伴或第三方系統(tǒng)間服務(wù)互通的CSB。

云服務(wù)總線CSB（CloudServiceBus）提供平臺(tái)化的應(yīng)用集成和服務(wù)開(kāi)放能力，通過(guò)統(tǒng)一的服務(wù)管理，可以適配多種常見(jiàn)服務(wù)協(xié)議。CBS支持跨環(huán)境服務(wù)互通，主要用于專有云、混合云。

CSB可以把企業(yè)內(nèi)外應(yīng)用提供的服務(wù)發(fā)布成API，供消費(fèi)方訂閱調(diào)用，并提供審批授權(quán)、服務(wù)管控和計(jì)量監(jiān)控等能力。不僅是內(nèi)部服務(wù)開(kāi)放到外部，還可以是內(nèi)到內(nèi)、內(nèi)到外、外到內(nèi)、外到外的靈活開(kāi)放模式。

上圖來(lái)源于阿里云，這塊還不太了解，就不再展開(kāi)，感興趣的朋友可以自行深入。接下來(lái)進(jìn)入第二部分～二、用集成技術(shù)與方式解決煙囪問(wèn)題1、集成技術(shù)介紹不同的應(yīng)用場(chǎng)景選用不同的集成技術(shù)，下面就從系統(tǒng)間集成需求的角度來(lái)對(duì)系統(tǒng)集成技術(shù)進(jìn)行分類，好讓大家對(duì)集成技術(shù)有更為深入的認(rèn)識(shí)和思考。

應(yīng)用功能交互是指系統(tǒng)間互相調(diào)用對(duì)方提供的功能或服務(wù)。數(shù)據(jù)交互是指系統(tǒng)間以獲取對(duì)方數(shù)據(jù)為目的的交互或數(shù)據(jù)傳輸，又可細(xì)分為輕量、批量（大量）。對(duì)聯(lián)機(jī)/實(shí)時(shí)查詢交易來(lái)說(shuō)，也作為輕量的數(shù)據(jù)交互類型選擇合適的集成技術(shù)。

關(guān)于集成技術(shù)的簡(jiǎn)述如下：WebService(SOAP/HTTP)使用于快速與ESB平臺(tái)對(duì)接，是連接異構(gòu)系統(tǒng)或語(yǔ)言的首選協(xié)議。它不依賴于語(yǔ)言和平臺(tái)，便可以實(shí)現(xiàn)不同的語(yǔ)言間的相互調(diào)用，通過(guò)Internet進(jìn)行基于Http協(xié)議的網(wǎng)絡(luò)應(yīng)用間的交互，多用于同步通信模式。JMS是一個(gè)Java平臺(tái)中關(guān)于面向消息中間件（MOM）的API，用于在兩個(gè)應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信。Java消息服務(wù)是一個(gè)與具體平臺(tái)無(wú)關(guān)的API，絕大多數(shù)MOM提供商都對(duì)JMS提供支持。RMI是遠(yuǎn)程方法調(diào)用，允許運(yùn)行在一個(gè)Java虛擬機(jī)的對(duì)象調(diào)用運(yùn)行在另一個(gè)Java虛擬機(jī)上的對(duì)象。這兩個(gè)虛擬機(jī)可以是運(yùn)行在相同計(jì)算機(jī)上的不同進(jìn)程中，也可以是運(yùn)行在網(wǎng)絡(luò)上的不同計(jì)算機(jī)中，但不建議用于大數(shù)據(jù)量傳輸。Socket是計(jì)算機(jī)之間進(jìn)行通信的一種約定或一種方式，可以理解為一組較為穩(wěn)定接口。通過(guò)socket約定，一臺(tái)計(jì)算機(jī)可以接收其他計(jì)算機(jī)的數(shù)據(jù)，也可以向其他計(jì)算機(jī)發(fā)送數(shù)據(jù)。FTP簡(jiǎn)稱為“文傳協(xié)議”，用于Internet上的控制文件的雙向傳輸，適用于非實(shí)時(shí)數(shù)據(jù)傳輸，使用客戶/服務(wù)器模式，它屬于網(wǎng)絡(luò)傳輸協(xié)議的應(yīng)用層，能操作任何類型的文件而不涉及數(shù)據(jù)的加工轉(zhuǎn)換。ETL是構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)的重要一環(huán)，從數(shù)據(jù)源抽取出所需的數(shù)據(jù)，經(jīng)過(guò)數(shù)據(jù)清洗，最終按照預(yù)先定義好的數(shù)據(jù)倉(cāng)庫(kù)模型，將數(shù)據(jù)加載到數(shù)據(jù)倉(cāng)庫(kù)中去DBLink用于當(dāng)前數(shù)據(jù)庫(kù)會(huì)話中訪問(wèn)另外一個(gè)數(shù)據(jù)庫(kù)，適用于oracle數(shù)據(jù)庫(kù)之間的數(shù)據(jù)交互。JDBC是一種用于執(zhí)行SQL語(yǔ)句的JavaAPI，可以為多種關(guān)系數(shù)據(jù)庫(kù)提供統(tǒng)一訪問(wèn)，它由一組用Java語(yǔ)言編寫的類和接口組成。不難看出，集成其實(shí)不是一項(xiàng)簡(jiǎn)單的任務(wù)，需要了解銀行業(yè)務(wù)場(chǎng)景或問(wèn)題后，經(jīng)過(guò)反復(fù)摸索和試錯(cuò)，或者是向有經(jīng)驗(yàn)的集成架構(gòu)師取經(jīng)，才能學(xué)到套路。套路不是指可以復(fù)制粘貼的代碼，而是一些寶貴的建議或工作思路，使用得當(dāng)，才能幫助我們解決集成目標(biāo)與具體系統(tǒng)之間的鴻溝。2、應(yīng)用集成方式為了尋找更好的應(yīng)用集成解決方案，所以有不同的應(yīng)用集成方式，大體上可以分為四種，按演化的順序和復(fù)雜度排序，分別是文件傳輸、共享數(shù)據(jù)庫(kù)、遠(yuǎn)程過(guò)程調(diào)用和消息傳遞。它們?cè)诮鉀Q某些特定領(lǐng)域的問(wèn)題時(shí)都有自己的特長(zhǎng)，而且每個(gè)應(yīng)用都可以使用不同的集成方式，所以應(yīng)當(dāng)根據(jù)實(shí)際情況選擇最合適的。

（1）文件傳輸

文件傳輸是最簡(jiǎn)單的應(yīng)用集成方式，因?yàn)槲募且环N通用的存儲(chǔ)機(jī)制，各系統(tǒng)都有具備該功能，集成人員不必了解應(yīng)用的內(nèi)部細(xì)節(jié)。通常是由各應(yīng)用小組提供文件，然后約定文件服務(wù)器地址、文件命名規(guī)則、文件內(nèi)容格式等內(nèi)容，再通過(guò)上傳文件到文件服務(wù)器進(jìn)行數(shù)據(jù)交互即可。

當(dāng)今商業(yè)銀行對(duì)數(shù)據(jù)分析的需求越來(lái)越多，系統(tǒng)之間的數(shù)據(jù)交互活動(dòng)越來(lái)越頻繁，同時(shí)，銀行對(duì)數(shù)據(jù)文件傳輸?shù)陌踩?、可靠性、審?jì)性、完整性、可視化等需求也在不斷增加，如銀行對(duì)賬文件、賬單文件、批量轉(zhuǎn)聯(lián)機(jī)文件等，所以構(gòu)建更有效的銀行文件傳輸平臺(tái)需求日益迫切。銀行文件傳輸平臺(tái)是銀行文件傳輸?shù)闹匾ぞ撸壳巴ㄓ玫奈募鬏敿夹g(shù)包括文件拷貝、FTP文件傳輸協(xié)議、TCP/IP傳輸協(xié)議和HTTP協(xié)議等。除了技術(shù)外，建設(shè)時(shí)還要分析系統(tǒng)接口現(xiàn)狀，安全規(guī)范，應(yīng)用場(chǎng)景，運(yùn)維場(chǎng)景，監(jiān)管要求和實(shí)施商。比如，納入銀行文件傳輸平臺(tái)的文件范圍，就需要考慮批量是否會(huì)影響聯(lián)機(jī)，因?yàn)槁?lián)機(jī)交易對(duì)時(shí)效性要求比批量更高；再如，與行外系統(tǒng)進(jìn)行文件傳輸時(shí)，就需要考慮外聯(lián)機(jī)構(gòu)的系統(tǒng)不支持行內(nèi)現(xiàn)有傳輸工具，得充分與合作方進(jìn)行溝通，確定合適的傳輸機(jī)制等。除了批量轉(zhuǎn)聯(lián)機(jī)文件，文件還有一個(gè)細(xì)分類型：文件通知，顧名思義即采用文件傳輸?shù)姆绞竭M(jìn)行通知信息的傳達(dá)。例如，批量是異步處理，調(diào)用者如何知道文件處理到哪一步了呢？可以通過(guò)一個(gè)查詢交易來(lái)跟蹤處理進(jìn)度，也可以批量處理方處理完關(guān)鍵步驟后主動(dòng)對(duì)外發(fā)送文件通知?？偟膩?lái)說(shuō)，文件傳輸?shù)膬?yōu)點(diǎn)和缺點(diǎn)優(yōu)點(diǎn)如下：優(yōu)點(diǎn)：

適合數(shù)據(jù)量大的情況，不會(huì)超時(shí)，不占用網(wǎng)絡(luò)帶寬。

方案簡(jiǎn)單（只要接口雙方約定好路徑、格式、處理方式即可），實(shí)現(xiàn)簡(jiǎn)單、傳輸批量數(shù)據(jù)效率較高。避免了網(wǎng)絡(luò)傳輸，網(wǎng)絡(luò)協(xié)議相關(guān)的概念。缺點(diǎn)：

不太適合做實(shí)時(shí)類的業(yè)務(wù)。

必須有共同的文件服務(wù)器，存在安全風(fēng)險(xiǎn)，文件可能被篡改，刪除，或者存在泄密等。

格式?jīng)]有統(tǒng)一標(biāo)準(zhǔn)，標(biāo)準(zhǔn)性差，當(dāng)改變文件格式的時(shí)候，需要各個(gè)系統(tǒng)都同步做修改。許多集成問(wèn)題就是由于分析數(shù)據(jù)的方法不兼容造成的。（2）共享數(shù)據(jù)庫(kù)共享數(shù)據(jù)庫(kù)相比文件傳輸來(lái)說(shuō)，因?yàn)槭褂玫耐粋€(gè)數(shù)據(jù)庫(kù)，所以交互更加簡(jiǎn)單和靈活。通過(guò)數(shù)據(jù)庫(kù)的事務(wù)機(jī)制，可以做成可靠性的數(shù)據(jù)交換，保證了數(shù)據(jù)的一致性，而且時(shí)間特性更強(qiáng)。讓所有應(yīng)用都能在需要的時(shí)候，訪問(wèn)任何共享數(shù)據(jù)是一個(gè)不錯(cuò)的選擇。不僅能獲取到最新的數(shù)據(jù)，增強(qiáng)人們對(duì)數(shù)據(jù)本身的信任，而且還能減少因數(shù)據(jù)修改沒(méi)迅速傳遞給應(yīng)用而造成的錯(cuò)誤（如數(shù)據(jù)不一致）。

但如果所集成的所有應(yīng)用都依賴于相同的數(shù)據(jù)庫(kù)，盡管各個(gè)應(yīng)用能保證數(shù)據(jù)一致，但會(huì)大大增加系統(tǒng)間的耦合性。例如，當(dāng)多個(gè)應(yīng)用通過(guò)共享數(shù)據(jù)庫(kù)頻繁讀取和修改相同的數(shù)據(jù)時(shí)，數(shù)據(jù)庫(kù)會(huì)成為一個(gè)性能瓶頸，如果各個(gè)應(yīng)用都在對(duì)數(shù)據(jù)完成互斥操作時(shí)，還會(huì)引起死鎖。當(dāng)應(yīng)用分布在不同的位置、通過(guò)廣域網(wǎng)訪問(wèn)同一個(gè)共享數(shù)據(jù)庫(kù)時(shí)，訪問(wèn)速度可能過(guò)慢。分布式數(shù)據(jù)庫(kù)的話還會(huì)涉及數(shù)據(jù)存儲(chǔ)在哪臺(tái)機(jī)器、是否會(huì)存在鎖定沖突等問(wèn)題，都很容易在性能方面帶來(lái)災(zāi)難。而且多層級(jí)的組織架構(gòu)下，協(xié)調(diào)各部門配合改用統(tǒng)一的數(shù)據(jù)庫(kù)，也是一項(xiàng)非常艱難的任務(wù)。（3）遠(yuǎn)程過(guò)程調(diào)用

應(yīng)用集成的實(shí)現(xiàn)目標(biāo)除了數(shù)據(jù)之外，就是集成應(yīng)用的功能了，因?yàn)閿?shù)據(jù)的改變離不開(kāi)各應(yīng)用采取的動(dòng)作，所以需要一種機(jī)制通過(guò)傳遞要共享的數(shù)據(jù)，結(jié)合應(yīng)用間的函數(shù)調(diào)用，來(lái)告訴接受方應(yīng)用該如何處理數(shù)據(jù)。這時(shí)就可以使用遠(yuǎn)程過(guò)程調(diào)用(RPC)，也可稱為外調(diào)或外呼。遠(yuǎn)程過(guò)程調(diào)用的方法在早些年比較常見(jiàn)，典型的如Java的RMI。在分布式環(huán)境下，遠(yuǎn)程過(guò)程調(diào)用允許本地計(jì)算機(jī)上的程序調(diào)用遠(yuǎn)程計(jì)算機(jī)上的進(jìn)程。遠(yuǎn)程過(guò)程調(diào)用允許發(fā)送一個(gè)請(qǐng)求（客戶進(jìn)程）到遠(yuǎn)地進(jìn)程即被調(diào)用者，被調(diào)用者或服務(wù)器進(jìn)程執(zhí)行這個(gè)過(guò)程并發(fā)回一個(gè)結(jié)果（響應(yīng)）消息。遠(yuǎn)程過(guò)程調(diào)用方法最主要的特點(diǎn)是程序不需要知道調(diào)用的過(guò)程是本地還是遠(yuǎn)地。遠(yuǎn)程過(guò)程調(diào)用和傳統(tǒng)的過(guò)程調(diào)用不同就在于調(diào)用者（Caller或Client）和被調(diào)用的進(jìn)程（Server）是在不同的機(jī)器上的不同的進(jìn)程。其典型的應(yīng)用場(chǎng)景有很多，從12年說(shuō)起。隨著facebook、amazon開(kāi)放平臺(tái)獲得的巨大成功，互聯(lián)網(wǎng)頭部大廠也逐步開(kāi)放接口，實(shí)施開(kāi)放平臺(tái)生態(tài)圈戰(zhàn)略，銀行業(yè)開(kāi)始試點(diǎn)互聯(lián)網(wǎng)金融，新建互金系統(tǒng)。傳統(tǒng)銀行的各個(gè)產(chǎn)品系統(tǒng)是比較穩(wěn)定，采取瀑布式開(kāi)發(fā)方式導(dǎo)致需求實(shí)施周期很長(zhǎng)，無(wú)法滿足互金產(chǎn)品快速迭代的需求。

所以將互金產(chǎn)品單獨(dú)排期實(shí)施，單獨(dú)部署。所有的互金產(chǎn)品系統(tǒng)全部將接口服務(wù)化注冊(cè)到服務(wù)注冊(cè)中心，案例是基于阿里的dubbo開(kāi)發(fā)，系統(tǒng)將接口都注冊(cè)在zookeeper上，兩個(gè)系統(tǒng)直接的服務(wù)交互就采用的是遠(yuǎn)程過(guò)程調(diào)用模式。遠(yuǎn)程過(guò)程調(diào)用可以跨平臺(tái)操作，非常靈活。其缺點(diǎn)主要在于采用了同步通信方式，適合于小型的簡(jiǎn)單應(yīng)用，而且應(yīng)用間仍是緊密的耦合在一起，不同的業(yè)務(wù)場(chǎng)景下還存在操作處理的時(shí)序性問(wèn)題，所以獨(dú)立地修改系統(tǒng)比較困難。為了支持少量數(shù)據(jù)的頻繁交換、以更加松耦合的異步方式來(lái)集成應(yīng)用，可以使用消息傳遞。（4）消息傳遞

采用消息傳遞實(shí)現(xiàn)系統(tǒng)間的協(xié)作和通信，有助于集成人員選擇不同的消息傳遞方式，如把消息廣播給多個(gè)接收者，或把消息路由給多個(gè)接收者之一，有助于將集成設(shè)計(jì)與應(yīng)用開(kāi)發(fā)分離，以及流量的削峰填谷、解決最終一致性問(wèn)題等，是一種兼顧了性能、可靠性和松耦合的一種理想集成方式。

（消息路由：指消息發(fā)送者不知道消息發(fā)送到哪里，它可以將數(shù)據(jù)發(fā)送給一個(gè)消息路由器，由它將數(shù)據(jù)轉(zhuǎn)發(fā)給