业务背景

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