傳統銀行IT如何落地區塊鏈技術？| 架構師必備參考

為什麼要上區塊鏈系統

在落地工作啟動之前，還是要費點口舌來談談這個話題。

不管對我們還是銀行來說，正常邏輯是，要考慮清楚哪些產品適合使用區塊鏈架構實現，哪些不適合。（當然，也有情況除外）這裏參考了段新星在鈦坦白的分享實錄（ http://www.tmtpost.com/2694378.html?from=timeline&isappinstalled=0 ），文章提出了應用三原則，我覺得點的非常到位，這裏我補充一些銀行緊密相關的說明。

定律一，「不要拿大炮打蚊子」，區塊鏈技術更適宜於資產網路（Assets Over IP），針對這點，銀行本身從事的就是資產相關業務，比較匹配。

定律二，使用區塊鏈，一定是要有多方寫入資料的需求

如果把區塊鏈作為一種資料庫而言，這裏邊非常突出的特色就是：它是一個天生去適應多方進行協作的資料庫，一個單一的寫入者寫入資料的資料庫可以搞定的，就不需要用區塊鏈。所以，在這裏一定有多方協作需求。

定律三，區塊鏈產品一定是天然的弱中心化的

區塊鏈做在國內支付基本沒有可能，因為中心化平臺已經足夠強勢和足夠好的體驗，比如支付寶、微信、銀聯。但用區塊鏈做打通多個不同國家商家、金融機構的跨境匯款、清算結算的成功案例則不少。原因也是很簡單，後者在複雜多邊市場中，缺乏「中心協調者」，存在嚴重對手風險的交易困境。比如，信用證就是一個很好的應用場景，今年 7 月份，中信銀行已與民生銀行合作推出首個銀行業國內信用證區塊鏈應用，併爲銀行拓展國際結算、貿易融資等業務提供支撐。

另外，需要補充的是，在現階段銀行體系使用區塊鏈來解決運營效率、降低運營成本也是一個非常明顯的應用點，比如：招商銀行通過區塊鏈技術改造的跨境直聯清算業務將正式實現商用，實現了總行與海外分行各節點的資金清算，並將報文傳遞時間由 6 分鐘縮減至秒級。

典型融合架構

以下為典型的銀行現有 IT 和區塊鏈的融合架構。部署在銀行的區塊鏈節點會在應用層、業務層、資料層和銀行現有 IT 發生互動。

應用層：銀行 IT 應用層，比較典型的，比如國際結算系統、外匯交易系統、支付系統等等，將會和區塊鏈的連線層發生互動，通過 Restful API 發起區塊鏈交易或者通過 WebSocket 機制接受區塊鏈區塊和交易結果。

業務層：通常風險控制策略、支付清算規則、AML 規則在這一層制定，區塊鏈通過智慧合約（或稱：鏈上程式碼 chaincode）寫入和交易關聯方相關的業務規則，比如風控規則、清算分潤等都可以通過智慧合約寫入。

資料層：區塊鏈一般採用 K/V 資料庫，適合區塊鏈實現不間斷鏈式儲存和簡單資訊的儲存，並不支援 SQL 語句複雜查詢，當然也無法支撐進一步資料分析、挖掘。比如，在我們在一商業銀行落地數字資產專案，基於 UTXO 的賬戶模型需要被抽取、加工，進入到行內的 AML 規則庫進行資金流向監管，實現資金的精準投放。同時，銀行資料層通常有更完善的容災備份策略。所以，架構方案配套為關係性資料庫（Oracle/DB2/Mysql/…）提供資料匯入功能，一方面作為資料安全儲存需要，一方面為資料再加工提供資料來源頭。

對賬模式的變化

以哪裏的賬目爲準，對賬週期怎麼設定，在銀行 IT 中一直是一個很原則性問題，系統融合區塊鏈之後，這兩點需要重新理解，並使用新的規則來實現。我們在一些落地專案中，需要花費很多精力來讓銀行 IT 人員理解在區塊鏈模式下實現新的對賬模式。

我們以基於銀聯的跨行支付系統為例，來看一下傳統對賬模式。

清分一般發生在 T 日日終（比如 23:00），銀聯完成清分後，向各個成員機構下發清分檔案，各個成員銀行根據中心的清分檔案來對賬，注意哦，一定要以銀聯爲準。

PS：淸分 Clearing 是指對交易日誌中記錄的成功交易，逐筆計算交易本金及交易費用（手續費、分潤等），然後按清算物件彙總軋差形成應收或應付金額。簡言之，就是搞清楚今天應該向誰要多少錢？應該給誰多少錢？

相比現有中心機構模式，基於區塊鏈模式下，每隔一段時間（一般幾秒到十幾秒之間）會生成區塊（Block）的生成，這個區塊中的交易明細已經在各個參與方節點的共識過程中形成一致性賬本，意味著對賬時時刻刻都在進行。所以，新的對賬模式應調整為：

1. 日終對賬變為實時對賬
2. 以中心機構（如：銀聯）爲準或者行核心心繫統爲準轉變為以區塊鏈賬務爲準。

由此可以看出，顯而易見的好處是：效率提高了，配合以良好的交易機制（在下一章節提到），可以將差錯賬發生率較低到幾乎為零。

解決事務一致性

我們在某銀行的一個數字資產專案中，探討一個場景「數字資產提現」，這個場景要求先從區塊鏈做完成數字資產提現交易，同時在銀行本地賬務系統進行賬戶相關賬務操作，這兩個動作要求實現事務一致性。

在銀行現有系統架構中，事務一致性保證有一些傳統做法，最簡單的是通過本地關聯式資料庫的強一致性來實現本地事務的一致性；或者是通過設計一些衝正交易模式來進行交易回滾；再者通過兩階段提交協議（2PC）來實現。

針對區塊鏈交易以上均無法支援，原因很明顯，一、區塊鏈節點是獨立應用，無法通過本地事務實現；二、區塊鏈使用的資料庫是 NoSQL 資料庫，這些非關係型資料庫無法支援 2PC；三、區塊鏈沒有交易回滾（Rollback）機制，只要區塊上的交易，無法通過沖正交易回滾。

解決思路是 從微服務架構中尋找事務一致性的解決方案 。其實區塊鏈應用節點就是一個獨立微服務。

微服務的實現事務一致性的模式有三種，可靠事件模式、業務補償模式、TCC 模式。其中最適合的是可靠實現模式，某種情況下可以使用業務補償模式。原因是：TCC 模式，要求支援 Cancel 操作，區塊鏈均不適合。 綜上，我們建議使用基於外部事件系統的可靠事件模式來保證交易一致性 。

具體方案設計如下：

外部事件系統記錄事件訊息全流程狀態，從上圖可以看出，從 1-5 是正常交易流程，其中可能發生異常情況：

• 區塊鏈交易失敗
• 區塊鏈交易成功，但沒有通知到事件系統
• 賬戶系統交易失敗（可能沒有收到，也可能處理失敗）
• 賬戶系統交易成功，沒有通知到事件系統

對賬處理程序定時從事件系統庫中找出 A）已經登記的，但沒有收到交易出塊通知的交易 B）賬戶系統未置「完成」的交易。

針對 A，對賬處理程序從區塊鏈中進行查詢（包括對比區塊，是不是已經過了超過 2 個以上區塊），如果區塊鏈沒有完成交易，則將事件置「取消」，解決第一種異常；如果區塊鏈交易成功，則更新事件狀態為「待賬務系統處理」，並送入訊息佇列，解決第二種異常；

針對 B，再次通知賬戶系統，觸發賬戶系統再次處理（本操作可以根據情況，設定多次），解決第三種和第四種異常。

PS：賬戶系統需要實現冪等性，不能因為重複收到事件而多次重複記賬！

補充說明，賬戶系統對於記賬失敗可以反交易處理，在其他場景，我們也可以設計事務補償的模式。平臺使用服務編排的方式降低這種模式的開發複雜度。

身份實名化及金鑰管理

在公有區塊鏈最初當中，均不需要進行身份實名，金鑰管理也是交給個人自行管理。對於金融行業應用區塊鏈，顯然既不符合監管，也沒法滿足銀行商用標準，所以，針對銀行聯盟鏈來說，最重要需要實現兩個目標：

1. 鏈上身份實名化
2. 資產控制金鑰的可管理，包括掛失、找回這樣的異常管理

對此，我們建議的方案如下：

1. 對於身份實名，基於銀行已有成熟驗證通道，我們建議藉助銀行現有的二、三類賬戶驗證模式和 KYC，比如銀行卡四要素的認證方式。
2. 鑑於使用者對銀行的信任度很高，金鑰管理方案建議採用「可選託管方案」，使用者可以選擇自行生成和管理金鑰，或者在使用者許可下，由銀行為使用者託管金鑰，並通過安全方式下發給使用者終端，這樣使用者可以通過自己實名身份進行掛失、找回等。具體如下說明。

高可用的部署架構

銀行 IT 對高可用一直有極高的要求，區塊鏈的構建需要完全支援高可用（HA）的部署架構。

我們建議使用微服務架構建立區塊鏈服務叢集，區塊鏈節點僅是一個邏輯概念，它由多個可自由伸縮的物理節點構成。

目前業界比較成熟的微服務框架有 Netflix Spring Cloud、Apache ZooKeeper 等。方案並不侷限某一框架，我們以使用 Spring Cloud 提供的 服務註冊（Eureka）、服務發現（Ribbon）框架為例，具體的部署方案如下。

PS：每個銀行在各自 HA 方案中有各自標準，基於微服務的架構方案僅為一種選擇，具體情況可以根據銀行 HA 總體方案調整。

以上我們將所有區塊鏈節點以服務註冊到 Eureka 叢集，讓服務呼叫方（銀行各類應用）能夠方便地找到區塊鏈節點，保證全程無單點。

其中區塊鏈叢集中可以設定效能比較好的物理機器作為記賬節點，其他作為提供服務響應作用或資料備份作用的輕節點。