低成本、高稳定性-满帮集团使用 Eureka 和 ZooKeeper 的上云实践

在上述业务背景下，满帮采用阿里云 MSE Nacos、MSE ZooKeeper 产品来替换现有的 Eureka 和 Zookeeper 集群。那么，MSE 是如何实现低成本且快速的架构升级，以及上云期间业务流量的无损平滑迁移的呢？

MSE Nacos 对开源 Eureka 原生协议完全兼容，内核仍然由 Nacos 驱动，业务适配层与 Eureka InstanceInfo 数据模型和 Nacos 的数据模型（Service和Instance）一一映射。而这一切对于满帮集团已经对接过自建 Eureka 集群的业务方而言，做到了完全透明。这就意味着，业务代码层面无需任何改动，只需要将 Eureka Client 连接的服务端实例 Endpoint 配置修改成 MSE Nacos 的 Endpoint 即可。使用上同样也很灵活，既可以继续使用原生的 Eureka 协议，把 MSE Nacos 实例当成一个 Eureka 集群来用，也可以 Nacos、Eureka 客户端双协议并存。不同协议的服务注册信息之间支持互相转换，从而保证业务微服务调用的连通性。

另外在上云过程中，满帮采用了 MSE-Sync 解决方案，一款基于开源 Nacos-Sync 优化后的迁移配套数据同步工具，支持双向同步、自动拉取服务和一键同步的功能。通过 MSE-Sync，满帮工程师轻松实现了原先自建 Eureka 集群上已有的线上服务注册存量数据一键迁移到新的 MSE Nacos 集群，同时实现了旧集群上新注册的增量数据也会自动同步到新集群，保证了在业务实际切流迁移之前，新旧集群服务注册实例信息始终是完全一致的。待数据同步 check 通过后，替换掉原有的 Eureka Client 的 Endpoint 配置，重新发布升级后就成功迁移至新的 MSE Nacos 集群了。

满帮集团在与阿里云 MSE 团队合作技术架构升级的时候，提出的核心诉求，就是要解决原先 Eureka 集群间服务注册信息同步压力大的问题。Eureka Server 是传统的对等星型同步 AP 模型，各个 Server 节点角色完全对等，对于每次变更（注册/反注册/心跳续约/服务状态变更等）都会生成相应的同步任务来同步所有实例的数据。这样一来，同步作业量随着集群规模、实例数正相关同步上涨。当集群服务注册规模达到 2000+ 的时候，部分节点 CPU 占用率、负载都很高，甚至还会因假死导致业务抖动，这一点在 Eureka 官方文档也有提及。开源 Eureka 的广播复制模型，不仅会导致它自身的架构脆弱，也影响了集群整体的横向扩展性。

MSE Nacos 在架构选型的时候就考虑到了这个问题，并给出了更好的解决方案，即自研的 AP 模型 Distro 协议。该协议在保留了星型同步模型的基础上，Nacos 对所有服务注册实例数据进行了 Hash 散列、逻辑数据分片，为每一条服务实例数据分配一个集群责任节点，每一个 Server 节点仅负责与自己相关的数据同步和续约逻辑。同时，集群间数据同步的粒度相对于 Eureka 也更小。这样带来的好处是即使在大规模部署、服务实例数据很多的情况下，集群间同步的任务量也能保证相对可控，并且集群规模越大，这样的模式带来的性能提升也愈发明显。

MSE Nacos 和 MSE ZooKeeper 在承接了满帮集团的全量微服务注册中心业务后，在升级版本中持续迭代优化，通过大量的性能压测对比测试，不断从各个细节上继续优化服务端性能，从而持续提升业务体验。下面是对升级版本优化过程的介绍：

服务注册高可用、容灾保护

原生 Nacos 提供了高阶功能--推空保护。服务消费者（Consumer）通过注册中心订阅服务提供者（Provider）的实例列表，当注册中心变更或遇到突发情况，或服务提供者与注册中心间的连接因网络、CPU 等其他因素发生抖动时，可能会导致订阅异常，从而使服务消费者获取到的服务提供者实例列表为空。

为解决这个问题，可以在 Nacos 客户端或 MSE Nacos 服务端开启推空保护功能，以提高整个系统的可用性。此外，MSE 把稳定性功能引入到了对 Eureka 的协议支持中，当 MSE Nacos 服务端数据出现异常的时候，Eureka 客户端从服务端拉取数据会默认受到容灾保护，确保业务不会出现拿到不符合预期的服务提供者实例列表，而导致业务故障的问题。

另外，MSE Nacos 和 MSE ZooKeeeper 还提供了多重高可用保障机制，如果业务方有更高的高可靠性和数据安全需求，在创建实例时可以选择不少于 3 节点的方式。当其中某个实例故障的时候，节点间可实现秒级切换，故障节点自动离群。同时 MSE 每个 Region 都包含多个可用区，同一个 Region 内不同可用区之间的网络延迟较小（3 ms 以内），多可用区实例可以将服务节点部署在不同可用区，当可用区 A 出现故障的时候，流量会在短时间内切换到另外的可用区 B。整个过程业务方无感知，应用代码层面无感知、无需变更。实现这一个机制只需配置多节点部署，MSE 就会自动帮你部署到多个可用区进行打散容灾。

支持 Eureka 客户端增量拉取数据

满帮在迁移至 MSE Nacos 之后，原先服务端实例假死无法提供服务的问题得到了很好的解决，但机房的网络带宽仍出现占用过高，服务高峰期还可能出现带宽打满的问题。经分析发现是因为 Eureka 客户端每次从 MSE Nacos 拉取服务注册信息的时候，仅支持全量拉取。这样就出现了定时拉取数千级别的数据量的情况，导致网关层面的 FGC 次数也升高了很多。为解决这个问题，MSE Nacos 上线了针对 Eureka 服务注册信息的增量拉取机制，再加上客户端使用方式的调整，客户端只需要在首次启动后拉取一次全量数据，后续只需要根据增量数据来保持本地数据和服务端数据的一致性，不再需要周期性全量拉取，而正常生产环境中变更增量数据的数据量很小，这样一来可以大幅降低出口带宽的压力。采用了该机制后，带宽从升级前的 40 Mbit/s 降到了 200 kbit/s，带宽打满问题也得到了解决。

充分压测优化服务端性能

MSE 团队后续对 MSE Nacos 集群 For Eureka 的场景进行了更大规模的性能压测，并通过各种性能分析工具排查业务链路上的性能瓶颈点，对原有功能进行了更多的性能优化和底层性能调参：

• 引入缓存

针对服务端的全量和增量数据注册信息引入了缓存，并基于服务端数据 hash 来判断是否发生变更。在 Eureka 服务端读多写少的场景下，可以大幅减少 CPU 计算生成返回结果的性能开销。

• 优化字符串数据 IO 传输性能

发现 SpringBoot 原生的 StringHttpMessageConverter 在处理大规模数据返回的时候存在性能瓶颈，提供了 EnhancedStringHttpMessageConverter 来优化字符串数据 IO 传输性能。

• 支持 chunked

服务端数据返回支持 chunked。

• 线程池数自适应调整

Tomcat 线程池数根据容器配置自适应调整。

满帮集团在完成了以上版本迭代升级之后，服务端各项参数也取得了不错的优化结果。

服务端 CPU 利用率从 13% 降到了 2%：

注册中心读 RT 从原先 55 ms 降至 3 ms 以内：

服务端 YGC Count 从原先的 10+ 降至 1：

YGC Time 从原先的 125 ms 降至 10 ms 以内：

旁路优化，保障集群高压下的稳定性

满帮在迁移到 MSE ZooKeeper 一段时间后，集群又出现了“Full GC”，导致集群不稳定。经排查发现，ZooKeeper 中 Metrics 的 watch 相关统计指标在计算时对当前节点保存的 watch 数据进行了全量拷贝。由于在满帮的场景下有非常大的 watch 规模，Metrics 计算拷贝 watch 会产生大量的内存碎片，导致集群无法分配出符合条件的内存资源，最终出现 Full GC。

为了解决这个问题，MSE ZooKeeper 针对非重要 Metrics 采取降级的措施，保障这部分 Metrics 不会影响集群稳定性。针对 watch 拷贝的 Metrics，采取动态获取的策略，避免数据拷贝计算带来的内存碎片问题。优化后，集群 Young GC 时间和次数都有了明显下降。

优化之后集群能够平稳承接 200 万 QPS，GC 稳定：

持续参数优化，寻找延时和吞吐量的最佳平衡点

满帮将自建 ZooKeeper 迁移到 MSE ZooKeeper 之后，发现应用发布时，客户端读取 ZooKeeper 中数据延时过大，应用启动读取配置超时，导致应用启动超时。为了解决这个问题，MSE ZooKeeper 进行了针对性的压测分析。在满帮的业务场景下，ZooKeeper 在应用发布时需要承接大量请求，请求产生的对象在现有的配置中导致 Young GC 频繁。MSE 团队经过多轮压测调整集群配置，寻找请求延时和 TPS 最优的交点，在满足延时需求的前提下，探索集群最优性能，在保证请求延时 20 ms、集群日常 10万 QPS 的前提下，CPU 从 20% 降低到 5%，集群负载显著降低。