异构注册中心机制在中国工商银行的探索实践

文｜颜高飞【工商银行】

金融科技研究院云计算实验室

本文 2651字 阅读5分钟

前言

中国工商银行于 2014 年率先启动银行核心业务系统的分布式架构转型探索，自主研发了同业领先的分布式服务平台。

注册中心为服务平台提供了核心的服务发现功能，其健壮性对服务调用的成功率起着至关重要的作用。近年来，随着服务架构落地范围迅速扩大，注册中心性能容量支撑能力面临更高挑战。

工商银行结合金融业实际运行场景，对注册中心架构进行了深度定制及优化，不断探索性能容量和高可用能力极限。

PART. 1

问题及挑战

工商银行分布式服务平台选用 zookeeper ****作为分布式服务注册中心。

zookeeper 在业界分布式系统中使用广泛，具有大规模应用场景，为用户提供高效、稳定的分布式协调服务。zookeeper 支持集群化部署、性能可扩展，可用性也较高，主要表现有：

1、半数存活即可用特性，使其容灾性能较强

只要选举节点中有过半节点正常工作，集群即可正常对外提供服务。若集群内个别服务器宕机，客户端会自动切换连接至其他可用服务器。

2、会话机制，使客户端注册信息保持稳定

客户端与 zookeeper 服务端之间通过心跳保持会话，默认会话超时 40s。若集群正常对外服务，在会话超时后，zookeeper 服务端将剔除客户端注册信息。而若集群整体不可用，会话不会过期，在注册中心集群恢复后，能自动从快照中重新恢复故障前的会话和注册信息，无需外部干预。

3、集群提供 observer 机制

实现读写分离、流量隔离

observer 节点不参与集群选举，只承担客户端连接和请求，提升整体吞吐量；分担选举节点压力，提升集群稳定性。在实施 observer 分组的情况下，还可实现客户端流量隔离。

在金融业务实际运行场景中，工商银行搭建了以选举节点为核心、扩展部署 observer 节点的 zookeeper 注册中心集群，并在工商银行稳定运行多年。

理论上，当 zookeeper 注册中心集群出现故障时，服务调用不会受到影响。

但在实际混沌工程故障演练过程中，我们发现：偶发场景下，分布式服务平台存在因 zookeeper 系统资源故障或其他问题导致影响业务交易的现象。

具体问题列举如下：

- 问题一：

单服务扩容后提供方节点数过多

触及 zookeeper 推送报文 4M 的上限，从而导致 zookeeper 服务器性能压力过大，未能及时处理其他服务注册请求，影响交易。

- 问题二：

zookeeper 集群 leader 服务器内存故障

进程僵死后集群重新选举产生新 leader，但集群内部分服务器未及时感知新 leader，导致部分服务提供方掉线，影响交易。

- 问题三：

zookeeper 注册数据大幅增大后

集群故障重新选举后 leader 向其他节点同步的数据量过大，服务器网络到达瓶颈，导致部分服务器未及时加入新集群，影响交易。

基于以上问题，工商银行一方面对 zookeeper 源码进行了深度定制，另一方面开始着手研究提升服务注册和服务发现高可用能力的机制。

PART. 2

建设多注册多订阅机制

提升服务调用稳定性

为规避单注册中心集群故障而影响服务调用的问题，工商银行构建了多点接入的高可用注册模型 （如图 1 所示）。

图 1 分布式服务高可用注册模型

说明：上图中 DC1 和 DC2 为 2 个机房，分别部署有 2 个独立的注册中心集群。DC1 和 DC2 中部署的提供方和消费方均注册、订阅自两个注册中心集群。DC1 中的消费方优先使用 DC1 注册中心推送的提供方列表，DC2 中的消费方优先使用 DC2 注册中心推送的提供方列表。

在同城双机房内独立部署两个 zookeeper 集群，提供方注册服务至双注册中心，消费方也从双注册中心订阅服务。消费方优先使用与其在同一机房内的注册中心推送的数据，当同机房注册中心集群发生故障时，其他机房的注册中心可接管。注册中心集群故障接管过程中，服务正常调用。

双注册双订阅机制建成后，分布式服务平台多次完美应对了底层系统资源故障、网络隔离等问题，分布式服务注册和服务发现稳定性显著提升。

基于双 zookeeper 集群部署的双活架构，因双集群注册中心组件技术栈相同，极小概率下仍存在系统性交易风险——若两个 zookeeper 注册中心集群在同一时刻均出现同一类型故障时 （ 比如同时达到性能瓶颈） ，业务交易仍然可能会受到影响。

因此，为规避极小概率的系统性风险，工商银行进一步开展异构注册中心建设，追求极致的服务注册和发现高可用能力。

PART. 3

建设异构注册中心 规避单一技术栈风险

注册中心异构部署，进一步提升高可用能力

工商银行开展异构注册中心建设，在部署 zookeeper 集群的同时对等部署一套独立的异构注册中心集群。业务系统同时向 zookeeper 和异构注册中心两个集群注册并进行服务订阅 （如图 2 所示） 。

图 2 异构注册模型

异构注册中心与 zookeeper 协同工作，提升注册中心整体对外服务能力。当 zookeeper 集群与异构注册中心任一集群发生系统性故障时，另一注册中心集群可接管 （如图 3 所示数据表结构） 。

图 3 异构注册模型下任一注册中心集群故障

说明：上图中 zookeeper 集群故障，异构注册中心正常工作，服务仍可正常注册、订阅及调用。

提出合并订阅机制，

使注册中心故障时迁移更加平滑

工商银行原有多注册中心订阅机制，消费方优先使用某一注册中心推送的提供方列表，仅当该注册中心上无任一可用提供方，消费方才切换使用下一注册中心推送的数据。此时若优先使用的注册中心因故障推送了不完整的提供方列表，消费方集中调用这些提供方，可能导致“提供方负载不均”、“触发并发限流”等问题。

为保障建设异构注册中心后注册中心故障时迁移更加平滑，工商银行研究并提出了消费方合并订阅机制： 在消费方侧合并 zookeeper 和异构注册中心的订阅视图，各注册中心订阅数据合并后再刷新 invoker 缓存。

即使某注册中心故障推送了空或者不完整的提供方列表，合并后的数据仍是有效的，提高了消费方筛选提供方的效率，提升交易成功率。

图 4 多注册中心合并订阅机制

注册中心异构部署和消费方合并订阅机制建成后，混沌模拟注册中心 CPU 满载、内存高负荷、磁盘故障、网络抖动、网络隔离等故障场景，提供方负载均衡，交易无失败，符合预期。同时，合并订阅机制还能额外降低多注册中心模式下消费方缓存提供方列表所占用的内存。

基于以上技术储备及基础建设，工商银行于 2020 年开展异构注册中心建设，规避行内注册中心单一技术栈风险，进一步提升了注册中心核心组件在整个分布式体系中的高可用能力。

PART. 4

未来展望

为满足分布式服务平台金融级高可用的需求，工商银行探索并提出异构注册高可用方案，消除了大规模服务注册场景下单一注册中心存在的系统性风险，保障金融系统的稳健运行。

未来，工商银行将在异构注册的基础上进一步推动单元化部署运维转型，打破注册中心为全局唯一流量枢纽的现状，实现交易流量在单元内部最大限度完成闭环，辅以单元自动切换实现故障隔离，进一步控制区域性故障场景下的故障爆炸半径，全面提升分布式服务平台流量控制、高可用接管能力，为同业微服务架构规模化应用提供最佳实践和范例。