高品质的音视频能力是怎样的? | Qcon 全球软件开发大会·上海站邀请函 了解详情
写点什么

传统银行 IT 如何落地区块链技术?| 架构师必备参考

  • 2018-06-06
  • 本文字数:3367 字

    阅读完需:约 11 分钟

为什么要上区块链系统

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

不管对我们还是银行来说,正常逻辑是,要考虑清楚哪些产品适合使用区块链架构实现,哪些不适合。(当然,也有情况除外)这里参考了段新星在钛坦白的分享实录( 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 集群,让服务调用方(银行各类应用)能够方便地找到区块链节点,保证全程无单点。

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

2018-06-06 18:152008

评论

发布
暂无评论
发现更多内容

iOS面试--拼多多最新iOS开发面试题

一意孤行的程序员

ios swift 面试 ios开发 知识分享

阿里云原生开源大家族加入中科院软件所开源软件供应链点亮计 - 暑期 2021

阿里巴巴云原生

开源 容器 微服务 开发者 云原生

我粉了!阿里大牛从内部带出来的百亿级高并发系统,从基础到实战、面面俱到

Java 程序员 架构 面试

超级详细!全网独家首发的SpringCloud Alibaba 到底有多强?

Java 程序员 架构 面试

华为HMS生态和1+8+N的交叉点,点透棋局的华为帐号

脑极体

Nginx的11个执行阶段详解

运维研习社

nginx 运维 源码剖析 5月日更

记十亿级Es数据迁移mongodb成本节省及性能优化实践

杨亚洲(专注MongoDB及高性能中间件)

MySQL 数据库 mongodb 架构 分布式数据库mongodb

推荐计划 | 推荐好友用 CODING,获高额返现奖励

CODING DevOps

团队管理 敏捷开发 研发工具 开发团队

高级软件工程师必备的五大技能

架构精进之路

5月日更

Kubernetes 普及系列:容器基础入门

CODING DevOps

Kubernetes

仰望天空,脚踏实地 —— CODING OKR 全新上线

CODING DevOps

团队管理 OKR

飞猪基于 Serverless 的云+端实践与思考

阿里巴巴云原生

Serverless 容器 运维 云原生 监控

5分钟速读之Rust权威指南(八)

码生笔谈

rust

Spark知识点简单总结

五分钟学大数据

大数据 spark 5月日更

每个开发人员都应该知道的 10 个 GitHub 仓库

LeanCloud

GitHub web开发

字节跳动Java岗一二三面全经过分享

北游学Java

Java 字节跳动 面试

☕【JVM 技术之旅】让你完全攻克内存溢出(OOM)这一难题(上)

洛神灬殇

JVM OOM 异常 Exception 5月日更

百度 Serverless 架构揭秘与应用实践

百度开发者中心

百度 开源 Serverless 云原生

部署混合云环境的5大挑战

浪潮云

云计算

简单了解 MySQL 中相关的锁

SH的全栈笔记

MySQL 后端

2021 DevOpsDays 东京站完美收官 | CODING 专家受邀分享最新技术资讯

CODING DevOps

DevOps CI/CD

玩转直播系列之消息模块演进(3)

vivo互联网技术

Java 服务器 消息系统 直播技术

Hive窗口函数与分析函数

大数据技术指南

hive 5月日更

首届HarmonyOS开发者创新大赛颁奖典礼于深圳召开

科技汇

参与 Apache 顶级开源项目的 N 种方式,Apache Dubbo Samples SIG 成立!

阿里巴巴云原生

开源 开发者 云原生 dubbo 中间件

MindSpore:不用摘口罩也知道你是谁

华为云开发者联盟

算法 人脸识别 口罩 mindspore 口罩人脸

并发王者课 - 青铜 3: 双刃剑-理解多线程带来的安全问题

MetaThoughts

Java 多线程 并发 王者并发课

ETL-KETTLE工具使用

this

Java 数据 数据同步 ETL

程序员写好技术文章的几点小技巧

阿里巴巴云原生

程序员 云原生 写作 写作技巧

阿里P9架构师强烈推荐:想拿60W以上年薪必看,Java高并发四套小册。

Java架构追梦

Java 阿里巴巴 架构 面试 高并发

做一次黑客,入侵一次服务器

叫我阿柒啊

Docker 入侵 docker远程 redis注入

传统银行IT如何落地区块链技术?| 架构师必备参考_语言 & 开发_本体_InfoQ精选文章