业务背景
好未来是一家以智慧教育和开放平台为主体，在全球范围内服务公办教育，助力民办教育，探索未来教育新模式的科技教育公司，旗下拥有学而思素养、学而思网校等品牌。作为国家新一代人工智能开放创新平台在教育行业的代表，好未来深耕教育场景，目前已积累15大类共计170余种AI能力，覆盖视觉、语音、自然语言处理等多个方向，引领教育+AI发展的同时，助力中小行业伙伴的成长，推动教育新生态建设。
2021年好未来 AI 中台业务规模激增，日调用量超6亿，总调用量上千亿。相比2020年增长约9倍，并持续呈现增长趋势。业务规模井喷式增长，给平台带来的稳定性技术挑战也越发强烈，好未来AI中台的现有架构，无论是业务支撑还是架构设计，均存在一定的风险和隐患。
痛点分析与解决方案
好未来采用SpringCloud全家桶和Kubernetes构建云原生的 AI 中台。整体采用单集群部署。这种部署架构随着业务规模的激增，带来资源和性能瓶颈，如 VPC 中的 IP 资源、Node节点、apiserver性能等问题进而影响现网业务。另一方面，也带来集群层面的单点问题，如：完全依赖某一家云厂商、没有灾备集群、升级困难等挑战 。
![]()
除此之外 ，因历史遗留问题导致的技术债也日益严重，如：技术栈不统一 （java、python、go、c++）、服务注册sdk使用不规范 、服务负载不均衡等问题。整体架构升级与改造中，涉及模块众多，本文将重点聚焦于注册中心模块遇到的痛点与解决方案 。
- 服务负载不均衡
- 业务规模激增，注册中心瓶颈显著
- 技术栈多且杂，迁移难
现有服务注册发现方案
首先，我们先来看一下好未来现有的服务注册发现方案。
好未来选择Eureka组件作为AI中台的注册中心。Eureka是Netflix开源的一款基于Java语言的服务发现框架，2014年发布了第一个版本，现在业界广泛使用的是与Spring Cloud结合的Spring Cloud Neflix的版本。
Eureka主要功能是为应用之间跨进程的RPC调用提供服务注册发现，以及故障实例剔除的功能，其工作原理如下图所示：
![]()
Eureka Server：提供基于最终一致性的服务数据管理，服务发现，异常节点剔除等能力。
Provider：服务被调方，启动时候将自身注册到Eureka server，运行过程中定时发送心跳续约请求进行保活，在进程结束时将自身从Eureka server反注册。
Consumer：服务主调方，基于Eureka服务发现接口，从eureka拉取服务列表，并根据一定负载均衡算法，选出一个IP地址与被调方进行远程调用。
Eureka支持多语言客户端SDK，官方提供了Java版本的SDK（spring-cloud-netflix-eureka-client），社区提供了其他语言的SDK（Go，Python等）。
好未来为多语言应用，同时使用了官方提供的Java SDK、社区版Go/Python SDK，与此同时，还自研了C++ SDK。具体架构如下图所示 ：
![]()
2、核心的痛点与解决方案
痛点一 ：服务负载不均衡
好未来将每个服务配置的k8s service name注册至Eureka server服务列表中。通过Eureka + Ribbon 实现轮询（round-robin）负载算法的客户端负载均衡，Ribbon负载均衡器缓存了从Eureka Server中获取的所有服务信息。 由于同一个服务不同实例的k8s service name是同一个，导致在长链接场景下，客户端负载不均衡。如下图所示：
![]()
解决方案：
将注册服务信息由k8s clusterIP替换成每个实例的pod ip。
![]()
痛点二：注册中心注册瓶颈
好未来有4000左右的服务数，平均每个服务3节点。将service（cluster ip）注册改为pod ip注册后，客户端注册量由4000，增长至超过1万。
Eureka各个server之间是通过异步请求的方式进行写请求的同步，写请求包括注册/反注册/心跳续约的请求，同步失败会进行重试。这种异步同步模式，在客户端集群规模较大、或者网络情况不好触发了重试风暴的情况下，容易因为处理过多的同步续约请求，导致server端高负载。
以下是好未来出现的现网场景，一个可用区的Eureka server出现网络异常，续约的同步请求都重试到其他区的服务端，导致服务端高负载，出现大量请求超时，超时情况下会继续重试，从而导致高负载问题蔓延到其他区。
在1小时内，服务端平均负载飙升到80%，续约请求的时延也出现10s的峰值，导致大量服务健康状态出现异常，严重影响了现网的服务运营质量。
![]()
解决方案：
性能、可扩展性与迁移成本是好未来进行注册中心选型时重点考虑的因素。在对比了开源和业内其他厂商的注册中心之后，决定选择腾讯云提供的TSE微服务引擎（Polaris）。
![]()
Polaris(北极星)是腾讯开源的服务发现和治理组件，在服务注册发现基础上，提供了流量调度，故障剔除等治理能力，其功能可完整覆盖Eureka的使用场景。Polaris(北极星)很好的解决了Eureka带来的性能瓶颈和容量瓶颈。Polaris服务端采用计算存储分离的架构，计算层可以随着接入节点的增加平行扩展，轻松支持百万节点。
在5万服务注册节点的场景下，性能数据如下：
- 服务注册：成功率100%，最大延时<1s
- 上报心跳：成功率100%，最大延时<15ms
- 服务发现：成功率100%，最大延时<8ms
通过监控曲线可以看到，5W注册实例，并发进行全量数据拉取及实时心跳续约的场景下，北极星（Eureka）的整体CPU使用情况稳定在2.29核，并且整体的**CPU利用率稳定在57%**左右。
![]()
痛点三：技术栈多且杂，迁移难
因历史遗留问题导致的技术栈也日益严重，技术栈不统一 、服务注册sdk使用不规范。好未来为多语言应用，同时使用了官方提供的Java SDK、社区版Go/Python SDK，与此同时，还自研了C++ SDK。因此，迁移成本是重要的考虑因素：
问题一：用户程序代码需要改造吗？
好未来当前程序已经集成了Eureka的客户端，如果切换成北极星客户端的话，需要做代码变更，成本较高。
解决方案：
北极星实现了Eureka Server API的全兼容，做到支持各个语言、不同版本的Eureka Client进行直接接入。完全无需代码改造。
![]()
问题二：数据如何平滑迁移 ？
用户现网已经注册到Eureka上的存量数据，如何平滑迁移到北极星上，过程中不能出现业务的中断。
解决方案：
北极星在服务端通过服务数据单向同步，以及关联查询的方式，实现了新老服务的互访，好未来可以按自己的节奏将服务从Eureka注册中心迁移到北极星。
![]()
3、总结与收益
从定位上来说，Eureka是服务注册中心，只提供服务发现、服务注册和健康检查功能。北极星是服务发现和治理中心，除服务发现、服务注册和健康检查之外，还提供流量控制、故障容错和安全能力。
从架构上来说，Eureka集群采用异步复制的方式同步数据，每个Server将收到的写请求异步复制给集群内的其他Server。当Client越来越多时，需要扩容Server。但是，增加Server也会增加Server之间的复制请求，导致扩容效果不明显。北极星服务端计算存储分离，计算层节点可以随着客户端节点的增加平行扩展，轻松支持百万级节点接入。
好未来AI中台零代码修改，将注册中心由Eureka迁移至北极星，并发注册服务数有极大的提升，由7k提升至5w。解决了业务规模激增场景下开源注册中心瓶颈问题，有效避免线上再次故障。北极星计算存储分离、控制面无状态，可以随着未来业务规模的继续扩大，高效方便的继续扩容。除此之外，好未来还获得了服务治理、可视化控制台、服务治理监控等方面的收益。
- 服务治理：北极星提供熔断功能，根据实时采集的错误率等指标，及时熔断异常的服务、接口、实例或者实例分组，降低请求失败率。 当负载已经超过了系统的最大处理能力时，北极星提供服务限流功能，可针对不同的请求来源和系统资源进行访问限流，避免服务被压垮。有效提升业务系统的健壮性。
- 可视化控制台：北极星提供简单易用的可视化控制台，用户可通过控制台界面简化服务管理、配置管理、以及服务治理规则管理等相关的操作。
- 服务治理监控：北极星提供可视化的服务治理监控能力，基于Prometheus和Grafana，提供服务路由、故障熔断、访问限流等曲线监控以及告警的能力。
