銀行核心系統之應用集成_ZenDei技術網路在線

應用集成是解決各個系統之間信息共用中最基礎和最重要的一步。我國的商業銀行都擁有繁多、複雜的應用系統，重覆開發的情況嚴重，而且不能很好地跨系統共用數據或功能，不利於金融創新能力的提升。本文主要介紹了應用集成的發展階段，和如何運用集成技術與方式解決系統的煙囪問題，以及相比較之下的優點與局限性。還請各路專... ...

應用集成是解決各個系統之間信息共用中最基礎和最重要的一步。我國的商業銀行都擁有繁多、複雜的應用系統，重覆開發的情況嚴重，而且不能很好地跨系統共用數據或功能，不利於金融創新能力的提升。本文主要介紹了應用集成的發展階段，和如何運用集成技術與方式解決系統的煙囪問題，以及相比較之下的優點與局限性。還請各路專家批評指正：）
本文適合系統集成人員、應用開發人員或介面組人員閱讀，能擴展一定知識面、實現個人技術&業務能力的沉澱和提升、從而設計出更好的集成解決方案。在實際工作中，會遇到各種各樣的問題，對開展工作的方式方法或套路還在梳理中，暫不做介紹。
此文的輸出源於在工作中的一些思考、經查閱資料後而得出的總結，文章內容不代表公司觀點。在文末有列出參考資料，方便對某個分支感興趣的同學，自行深入學習。同時也希望和更多的朋友一起探討和分享，或直接在留言區說說你的看法，一起成長。

一、應用集成的基本概念和發展階段

1、基本概念
應用集成是將基於不同平臺、用不同方案建立起異構應用集成的一種方法和技術。對銀行信息科技而言，不僅能夠充分發揮各單一應用的價值，而且還能使銀行的整體運作效率得以提高。
在《銀行信息系統架構》一書中，關於應用集成是這麼說的：“從全行角度看，銀行IT系統是一個有機的整體，需要不同應用之間的信息交互和服務協同，那麼就要對應用進行集成。”
對應用集成的結構化描述叫應用集成架構，可以結構化地描述多個應用之間的關係，具體的例子在下文中會細講，先一起來看看發展階段吧。

2、發展階段
瞭解應用集成不同發展階段的定義，有利於銀行認識自己，找出差距，更好地有針對性的實施IT規劃；有利於從業人員對本專業形成正確的認知；有利於讓我們自身知識體系更加豐饒和健全。
如何劃分我國銀行IT系統應用集成的發展階段，有多種說法，沒有一個業界公認統一的標準。同梁禮方老師說的一樣，不能用時間點來統一定義。
因為不同的銀行，成立的時間不一樣，應用系統集成的起步時間自然不一樣，並且後來成立的銀行可以參考前面銀行IT建設的經驗，雖然起步稍晚，但發展相對會快一點。
從銀行的應用集成架構模式來梳理，應用集成的發展階段主要可以分為網狀型架構、輪狀型架構、匯流排型架構、API平臺和雲服務匯流排。

（1）網狀型架構

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

從上圖可以看出，當時系統間的關聯關係非常混亂，整體呈現為網狀結構，像蜘蛛網一般。
這是因為在系統設計開發時，沒有考慮它們之間的互聯，所以之後系統建設時，會發現有的外包採購系統與其他系統的報文結構都不一樣，與這類系統對接時，需要把介面的報文全處理一遍，導致了很多重覆的工作。
隨著銀行信息化的不斷深入，系統數據和數量不斷增加，系統間的相互訪問越來越多、越來越密切，系統的建設難度和改造難度也越來越大。
這就是我們經常說的牽一發而動全身，也是我們所“深惡痛絕”的網狀型架構的由來。

（2）輪狀型架構

由於網狀型架構存在諸多弊端，為了更有效地利用現有的信息系統和資源，使人、財、物等資源在企業內部共用，銀行IT建設開始註重系統的內部建設，如統一編碼標準、命名標準、元數據定義。
因此，演化出了輪狀型的應用集成架構模式，也可稱為"集中式"。
集中式典型的做法是將主要業務處理的綜合業務系統作為中心節點，系統只需要與中心相連，便可實現彼此間的交互。其他節點作為綜合業務系統的外掛系統。

即Hub模式，使得系統間連接數量大幅減少，而且很容易實現應用之間的整合，便於管理大量的連接和系統。（Hub 模式：是將所有的運輸量集中到一個中心節點，然後再向各節點發運的網路模式。）
不過，基於中心模式的集成架構，缺點也很明顯。由於中間節點既要處理大量的銀行業務，又要承擔應用之間的交互，具有較大性能瓶頸。儘管國內少數銀行仍然採用此種類型的架構，但已經落伍了。

（3）匯流排型架構

隨著SOA的興起，出現了匯流排型架構，它是目前國內銀行中使用最多、最廣泛的一種應用集成架構模式。
在匯流排型架構中，銀行的主要應用都通過匯流排連接和交互，匯流排不處理或很少處理銀行業務邏輯，它主要負責應用之間的互聯互通等功能，即中介代理。
換句話說，匯流排型架構就是在渠道系統與核心、及外圍系統間建立一座橋梁。各系統的介面都註冊發佈到ESB匯流排上，由匯流排發佈統一的、標準的介面，不同應用只需要按照匯流排的規範與匯流排進行互聯。

因此對服務使用者而言，無需關心服務提供者是基於什麼開發技術或平臺提供的服務，不僅避免了因服務提供者介面的變化而需要同步修改此服務調用者的資源，而且也降低了系統間耦合，更方便、高效地實現了對新系統的集成，為服務負載均衡、服務管控提供了更專業的能力。
從而簡化了銀行信息系統的複雜性，提高了系統架構的靈活性，降低了行內信息共用的成本。但隨著系統功能的追加，匯流排程式逐漸成為一個複雜的龐然大物，導致存在隱性風險。
例如，邏輯耦合嚴重，代碼難以理解，開發人員職責不清，系統部署困難，回歸測試、匯流排的擴容升級、或是在網路設備上的資源投入成本巨大，以及ESB這種“中心化”服務可能帶來災難性的雪崩效應。
加上互聯網時代的海量用戶與數據，對系統可擴展、高併發及業務響應速度等方面都提出了更高的要求。所以，為了進一步提高銀行整體科技能力，需要通過適當的分散式架構轉型，來降低開發和運維的成本，有效的實現業務創新和技術變革。

（4）API平臺

分散式架構是利用網路電腦設備，將計算任務和數據分解，充分利用各電腦的計算能力，彼此協調、共同完成一項業務功能的技術架構。
在2016年，人行發佈了《金融業信息化“十三五”發展規劃》，明確提出“以安全、可靠、高效、彈性為重點目標實施架構轉型、探索分散式架構和成熟開源技術應用，逐步減少或擺脫對單一技術產品的依賴”。
所以無論從技術發展還是監管要求來看，銀行核心系統朝著分散式架構、雲計算方向發展已是必然趨勢。
如果將此前的銀行系統比作煮雞蛋，那蛋殼是渠道系統（如營業廳），蛋清是前置服務（如人行前置），蛋黃就是銀行核心系統。
那現在銀行IT系統採用了分散式架構，從煮雞蛋變成了攤雞蛋餅，底座雞蛋餅的接觸面更大了，裡面可以摻著各種各樣的蔬菜、各種各樣的佐料。
就如同銀行不能再像以前一樣，保守地將技術應用限制在自己的體內，需要逐步從封閉走向開放。
所以為突破對單一資源依賴、促進分散式系統發展、避免單點故障提高可用性、提高復用性等方面原因。在應用集成的過程中，核心和基礎組建被抽取出來作為單獨的系統對外提供服務，形成API平臺。

銀行通過API快速開放核心能力，並對API提供安全運行和高效管理的成熟軟體，通過API包裝成符合互聯網模式的產品或服務，積極輸出給自身的業務場景、或合作伙伴，實現共贏，加快銀行數字化轉型的速度。
API平臺對傳統銀行互聯網化可分為三大能力，分別是服務訪問、管理組織和運維管控。
服務訪問用於提供穩定高效且可線性擴展的服務能力，可細分為協議轉換、認證鑒權、服務控制；管理組織包括API的發佈和管理、服務授權與消費；運維管控具有多樣的運維管理工具，包括日誌監控、平臺配置等。
構建API平臺是一項頗具挑戰性的任務，受制於過去銀行內部系統間報文結構的慣性，業務和技術部門的分隔也是巨大障礙。國內的先行者，有浦發銀行的API開放平臺和招商銀行的企業開放平臺，可以通過官網瞭解到。

（5）雲服務匯流排

隨著銀行業信息化的快速發展，各銀行都認識到雲平臺對銀行架構轉型的重要性，紛紛大力建設雲平臺。就來說說能幫助銀行實現行內系統之間、與合作伙伴或第三方系統間服務互通的CSB。
雲服務匯流排 CSB（Cloud Service Bus）提供平臺化的應用集成和服務開放能力，通過統一的服務管理，可以適配多種常見服務協議。CBS支持跨環境服務互通，主要用於專有雲、混合雲。
CSB可以把企業內外應用提供的服務發佈成API，供消費方訂閱調用，並提供審批授權、服務管控和計量監控等能力。不僅是內部服務開放到外部，還可以是內到內、內到外、外到內、外到外的靈活開放模式。

上圖來源於阿裡雲，這塊還不太瞭解，就不再展開，感興趣的朋友可以自行深入。接下來進入第二部分～

二、用集成技術與方式解決煙囪問題

1、集成技術介紹
不同的應用場景選用不同的集成技術，下麵就從系統間集成需求的角度來對系統集成技術進行分類，好讓大家對集成技術有更為深入的認識和思考。

應用功能交互是指系統間互相調用對方提供的功能或服務。數據交互是指系統間以獲取對方數據為目的的交互或數據傳輸，又可細分為輕量、批量（大量）。對聯機/實時查詢交易來說，也作為輕量的數據交互類型選擇合適的集成技術。
關於集成技術的簡述如下：

WebService(SOAP/HTTP)使用於快速與ESB平臺對接，是連接異構系統或語言的首選協議。它不依賴於語言和平臺，便可以實現不同的語言間的相互調用，通過Internet進行基於Http協議的網路應用間的交互，多用於同步通信模式。
JMS是一個Java平臺中關於面向消息中間件（MOM）的API，用於在兩個應用程式之間，或分散式系統中發送消息，進行非同步通信。Java消息服務是一個與具體平臺無關的API，絕大多數MOM提供商都對JMS提供支持。
RMI是遠程方法調用，允許運行在一個Java虛擬機的對象調用運行在另一個Java虛擬機上的對象。這兩個虛擬機可以是運行在相同電腦上的不同進程中，也可以是運行在網路上的不同電腦中，但不建議用於大數據量傳輸。
Socket是電腦之間進行通信的一種約定或一種方式，可以理解為一組較為穩定介面。通過socket約定，一臺電腦可以接收其他電腦的數據，也可以向其他電腦發送數據。
FTP簡稱為“文傳協議”，用於Internet上的控制文件的雙向傳輸，適用於非實時數據傳輸，使用客戶/伺服器模式，它屬於網路傳輸協議的應用層，能操作任何類型的文件而不涉及數據的加工轉換。
ETL是構建數據倉庫的重要一環，從數據源抽取出所需的數據，經過數據清洗，最終按照預先定義好的數據倉庫模型，將數據載入到數據倉庫中去
DBLink用於當前資料庫會話中訪問另外一個資料庫，適用於oracle資料庫之間的數據交互。
JDBC是一種用於執行SQL語句的Java API，可以為多種關係資料庫提供統一訪問，它由一組用Java語言編寫的類和介面組成。

不難看出，集成其實不是一項簡單的任務，需要瞭解銀行業務場景或問題後，經過反覆摸索和試錯，或者是向有經驗的集成架構師取經，才能學到套路。套路不是指可以複製粘貼的代碼，而是一些寶貴的建議或工作思路，使用得當，才能幫助我們解決集成目標與具體系統之間的鴻溝。

2、應用集成方式
為了尋找更好的應用集成解決方案，所以有不同的應用集成方式，大體上可以分為四種，按演化的順序和複雜度排序，分別是文件傳輸、共用資料庫、遠程過程調用和消息傳遞。
它們在解決某些特定領域的問題時都有自己的特長，而且每個應用都可以使用不同的集成方式，所以應當根據實際情況選擇最合適的。

（1）文件傳輸

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

當今商業銀行對數據分析的需求越來越多，系統之間的數據交互活動越來越頻繁，同時，銀行對數據文件傳輸的安全性、可靠性、審計性、完整性、可視化等需求也在不斷增加，如銀行對賬文件、賬單文件、批量轉聯機文件等，所以構建更有效的銀行文件傳輸平臺需求日益迫切。銀行文件傳輸平臺是銀行文件傳輸的重要工具，目前通用的文件傳輸技術包括文件拷貝、FTP文件傳輸協議、TCP/IP傳輸協議和HTTP協議等。除了技術外，建設時還要分析系統介面現狀，安全規範，應用場景，運維場景，監管要求和實施商。比如，納入銀行文件傳輸平臺的文件範圍，就需要考慮批量是否會影響聯機，因為聯機交易對時效性要求比批量更高；再如，與行外系統進行文件傳輸時，就需要考慮外聯機構的系統不支持行內現有傳輸工具，得充分與合作方進行溝通，確定合適的傳輸機制等。除了批量轉聯機文件，文件還有一個細分類型：文件通知，顧名思義即採用文件傳輸的方式進行通知信息的傳達。
例如，批量是非同步處理，調用者如何知道文件處理到哪一步了呢？可以通過一個查詢交易來跟蹤處理進度，也可以批量處理方處理完關鍵步驟後主動對外發送文件通知。總的來說，文件傳輸的優點和缺點優點如下：優點：

適合數據量大的情況，不會超時，不占用網路帶寬。
方案簡單（只要介面雙方約定好路徑、格式、處理方式即可），實現簡單、傳輸批量數據效率較高。避免了網路傳輸，網路協議相關的概念。

缺點：

不太適合做實時類的業務。
必須有共同的文件伺服器，存在安全風險，文件可能被篡改，刪除，或者存在泄密等。
格式沒有統一標準，標準性差，當改變文件格式的時候，需要各個系統都同步做修改。許多集成問題就是由於分析數據的方法不相容造成的。

（2）共用資料庫

共用資料庫相比文件傳輸來說，因為使用的同一個資料庫，所以交互更加簡單和靈活。通過資料庫的事務機制，可以做成可靠性的數據交換，保證了數據的一致性，而且時間特性更強。

讓所有應用都能在需要的時候，訪問任何共用數據是一個不錯的選擇。不僅能獲取到最新的數據，增強人們對數據本身的信任，而且還能減少因數據修改沒迅速傳遞給應用而造成的錯誤（如數據不一致）。

但如果所集成的所有應用都依賴於相同的資料庫，儘管各個應用能保證數據一致，但會大大增加系統間的耦合性。

例如，當多個應用通過共用資料庫頻繁讀取和修改相同的數據時，資料庫會成為一個性能瓶頸，如果各個應用都在對數據完成互斥操作時，還會引起死鎖。

當應用分佈在不同的位置、通過廣域網訪問同一個共用資料庫時，訪問速度可能過慢。分散式資料庫的話還會涉及數據存儲在哪台機器、是否會存在鎖定衝突等問題，都很容易在性能方面帶來災難。

而且多層級的組織架構下，協調各部門配合改用統一的資料庫，也是一項非常艱難的任務。

（3）遠程過程調用

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

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

（4）消息傳遞

採用消息傳遞實現系統間的協作和通信，有助於集成人員選擇不同的消息傳遞方式，如把消息廣播給多個接收者，或把消息路由給多個接收者之一，有助於將集成設計與應用開發分離，以及流量的削峰填谷、解決最終一致性問題等，是一種兼顧了性能、可靠性和松耦合的一種理想集成方式。
（消息路由：指消息發送者不知道消息發送到哪裡，它可以將數據發送給一個消息路由器，由它將數據轉發給適當的接收者。）
非同步處理是消息傳遞的主要應用場景之一。當業務或流程處理過程發送一個消息時，通信雙方不需要同時線上等待，任何一方只需各自處理自己的業務。
舉些生活里的例子。
比如在打電話的時候，我們是期望被呼叫的一方能夠實時響應，如果不在或者忙的話，發起呼叫的一方只能幹等，一旦超過時間會自動結束。就好比系統中的多個應用通信時，一個應用的失敗引發所有其他應用也失敗，這就是系統的健壯性不夠。
再如發送手機簡訊，發送消息之後可以準確的送達到對方，無需保持等待狀態。接受簡訊的一方，等空閑時會進行回覆。就類似系統中的非同步處理。能降低系統響應時間，提高系統性能和吞吐量，而且由於非同步處理在不同的服務間，可以隔離服務，避免雪崩。