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

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

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

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

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

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

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

從上圖可以看出，當時系統(tǒng)間的關聯(lián)關系非常混亂，整體呈現(xiàn)為網(wǎng)狀結構，像蜘蛛網(wǎng)一般。這是因為在系統(tǒng)設計開發(fā)時，沒有考慮它們之間的互聯(lián)，所以之后系統(tǒng)建設時，會發(fā)現(xiàn)有的外包采購系統(tǒng)與其他系統(tǒng)的報文結構都不一樣，與這類系統(tǒng)對接時，需要把接口的報文全處理一遍，導致了很多重復的工作。

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

這就是我們經常說的牽一發(fā)而動全身，也是我們所“深惡痛絕”的網(wǎng)狀型架構的由來。

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

因此，演化出了輪狀型的應用集成架構模式，也可稱為"集中式"。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

就如同銀行不能再像以前一樣，保守地將技術應用限制在自己的體內，需要逐步從封閉走向開放。

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

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

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

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

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

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

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

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

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

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

（1）文件傳輸

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

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

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

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

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

必須有共同的文件服務器，存在安全風險，文件可能被篡改，刪除，或者存在泄密等。

格式沒有統(tǒng)一標準，標準性差，當改變文件格式的時候，需要各個系統(tǒng)都同步做修改。許多集成問題就是由于分析數(shù)據(jù)的方法不兼容造成的。（2）共享數(shù)據(jù)庫共享數(shù)據(jù)庫相比文件傳輸來說，因為使用的同一個數(shù)據(jù)庫，所以交互更加簡單和靈活。通過數(shù)據(jù)庫的事務機制，可以做成可靠性的數(shù)據(jù)交換，保證了數(shù)據(jù)的一致性，而且時間特性更強。讓所有應用都能在需要的時候，訪問任何共享數(shù)據(jù)是一個不錯的選擇。不僅能獲取到最新的數(shù)據(jù)，增強人們對數(shù)據(jù)本身的信任，而且還能減少因數(shù)據(jù)修改沒迅速傳遞給應用而造成的錯誤（如數(shù)據(jù)不一致）。

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

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

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

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

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