共计 3404 个字符，预计需要花费 9 分钟才能阅读完成。
业务背景
好将来是一家以智慧教育和开放平台为主体，在寰球范畴内服务公办教育，助力民办教育，摸索将来教育新模式的科技教育公司，旗下领有学而思素养、学而思网校等品牌。作为国家新一代人工智能凋谢翻新平台在教育行业的代表，好将来深耕教育场景，目前已积攒 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，提供服务路由、故障熔断、拜访限流等曲线监控以及告警的能力。