【开源应用 案例共享】微众银行——金融级云原生消息总线及事件网格平台建设

时间:2023-01-30 12:14:44

2021年10月,中国人民银行等联合发布了《关于规范金融业开源技术应用与发展的意见》(银办发〔2021〕146 号),规范金融机构合理应用开源技术,提高应用水平和自主可控能力,促进开源技术健康可持续发展。前期,为助力成员单位做好开源技术应用与发展工作,北京金融科技产业联盟开源专委会组织了金融业开源技术应用、创新等方面的案例征集,现对部分优秀案例进行宣传,发挥先进典型示范引领作用

一 案例背景

实施背景

微众银行作为一家纯线上银行,为满足互联网客户的7×24业务服务需求,对系统的可用性有着极高的要求。同时为更好地提供普惠金融能力,微众银行也需要走出一条“高效率、低成本、广覆盖”的创新之路。因此,微众银行基于开源技术自研了分布式金融级消息总线,实现了对商业消息总线产品的全部替换,实现了完全自主可控,同时在两地三中心的基础上,基于分布式金融级消息总线的多活特性,启动和实施了全行业务系统同城多中心多活的规划和建设,实现同城任何一个数据中心故障不影响对客户的业务服务,为普罗大众提供更加可靠的金融服务。

业务需求

为达到分布式架构基础组件的安全可控,支持海量业务的发展,加强同城数据中心容灾能力,进一步提升业务连续性管理水平,本项目目标是建立分布式消息总线替换集中式总线,支持多中心多活特性,实现应用系统的同城多数据中心多活改造,即应用系统在任一数据中心内不可用时,能自动由同城其他数据中心接替进行业务处理,对外继续提供服务。量化来看,分布式消息总线的设计目标为:消息总线的容灾能力达到同城RPO=0、同城RTO接近于0。

存在的痛难点问题

1)消息总线支持分布式部署,每个组件均能进行独立的扩展,升级,任意一个节点不可用,总线仍然能提供服务。 

2)分布式消息总线提供多中心多活的特性支持,系统在同城多个数据中心部署,应用无状态,单个数据中心故障时,能够通过同城其他数据中心的机器继续提供服务。

3)分布式消息总线对机器及网络故障进行快速的自动隔离,降低故障对业务的影响。改造过程的风险控制,实现平滑改造,减少对业务的影响。

解决思路

在应用层面,任意一个DCN在同城两个或两个以上数据中心部署、单个DCN内应用部署两个或两个以上的实例,实现应用多中心多实例多活部署,应用在多中心同时提供服务,确保同城任一中心出现故障时,还有其他数据中心的应用实例继续提供服务。

在系统间通讯层面,通过消息总线支持跨IDC的消息转发,打通三中心间的应用通讯,使应用对消息流向无感知。同城三中心任一数据中心出现故障时,自动将消息流转至其他数据中心,由其他数据中心的下游应用继续接收和处理消息。在系统间通讯时,遵循数据中心内优先访问的原则,以减少跨数据中心的通讯流量和端到端的交易延迟,提高系统间通讯的质量和稳定性。

二 创新成效

技术方案

2015年10月至2016年2月,期间主要完成了分布式消息总线的开源选型和架构概念设计、可行性评估和技术架构的高层设计。提交了分布式消息总线设计方案。

为了尽可能不重复造*,微众银行对比选型了一些开源产品,RocketMQ是一款开源的分布式消息队列产品,采用Java语言开发,相对于其他类型产品的优势在于,分布式设计,组件自包含无第三方依赖,架构比较简单,易于改造。同时在DCN化、多播、request-reply等特性、熔断、限流、故障隔离等机制、多语言接入支持,DevOps运维治理工具等方面都十分欠缺,需要重新设计开发。

2016年2月至2017年2月,期间主要完成了分布式消息总线的研发,并开始进行生产灰度测试,逐步开始替代集中式的消息总线。2017年3月至2017年10月,期间主要开始分布式总线替换集中式总线的流量的切换灰度以及完成了消息总线多活的改造。2019年9月,基于微众银行整体开源战略,将实践成果对外开源,定位为分布式金融级消息总线,项目名为DefiBus;2020年,剥离出EventMesh开源项目,致力于打造一个动态的云原生事件驱动架构基础设施。 

【开源应用 案例共享】微众银行——金融级云原生消息总线及事件网格平台建设

 

EventMesh事件网格

【开源应用 案例共享】微众银行——金融级云原生消息总线及事件网格平台建设

多活架构

【开源应用 案例共享】微众银行——金融级云原生消息总线及事件网格平台建设

 

技术创新

1)支持同步、异步、多播、广播等调用方式,系统间调用不需要指定所在部署区域,只需指定服务名,消息就能够自动进行路由,解耦了系统间的依赖,同时也解耦了系统和数据中心的部署关系,提升了数据中心的利用率。

2)消息总线是分布式设计和部署的、每个组件都分散在不同的数据中心,不同的机架,不同的服务器上,任何一个组件都是集群部署,可以单独对某个节点进行在线升级、对某个组件进行在线扩容,对业务无影响。

3)消息总线是多中心多活设计,在多个数据中心都有部署,当其中一个数据中心的总线服务全部不可用时,可以自动切换到其他数据中心可用的总线服务上去,对业务无影响。

4)由于部署在普通的X86和ARM服务器上,对于经常发生故障的机器,以及网络中断等异常情况,总线能够自动判断故障并迅速自动隔离,并在机器和网络恢复后,自动恢复总线服务。

5)总线能够感知下游系统故障,通过熔断机制将消息切换到另外可用的服务上去、对于处理能力下降的系统,总线能够通过限流机制保护系统不至于崩溃、各系统变更时可独立进行变更,无直接关联影响,且具备逐台机器进行灰度发布的能力。

6)总线设计支持高并发、消息能在毫秒级低延时进行流转,提升业务处理能力。

业务创新

  • 提高了全行业务连续性水平

  • 优化了跨数据中心系统间调用的机制

  • 提升了系统跨数据中心部署的灵活性

  • 提高了服务器利用率、降低了硬件设施成本

  • 改造过程整体风险可控,可快速复制

  • 降低了故障机器对于业务的影响

三 产业价值

该项目加强了基础架构的安全可控能力,提升了同城数据中心容灾能力,进一步提升了业务连续性管理水平,实现了分布式消息中间件的安全自主可控。采用被广泛使用和生产验证的开源技术组件作为底层实现,并基于开源组件,结合金融场景,定制开发了很多特有的高可用特性,解决了很多开源组件没有解决的问题,并在生产环境进行了多次故障演练,有效地降低了机器故障对业务的影响,验证了消息总线的安全可靠性,符合架构安全性要求。

分布式消息总线支撑的多数据中心多活特性,实现了同城 RPO=0,同城RTO接近于0,系统在同城任一数据中心内不可用时,能由同城其他数据中心接替进行业务处理,对外继续提供服务,确保系统服务的高可用性。有效保护客户的资金和业务安全,使客户权益得到进一步的保障。分布式消息总线架构是基于分布式架构、面向全行所有业务的架构,项目的成功验证了分布式消息总线架构在银行业实施的可行性。

业界首次创新性提出的EventMesh事件网格中间件,目前已进入全球最大开源基金会Apache软件基金会孵化。它可以用于分离应用和中间件层,在事件驱动型应用的编排场景,SaaS组合式应用的标准接入场景,事件总线场景,以及多云混合云的联合治理场景等等,有着广泛的应用前景,适合全行业推广。