工商银行基于Dubbo构建金融微服务架构的实践-服务发现篇

导读 ：Dubbo 作为分布式微服务框架，众多公司在实践中基于 Dubbo 进行分布式系统架构。重启开源后，我们不仅看到 Dubbo 3.0 最新的 Roadmap 发布，而且还看到阿里在自身电商开始推进 Dubbo 和内部 HSF 的融合，并在 双11 上开始使用 Dubbo 3.0。本文是工商银行基于 Dubbo 构建金融微服务架构的分享，主要讲述了服务发现的应对策略和成果，后续将发布工行大规模服务监控治理的实践，以及从企业角度怎么去对 Dubbo 二次开发等内容。欢迎关注。

背景及概览

工商银行 traditionally-based business systems typically utilize the JEE-based single architecture model. As the financial sector increasingly emphasizes online services and diversifies its service offerings, the traditional architecture has become insufficient to meet current demands. Therefore, since 2014, the Bank of China began exploring a service-oriented approach by selecting a specific business system for implementation. Through a comprehensive evaluation and comparison of several distributed service frameworks available at the time, they ultimately chose Dubbo, a solution that is relatively well-developed and has been successfully deployed in numerous domestic organizations. To further enhance this outcome, the Bank of China customized the Dubbo platform specifically for their needs, achieving remarkable success once fully operational.

从2015年开始逐步推进服务架构在全行范围内的落地实施工作。在这一过程中一方面致力于推动传统业务系统的架构转型,另一方面则逐步形成了类似中台的超大规模服务集群,为业务系统的快速组合与共享提供了支撑。经过多年的积累与提升,中国工商银行持续开展对Dubbo的迭代优化工作,在此基础上为企业定制专属解决方案,并通过持续完善相关配套服务,构建了一个包含基础平台、应用平台、数据平台等在内的全方位的服务生态体系

2019年时,工商银行的微服务体系全面升级成为其开放平台核心银行功能的重要组成部分,并为其IT架构实现分布式架构转型提供有力支撑

工行的微服务体系组成如下图所示：

• 在工行云平台上实现了各类基础设施的服务节点部署。
  无论是业务系统的各个节点还是微服务平台自身的功能模块均已成功部署于工行云平台。
• 为提升服务管理效率特配合设立了元数据中心用于按节点实现服务的注册发现功能。
• 通过外部分布式配置中心实现了各类动态参数的统一管理与下发方案。
• 针对服务监控需求实现了各类运行指标的统一采集存储并完成了与企业监控平台的有效对接。
• 主要功能是实时追踪服务质量保障链路快速定位故障根源并评估影响范围。
• 该系统具备在Dubbo架构之上自动发现新服务自动订阅新增版本以及智能协议转换的能力（将HTTP协议转换至RPC协议）从而保证全天候稳定运行。
• 提供了一个集成了管理监控查询等功能的一站式服务平台为运维团队和开发测试人员提供了高效便捷的服务治理方式。

最大的挑战

经过工行多年的落地实践，本文共总结了以下两方面的最大挑战：

• 性能容量方面 ，目前线上服务数量（即 Dubbo 概念中的服务接口数量），突破了两万；而每个注册中心下的提供者条目数量（即每个服务的所有提供者累计的数量），则达到了七百多万。基于评估结果，在未来阶段将面临需支撑十万级别在线上服务能力的数量挑战，并且每个注册中心将需要支持五百多万级别的提供者条目数量。
• 高可用方面 ，工行的目标是：微服务平台任何单一节点故障均不应影响线上交易流程。银行的核心业务系统采用持续运行模式，并在版本更新周期安排上充分考虑了错开策略以确保平台一致性的稳定性；即使在版本切换期间各核心业务系统的升级互不影响的情况下，在线交易也将保持正常运转；而对于注册中心层面而言，则需要特别关注本地环境下的版本更新问题。

本文将先从服务发现方面，来分享一下工行的应对策略及成效。

服务发现难点和优化

1. 入门

在Dubbo协议中遵循的服务架构模式涉及服务的注册、订阅以及互动机制。具体而言，在Provider实例（ServiceProvider）完成初始化后会自动完成自我注册；当Consumer实例（客户端）启动时会进行自我订阅，并动态收集所有ServiceProvider实例；而当系统运行期间ServiceProvider实例发生变更时，在线Consumer实例能够及时更新并重新获取最新的ServiceProvider集合。此外，在这种架构下实现的服务间交互采用的是基于点对点设计的RPC通信方式，在这种模式下客户端无需依赖中间节点即可直接与所有可用的服务进行交互。

中国工商银行于2014年选择Zookeeper作为其注册中心的技术平台。该技术广泛应用于各行业领域，并且支持分布式架构设计，确保了节点间数据的一致性。

Zookeeper内部会根据服务的不同建立相应的节点；每个服务下面会有四个类型的子节点：提供者（providers）、消费者（Consumers）、配置项（Configurations）和路由（Routers）。

• Provider临时节点：负责维护该服务提供者列表，并采用Zookeeper watch功能确保相关数据变更及时同步给客户端系统。
• Consumer临时节点：作为客户端系统查询相关消费者信息的重要数据存储结构。
• Configuration持久性存储单元：专门用来存储系统运行所需的各种参数设置信息。
• Router结构体：用于管理网络中的动态路由配置设置，并规定了客户端与各个业务系统的交互规则。

在云端生产环境中,Zookeeper分数据中心布置了多个集群,每个集群配备5个选举节点以及若干个Observer节点.Observer节点是从Zookeeper 3.3.3版本中新增的一种特殊类型的节点,它不参与选举过程,仅负责接收并记录表决结果,其其他功能特性与Follower节点保持一致.具体优势体现在以下几个方面:

• 分担网络压力：当服务数量不断增加时，在这种情况下客户端会被分配至相应的选举节点进行请求处理，并为这些请求承担了大量计算负载。然而由于选举节点在水平方向上的扩展能力存在限制，在 election node 数量不断上升的情况下事务投票的时间将会显著延长从而对该系统的高并发读性能造成不利影响。
• 减少跨城域间注册订阅流量：当有 100 个消费者需在同一服务进行跨城域注册订阅时 observer 系统能够集中管理这一类业务从而避免因跨城域间的网络带宽而产生的通信压力。
• 实现应用间独立性管理：通过将多个 observer 观测器专门配置给某些关键业务系统即可实现各业务系统的独立运行从而保证它们各自的网络流量不会互相干扰达到更好的系统整体效能。

2. 问题分析

工商银行基于近段时间内在线上Zookeeper服务中的实际使用经历（即所谓的"心酸血泪史"），归纳出了Zookeeper在作为服务注册中心功能时所面临的关键问题与挑战

• 随着服务数量以及服务提供者节点的增加，服务推送的数据量会呈爆炸式增长。举个例子，一个服务有 100 个提供者，当提供者启动的时候，因为 Zookeeper 的 CP 特性，每上线一个提供者，消费者都会收到事件通知，并从 Zookeeper 来读取这个服务的当前全部提供者的列表，然后刷新本地缓存。这个场景下，理论上每个消费者总共收到了 100 次事件通知，并从 Zookeeper 读取了 100 次服务提供者列表，1+2+3+...+100，总计 5050 条提供者数据。这在业务系统投产高峰期问题尤为突出，容易导致 Zookeeper 集群的网络被打满，造成服务订阅效率极其低下，并进一步影响了服务注册的性能。
• 随着写在 Zookeeper 上节点数量的增多，Zookeeper 的 snapshot 文件也不断变大，每次 snapshot 写入磁盘，会出现一次磁盘 IO 冲高。投产高峰期，因为事务量大，写 snapshot 文件的频率也非常高，这对基础设施带来了较大的风险。同时 snapshot 文件越大，也预示着 Zookeeper 节点故障后恢复的时间越长。
• 当 Zookeeper 选举节点发生重新选举后，Observer 节点都要从新的 Leader 节点同步全量事务，这个阶段如果耗时过长，就很容易导致连接在 Observer 节点上的客户端 session 超时，使对应 providers 节点下的临时节点全部被删除，即从注册中心角度看，这些服务都下线了，消费者端则出现无提供方的异常报错。紧接着，这些提供者会重新连接 Zookeeper 并重新注册服务，这种短时间内大批量服务的注册翻转现象，往往带来更为严重的服务注册推送的性能问题。

综上所述，经过分析可以得出结论：总体而言而言而言而言而言而言而言而言，在大多数情况下情况下情况下情况下情况下情况下情况下情况下情况下情况下情况之下之下之下之下之下之下之下之下之下之即即即即即即即即之之之之之之之之之之之内内内内内内内内内之内之内之内之内之内之内之内之内之内之内之内之内之上之上之上之上之上之上之上之上之上之上之处之处之处之处之处之处之处之处之处之处之处之外之外之外之外之外之外之外之外之外之外之外之外之后之后之后之后之后之后之后之后之后之后之后之前之前之前之前之前之前之前之前之前之前之前的结论是：Zookeeper 作为注册中心，在大多数情况下表现尚可；但在面对更大的服务量时，则需要进一步优化系统性能和资源管理以提升整体效率。

3. 优化方案

工商银行实施的主要优化措施包括：对订阅或更新流程进行延缓、在注册中心采用 multiple 模式以及切换至按节点注册等。

1）订阅延迟更新

工商银行对其Zookeeper客户端组件zkclient进行了优化工作，在消费者收到事件通知后进行提供者列表获取操作时引入了短暂延迟

当zkclient接收到childchange单一事件时,installWatch()借助EventThread机制来重新建立对节点的监控,同时调用getChildren()函数以获取节点下所有子节点的服务提供者列表,并更新本地的服务提供者缓存.这直接源于之前提到的'5050条数据'问题.

当zkclient检测到childchange()事件时，工商银行设置了等待时长，并将该工作分配给installWatch()执行。在此期间若服务提供者发生变更，则不会触发childchange事件。

有人可能会有疑问：这是否违反了 zookeeper 的 CP 模型？实际上并非如此：zookeeper 服务端的数据始终保持强一致性，并且消费者接收到事件通知后，在延迟获取提供者列表之后执行 getChildren() 方法时会发现 zookeeper 上已更新的数据状态。因此这种情况是正常的并不存在问题。

通过内部压力测试发现，在当服务提供者进行大规模上线测试时，每个消费者接收了来自422万个提供者节点的数据总量。在延迟达到1秒的情况下处理后，该数据规模缩减至约26万条。完成这一优化方案后，在高峰期能够从容应对大量服务的上线与下线。同时childchange事件数量及网络流量均降至约原始值的5%左右。

2）Multiple 模式

工商银行采用了 Dubbo 新版本中 registry-multiple 的 SPI 实现，并对之进行了优化升级，旨在通过多注册中心场景下的服务订阅进行改进。

在 Dubbo 中的服务消费者处理流程中，在存在多个注册中心时，消费者会根据对应的第一台注册中心的缓存信息来筛选提供方资源。若第一个注册中心缓存未找到，则系统会转而检查第二个注册中心对应的缓存信息进行匹配。这种机制设计虽然初衷是为了提高可用性与负载均衡性，在实际运行中可能会出现第一个节点失效导致发送给消费者的某些数据缺失（如某些关键配置参数）的情况发生，并从而可能破坏整个筛选机制的正常运行。

而 multiple 注册中心通过整合各节点发送的数据后再更新缓存内容。因此，在任何一个注册中心出现故障的情况下（即某个节点发送的数据可能不完整或缺失），只要至少存在另一个节点提供完整的数据集，则最终合并后的数据不会受到影响。

并且，在异构注册中心场景中也采用了 diverse registration center systems 的机制。当遇到问题时无需等待就可以将该注册中心暂时终止运行，并不会对服务节点的服务调用产生任何干扰，并且非常适合-gray deployment scenarios or urgent switchovers.

进一步来说，在这种情况下还能够带来更多好处。在消费者端所使用的 Reference 对象相对来说较为占用 JVM 内存资源。借助于 multiple 注册中心模式这一策略，在这种情况下能够在消费者端显著减少一半 invoker 对象的创建开销。鉴于此原因，在多个注册中心的应用场景下强烈建议优先选择并配置为 multiple 模式。

3）按节点注册

中国工商银行对Dubbo2.7和Dubbo3.0进行了反向移植，并采用了基于节点的注册方式构建的服务定位框架。其中涉及配置中心、元数据中心以及注册中心这三个关键组件的协同运作

• 配置管理模块：主要负责存储节点级别的动态参数，并记录服务原有写在 Zookeeper 上的 configurations 和 routers 等持久节点数据。
  • 元数据管理模块：主要负责存储节点元数据，包括每个服务节点名称（applicaiton-name）与其提供的服务映射关系等信息，并记录每个服务的类定义细节如方法输入输出参数等。
  • 注册管理模块：此时该模块仅负责存储服务提供者节点名称与其对应的实际 ip 端口信息。

该模型的变化对该消费者的服务调用不起任何作用；该消费者端通过分析元数据中心中"服务节点名称"与"服务"之间的关联关系，并结合注册中心中"服务节点名称"与实际IP地址端口的对应关系；从而实现对兼容存量模式下服务提供方invoker缓存的构建

通过压测实验结果表明，在采用基于节点的注册策略后，在线节点数量仅为原来总量的约1.68%，这对于运行在线Zookeeper系统而言完全没有压力；同时，在服务端拥有10万级别的服务数量以及对应的节点配置也能够轻松应对日常负载需求

未来的规划

未来我希望有机会将自身优势融入到社区中去

另外，在微服务发展 landscape 中来看的话,Mesh 已经成为了重要方向。对于工商银行来说,其主要痛点集中体现在服务 SDK 的版本升级问题上,Istio 存在诸多问题尚未解决,MCP 的命运尚不明朗,如何实现现有Dubbo 服务向MESH架构顺利迁移,已初具雏形,但仍面临诸多技术障碍亟待解决。

欢迎经验丰富的同学一起来交流讨论大规模场景的问题与心得体会，在一起共同提高Dubbo的企业落地表现得更加卓越！

作者：张远征

该连接将引导到目标页面，并包含特定参数字段以指定访问信息

本文为阿里云原创内容，未经允许不得转载。