銀行核心系統之應用集成

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

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

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、 集成技術介紹
不同的應用場景選用不同的集成技術，下面就從系統間集成需求的角度來對系統集成技術進行分類，好讓大家對集成技術有更為深入的認識和思考，

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

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

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

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

（1）檔案傳輸

檔案傳輸是最簡單的應用集成方式，因為檔案是一種通用的存盤機制，各系統都有具備該功能，集成人員不必了解應用的內部細節，
通常是由各應用小組提供檔案，然后約定檔案服務器地址、檔案命名規則、檔案內容格式等內容，再通過上傳檔案到檔案服務器進行資料互動即可，     

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

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

 缺點：

1. 不太適合做實時類的業務，
2. 必須有共同的檔案服務器，存在安全風險，檔案可能被篡改，洗掉，或者存在泄密等，
3. 格式沒有統一標準，標準性差，當改變檔案格式的時候，需要各個系統都同步做修改，許多集成問題就是由于分析資料的方法不兼容造成的，

（2）共享資料庫

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

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

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

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

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

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

（3）遠程程序呼叫

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

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

（4）訊息傳遞

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

從技術平臺的開發人員來說，實作訊息傳遞方式的細節有一定的學習曲線，意識到比遠程程序調動更慢，但同時也會促使他們設計出高內聚和低耦合的組件；對應用開發人員來說更加靈活，同步或異步都能通過訊息介面完成具體內容的發送和接受，

在分布式架構中，訊息傳遞只是作為訊息中心基礎技術組件的功能之一，高流量、高并發、分布式的情況下，訊息可能會產生積壓、延遲或丟失，導致一致性難以保證，那么就需要訊息中心輔助業務補償機制，保證最終一致性，

目前業內有多個主流訊息中心產品，從實作訊息中心的開源技術來看，典型的有RabbitMQ，ActiveMQ，RocketMQ，Kafka，網上有很多資料可以參考，

還沒細看，有時間再研究研究，

參考書籍或文獻：

1.阿里巴巴.《云棲大會》,2020年

2.笨鳥兒.《應用系統間資料傳輸方式總結》,2018年

3.monkey01.《傳統銀行架構變遷》,2017年

4.網路.《幾種企業應用集成方式的比較》,2017年

5.王漢明.《銀行資訊系統架構》,2015年

6.美國侯珀.《企業集成模式》,2006年

作者丨代堂鳴

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Application-integration-of-core-banking-systems.html

標籤：架構設計

上一篇：HTTPS涉及的加密演算法講解

下一篇：軟體設計第一課