导语：2021年，好未来的AI 中台业务规模激增，日调用量超6亿，总调用量上千亿。业务的快速发展给中台的现有技术架构带来一定的冲击。好未来AI中台是微服务架构，完成一个业务请求涉及多个服务之间相互调用，可以说注册中心的稳定性会直接决定业务调用的成功率。在技术升级过程中，腾讯云和好未来工程师在注册中心模块上，实现了零代码修改从Eureka迁移至北极星PolarisMesh的最佳实践，树立了国内企业在服务发现、服务治理领域的一个新标杆。
背景
作为国家新一代人工智能开放创新平台在教育行业的代表，好未来深耕教育场景，目前已积累15大类共计170余种AI能力，覆盖视觉、语音、自然语言处理等多个方向。
2021年好未来 AI 中台业务规模激增，日调用量超6亿，总调用量上千亿。相比2020年增长约9倍，并呈现持续增长趋势。业务规模井喷式增长，给平台带来的稳定性技术挑战也越发强烈，对现有技术架构也提出了更高的要求。
第一代架构：使用K8S作为注册中心
AI中台是基于K8S构建的服务层，早期是单集群架构，服务之间的调用是基于K8S域名寻址到Cluster IP进行调用。
为了解决单K8S集群所带来的IaaS资源不足、没有灾备容灾、升级困难等问题，AI中台的服务层需要改造并支持跨集群部署。为了实现服务层跨集群，系统需要做以下改造：
- 需要切换注册中心：K8S域名无法跨集群，服务要做跨集群调用需要依赖全局注册中心。
- 需要支持多语言技术栈：因历史遗留问题，AI中台的技术栈不统一，存在Java、Go、C++等多语言开发的服务。
第二代架构：使用Eureka作为注册中心
第二代AI中台改造使用完全的微服务架构，由于AI中台大部分的应用都是Java应用，因此选型使用了业界最常用的Spring Cloud Netflix框架来作为微服务的底座。由于Spring Cloud Neflix默认对接了Eureka注册中心，因此AI中台也选用了Eureka作为全局注册中心。
- 采用Eureka作为独立的注册中心：直接使用POD IP进行寻址，解决原K8S ClusterIP无法跨集群的问题。
- 除Java语言外，其他语言服务使用第三方或自研的Eureka客户端。
改造并使用Eureka作为注册中心后，在现网运营过程中，遇到了以下问题：
稳定性问题
好未来有4000左右的服务数，平均每个服务3节点。将service（cluster ip）注册改为pod ip注册后，客户端注册量由4000+增长至超过10000+。
AI中台Eureka服务采用的是多节点集群部署，节点间通过请求复制的方式维持节点间数据的一致性。在正常情况下，每秒复制的请求数=(节点数*续约请求数)/续约间隔。按照5秒的续约间隔，每个节点大约每秒处理6000个续约请求。
当其中一个Eureka服务出现异常时（比如网络中断等），续约失败的请求会进行重试，出现重试风暴，剩余的Eureka节点所需要处理的续约请求增加到原来的2倍，峰值到3倍。导致剩余节点出现了高负载。
高负载会导致Eureka的计算逻辑出现延迟，续约请求处理不过来导致实例被异常下线，影响业务正常调用。
维护成本问题
Eureka官方只提供了Java版本的客户端，其他语言客户端则需要依赖第三方开源实现（Go）或者自研（C++）。非官方客户端存在质量风险，需要额外投入成本进行优化和测试。
下一代架构：使用PolarisMesh作为注册中心
为解决Eureka注册中心所带来的稳定性和成本问题，需要对注册中心进行选型。
除了功能满足度以外，性能、可扩展性与迁移成本是好未来在选型时重点考虑的因素。在对比了开源和业内其他厂商的注册中心之后，决定选择PolarisMesh（北极星）作为AI中台的全局注册中心，替换原有的Eureka，主要基于以下考虑：
（1）北极星服务端采用计算存储分离架构，数据一致性通过存储层保证，无需计算层参与进行请求复制和数据同步。计算层可随着接入节点的增加进行水平扩展。
在单节点性能方面，同等规格下，北极星的注册发现性能是Eureka的10倍，能轻松解决Eureka在万级节点下服务发现的性能问题。
| 北极星 | Eureka | |
| 服务发现单机TPS | 80277 | 6431 |
| 服务注册单机TPS | 29457 | 4793 |
| 平均时延 | 79ms | 400ms |
（2）北极星社区官方提供了多语言SDK，以及多种主流框架（SpringCloud，Dubbo，gRPC）的集成插件，无需通过第三方社区以及自研的方式解决客户端接入的问题。
| 北极星 | Eureka | |
| Java语言 | 支持 | 支持 |
| Go语言 | 支持 | 不支持 |
| C++语言 | 支持 | 不支持 |
（3）北极星服务端基于插件化开发，通过扩展API插件的方式，实现了对Eureka接口的全兼容，AI中台的存量业务，无需修改代码即可直接接入，迁移成本低。
无缝迁移
迁移方案选型
AI中台已经完成了微服务的改造，服务层代码已经与Eureka进行了深度集成，且现网节点已经全部注册到Eureka，北极星注册中心的切换需要做到业务无感的迁移。
业界注册中心迁移一般有以下2种方案：
方案一：客户端双注册双发现
迁移后的应用，通过集成SDK或者JavaAgent的方式，同时往新老注册中心进行双注册双发现，以此保证迁移后的应用以及未迁移的应用，都可以获取到全量的服务数据。
方案二：服务端数据同步
新老注册中心服务端通过同步服务进行数据的双向同步，客户端无需感知即可获取全量的服务数据。
两种迁移方案的对比如下：
| 客户端双注册双发现 | 服务端数据同步 | |
| 应用无侵入 | Java应用通过JavaAgent的机制实现应用无侵入迁移，其他语言则需要修改代码进行迁移。 | 应用代码无感知 |
| 适用场景 | Java应用或者愿意对应用代码进行修改的业务（比如刚开始进行微服务改造） | 适用于对现网在运营的业务进行迁移 |
由于AI中台业务存在多语言的场景，且服务已经在现网运行，因此选用服务端数据同步的方案来进行Eureka到北极星的迁移。
迁移过程实现
北极星对Eureka的API进行了全兼容，因此，业务可以把北极星集群作为一个Eureka节点，加入到Eureka原来的集群中，基于Eureka原生的同步协议进行新老注册中心的服务数据双向同步。
基于上面的迁移方案，新的应用只需要修改一下注册中心地址，即可实现迁移，无需任何代码修改。业务可以按自己的节奏将服务从Eureka注册中心迁移到北极星，中途发现问题可随时回滚。
AI中台迁移后的业务结构如下：
总结与收益
好未来AI中台零代码修改，将注册中心由Eureka迁移至北极星，并发注册服务数有极大的提升，吞吐量得到了10倍的提升，并解决了业务规模激增场景下开源注册中心可靠性问题，有效避免线上再次故障。北极星计算存储分离、控制面无状态，可以随着未来业务规模的继续扩大，高效方便的继续扩容。
除此之外，好未来还获得了服务治理、可视化控制台、服务治理监控等方面的收益。
流量管理：北极星提供全方位的流量管理能力，可轻松满足用户针对应用的灰度发布、多环境隔离、故障熔断、访问限流等诉求。
可视化控制台：北极星提供简单易用的可视化控制台，用户可通过控制台界面简化服务管理、配置管理、以及服务治理规则管理等相关的操作。
流量监控：北极星Polaris提供可视化的监控能力，提供服务调用、故障熔断、访问限流等曲线监控以及告警的能力。
本文作者：
苏珂：好未来AI中台PaaS平台负责人
李佳南：腾讯云中间件团队高级产品经理
单家骏：腾讯云中间件团队技术专家，北极星开源社区PMC成员
