实战 | 数字银行的云原生中间件探索与实践

欢迎金融科技工作者积极投稿！

投稿邮箱：[e-mail]

                                          ——金融电子化

      

文 / 微众银行基础科技产品部  卢道和  陈广胜

众所周知，中间件基本上都是有状态的应用，在整个IT架构中承担了非常核心的职责，对于IO、性能、稳定性的要求都非常高，所以一直以来中间件的容量管理、交付、运维、容灾都是业界难题。

云原生的出现，为中间件的探索与实践带来了一种新的建设思路和开发模式。从技术特征来看，云原生所具备的极致弹性能力、服务自治、故障自愈能力、大规模可复制能力，极大地发挥了云的优势，加速了数字基础设施升级的进程。然而，云原生技术的落地门槛非常高。经过市场几年的炒作和洗礼，技术也经历了蛰伏期，云原生出现了新形态，将成为驱动业务增长的重要引擎，迎来规模化落地的进程。

微众银行基础科技产品部总经理    卢道和

应“云”而生，生生不息

作为国内最早成立的数字银行，微众银行依托云的技术优势，结合银行的业务特点，设计并实践了基于XML（X86服务器、MySql、Linux）的金融级分布式架构，该架构具有低成本、高可用性、高弹性、高规范性、高性能、低风险的特点，支持了亿级用户量、日均亿级交易量。微众银行在中间件领域探索出了一条独具特色的架构实践之路。

从应用的视角来看，微众银行的服务演进大致分为以下几个阶段：分布式服务、多活服务、容器化服务、云原生服务。

分布式服务，作为我们的设计初衷，也是为了满足业务增长需要。业务应用需要从传统的集中式单体应用开发模式转向分布式开发模式，改造的过程需要接入分布式中间件及服务治理体系。

首先应用系统需要按照职能、业务功能等维度进行拆分，形成了子系统，按业务类型划分出不同的服务，根据服务类型进行同步异步区分。当子系统作为服务提供方时，需要定义自己提供哪些服务，作为服务消费方时，需要定义消费哪些服务。当子系统作为事件订阅方时，需要定义自己需要订阅哪些事件，作为事件发布方时，需要发布哪些事件。当作为服务提供方和事件订阅方时，子系统也需要定义部署在哪些单元化DCN里面，方便中间件对服务消费方和事件发布方进行动态化路由选择。这些调用关系及部署信息都会登记注册到服务治理系统里面进行管控。

服务形态的演变，必然伴随着中间件架构的演进，在这个服务模型的定义下，微众银行中间件的演进经历了几个阶段：消息总线1.0、消息总线2.0、EventMesh、ServiceMesh。

消息总线1.0版本，服务和事件均以消息主题（topic）的形式存在，提供了同步RPC（request/reply）和异步MQ（pub/sub）的通信能力，二者都是基于MQ实现。对于应用来说，只需要引入一套开发框架即可，给开发带来了便利。整个分布式应用架构引入了单元化DCN设计，中间件需要动态地将交易路由到对应的DCN里面。由于系统组件与应用松耦合，消费者出现任何问题（升级停服、宕机、不可用等），都不会影响生产者的业务。遇到突发的海量消息压力，消费者还可以持续平稳且高效地处理消息，系统可用性效率高。消息总线具备持久化机制，系统发生故障时不会丢失消息。

1.0版本中间件虽然很好地解决了海量分布式服务的通信问题，但在实际生产运营过程中，也发现了一些问题。中间件主节点硬件发生故障时，会触发HA切换，恢复过程会有几十秒的中断；同时，SAN存储故障也会导致中间件短暂不可用。另外由于中间件跨节点消息通过Bridge转发，网络异常的情况会导致Bridge不稳定。这些因素都可能直接导致一组或多组DCN应用的短暂不可用，在早期还没有做多活架构的情况下，这样的中断在金融交易场景，尤其交易量大的时段是不能接受的。在运维便利性上，由于业务的扩张带来DCN的增多以及调用关系的复杂，使得中间件的扩容以及bridge路由策略的配置变得更加复杂，尤其是在DCN和IDC切换的时候，运维人员对配置工具的准确性和稳定性的依赖程度很高，毫无疑问这些都不利于生产的稳定运营。

随着业务发展的突飞猛进，对中间件提出的要求越来越高，这些问题的优化刻不容缓。更重要的是，由于中间件核心是闭源的，即便发现了问题，也无法进行修改和改进，这更加坚定了自主研发的决心。早在2015年，开源中间件技术方兴未艾，我们就深度参与到了开源社区，并基于开源版本深度定制开发了中间件2.0版本。

2.0版本中将同步异步区分开，同步采用“Active-Active”+Master模式，异步采用“Active-Active”+“Master-Slave”模式，全网无单点。该架构完全自主设计开发，近30万行代码，累计处理了万亿级消息。机器故障及断网情况下，最快秒级、最慢1分钟自动隔离；3000TPS交易场景下，耗时略有增加，在途交易失败小于100笔，成功率几乎不变。此外，还实现了在线流量治理的工具自动化，变更操作都可以让应用无感，大大降低生产故障风险和操作风险，保障业务稳定。

为了实现服务多活，进一步提升架构可用性和可靠性，在单IDC集群高可靠的基础上，消息总线继续探索支持多中心多活能力。应用可在多中心灵活部署，当需要进行IDC切换时，中间件可以自动将交易流量在多中心之间进行调拨，不需要对应用进行人为干预。中间件多活能力的上线，盘活了资源，使原先备节点可以参与支撑交易流量，大大提升了资源利用率。

生于“云”、长于“云”

微服务架构下容器技术的兴起，进一步提高了部署效率，具备资源弹性和服务化能力的云原生技术逐渐成为服务平台的基础。金融业务在安全稳定的核心原则下，容器技术解决了服务及中间件自身的运维、交付问题，帮助使用者屏蔽了底层的运行环境差异，降低了运维复杂度。使用者通过标准化的API就可以完成对中间件的调用，其好处在于让中间件逐渐基础设施化，开发者可以更关注业务的开发，从而提升企业整体的开发和运维效率。

在云原生出现之前，微众银行就遇到了中间件SDK升级及多语言应用接入的困难，两个因素叠加之后，每一次新版本发布，业务应用不仅要安排版本验证，还要面临大规模发版的问题，除了增加了工作量，也会有潜在风险。如果这些升级像服务端变更一样对应用不可见，将会带来非常大的便利。于是尝试探索轻量化SDK，甚至是无侵入式的接入方式，尽量将非功能性需求收敛到代理，而代理本身可以随着容器一起融入到运行环境里，成为基础设施。这个思想与后来出现的云原生理念不谋而合，如图1所示。

图1  云原生服务

微众银行的服务容器化率接近90%，借助Kubernetes+docker的底座，将资源进行池化，按需分配、错峰使用、在快速扩容及批量场景下，相对于虚机环境有着明显的效率优势。容器有弱隔离性的特点，服务之间互相干扰更小。服务一旦被构建为不可变的容器镜像，便可以多处运行，更有利于环境的复制和迁移。

微众银行的云原生将服务分为请求响应类型和事件驱动类型。ServiceMesh可以很好地支持常见的HTTP和RPC调用，EventMesh可以对ServiceMesh进行更好地补充，支持异步和事件驱动类型的服务，动态地将事件路由到订阅方，并且可以对微服务进行编排。服务默认容器部署，享受部署的便捷，对于一些不能容器化的服务，中间件依然能够支持接入。

EventMesh的前身，是在消息总线2.0时代，很多非Java语言应用接入中间件，无需为每个语言都开发一套复杂的SDK，而是将通用的逻辑收敛到一个Access代理中，简化并标准化SDK与Access之间的协议。因为SDK的逻辑很轻量，每新增一个语言，就能很快的支持，并且SDK的升级频率大大降低，Access的升级对服务是无感的。在云原生时代，经过架构升级，演化出现在的EventMesh事件驱动架构。

EventMesh提供了统一的事件源接入方式，为函数工作流服务提供SaaS应用事件或云服务事件的标准化接入。SaaS应用/云服务将产生的事件发送到事件网格中，事件网格对事件进行校验、过滤、路由和转化，然后推送给已经订阅事件的函数，触发函数执行业务处理逻辑。也可以作为云服务的标准事件中心，实现各个云服务之间的联动。应用产生的事件可以通过事件网格触发其他相关联的应用，从而实现应用与应用之间的事件流转。

EventMesh是一个计算存储分离的微内核插件架构，这也是云原生的设计理念。EventMeshRuntime定位是一个计算组件，用于处理不同的Pub/Sub协议（HTTP/gRPC/CloudEvents/MQTT/AMQP），并且对这些事件进行过滤、路由、编排后，可以通过不同的Connector将事件持久化到不同的EventMeshStore（RocketMQ/Kafka/Pulsar/Redis/Mysql/Pravega/Knative/workflow）里面；同时这些事件可以通过标准的OpenTelemetry和Prometheus协议插件进行观测，也可以通过ACL插件进行安全管控。

EventMesh完全自主研发，并已于2021年经过全球最大的开源基金会Apache全票通过进入孵化器孵化，成为全球金融业首个进入开源孵化器的开源项目，并有望在近期毕业成为顶级项目。目前参与到开源社区的不仅有来自华为、阿里、腾讯、字节跳动、百度、京东、滴滴、吉利汽车等国内大型企业的贡献者，还有Ebay、Redhat等国外优秀贡献者，累计贡献者超过100位。在已知的案例中，微众银行、华为云、政采云、永辉彩食鲜等公司均有规模化生产应用落地。

虽然消息总线也能支持Request-reply同步服务调用，但流量治理并非其强项，有了EventMesh的经验，我们把目光投向了ServiceMesh。ServiceMesh是把控制面和数据面进行分离的架构，在解决业务代码发布效率、解耦合、多语言支持方面有很好的收益，但同时带来了架构复杂度的提升、端到端延时的升高等问题，这些问题阻碍着ServiceMesh大规模生产上线。SpringCloud、Dubbo等非常成熟的RPC治理框架仍然是微服务化的主要选择。

微众银行的服务网格架构设计是在每个节点上都部署一个代理，这种架构的好处是每个节点只需要部署一个代理即可，相较在每个应用中都注入一个Sidecar的方式更节省资源，且中间件不与应用生命周期绑定在一起，中间件变更时不会影响业务应用。

同步和异步类型服务虽然被分开治理，却又能有机融合到一套架构下，各自发挥优势，最终形成了我们的云原生服务架构，如图2所示。

图2  云原生架构

“云”以致用，智效合一

金融业务需要在合规和安全稳定的核心原则下，才能开展技术创新实践。对于新技术的态度，不能盲从，要认识技术的本质是什么，能解决什么样的问题，最适合自己的方案才是最好的方案。

微众银行云原生中间件的架构演进，节约了资源成本、人力成本、时间成本。比如，相对于虚拟机部署，服务容器化后规格变小，碎片化的资源闲置率变得更低，资源利用率更高。通过云原生中间件接入的多语言客户端的升级频率，远低于直连的客户端，业务应用可以可以更专注业务需求开发而非中间件逻辑，且不受中间件升级的影响，还能得到更精细化的服务治理和控制能力。借助容器平台，中间件的发布、扩容效率得到大幅提升。通过可观测性平台，一笔交易流水可以把交易路径完整呈现出来，问题处理效率大幅提升。

云原生技术经过几年的发展，逐渐清晰明朗，全新的数字化基础设施必将为金融服务创新提供高水平科技支撑。

（栏目编辑：韩维蜜）

往期精选：

（点击查看精彩内容）

新媒体中心：主任 / 邝源  编辑 / 傅甜甜  张珺  邰思琪