（InfoQ）传统银行IT如何落地区块链技术

2018-6-13 架构之家 传统银行IT如何落地区块链技术？| 架构师必备参考 | 出处：http://www.infoq.com/cn

为什么要上区块链系统

在落地工作启动之前，还是要费点口舌来谈谈这个话题。

不管对我们还是银行来说，正常逻辑是，要考虑清楚哪些产品适合使用区块链架构实现，哪些不适合。（当然，也有情况除外）这里参考了段新星在钛坦白的分享实录（http://www.tmtpost.com/2694378.html?from=timeline&isappinstalled=0），文章提出了应用三原则，我觉得点的非常到位，这里我补充一些银行紧密相关的说明。

• 定律一，“不要拿大炮打蚊子”，区块链技术更适宜于资产网络（Assets Over IP）。针对这点，银行本身从事的就是资产相关业务，比较匹配。

• 定律二，使用区块链，一定是要有多方写入数据的需求。如果把区块链作为一种数据库而言，这里边非常突出的特色就是：它是一个天生去适应多方进行协作的数据库，一个单一的写入者写入数据的数据库可以搞定的，就不需要用区块链。所以，在这里一定有多方协作需求。

• 定律三，区块链产品一定是天然的弱中心化的。区块链做在国内支付基本没有可能，因为中心化平台已经足够强势和足够好的体验，比如支付宝、微信、银联。但用区块链做打通多个不同国家商家、金融机构的跨境汇款、清算结算的成功案例则不少。原因也是很简单，后者在复杂多边市场中，缺乏“中心协调者”，存在严重对手风险的交易困境。比如，信用证就是一个很好的应用场景，今年 7 月份，中信银行已与民生银行合作推出首个银行业国内信用证区块链应用，并为银行拓展国际结算、贸易融资等业务提供支撑。

另外，需要补充的是，在现阶段银行体系使用区块链来解决运营效率、降低运营成本也是一个非常明显的应用点，比如：招商银行通过区块链技术改造的跨境直联清算业务将正式实现商用，实现了总行与海外分行各节点的资金清算，并将报文传递时间由 6 分钟缩减至秒级。

典型融合架构

以下为典型的银行现有 IT 和区块链的融合架构。部署在银行的区块链节点会在应用层、业务层、数据层和银行现有 IT 发生交互。

典型的银行现有 IT 和区块链的融合架构

• 应用层：银行 IT 应用层，比较典型的，比如国际结算系统、外汇交易系统、支付系统等等，将会和区块链的连接层发生交互，通过 Restful API 发起区块链交易或者通过 WebSocket 机制接受区块链区块和交易结果。
• 业务层：通常风险控制策略、支付清算规则、AML 规则在这一层制定，区块链通过智能合约（或称：链上代码 chaincode）写入和交易关联方相关的业务规则，比如风控规则、清算分润等都可以通过智能合约写入。
• 数据层：区块链一般采用 K/V 数据库，适合区块链实现不间断链式存储和简单信息的存储，并不支持 SQL 语句复杂查询，当然也无法支撑进一步数据分析、挖掘。比如，在我们在一商业银行落地数字资产项目，基于 UTXO 的账户模型需要被抽取、加工，进入到行内的 AML 规则库进行资金流向监管，实现资金的精准投放。同时，银行数据层通常有更完善的容灾备份策略。所以，架构方案配套为关系性数据库（Oracle/DB2/Mysql/...）提供数据导入功能，一方面作为数据安全存储需要，一方面为数据再加工提供数据源头。

对账模式的变化

以哪里的账目为准，对账周期怎么设定，在银行 IT 中一直是一个很原则性问题，系统融合区块链之后，这两点需要重新理解，并使用新的规则来实现。我们在一些落地项目中，需要花费很多精力来让银行 IT 人员理解在区块链模式下实现新的对账模式。

我们以基于银联的跨行支付系统为例，来看一下传统对账模式。

image

清分一般发生在 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 集群，让服务调用方（银行各类应用）能够方便地找到区块链节点，保证全程无单点。

其中区块链集群中可以设置性能比较好的物理机器作为记账节点，其他作为提供服务响应作用或数据备份作用的轻节点。