猫眼在腾讯云北极星上的最佳实践

腾讯云中间件团队

发布于 2025-02-10 21:15:38

960

导语

在当前互联网行业飞速发展的背景下，企业对高效、稳定、灵活的服务治理方案需求愈发迫切。猫眼作为领先的互联网票务企业，通过采用腾讯云北极星（Polaris），成功优化了其微服务架构，实现了显著的性能提升和故障容错能力增强。通过将注册配置中心从 Nacos 迁移至北极星，猫眼解决了多项技术瓶颈问题，在同等规格下，承载的服务注册数更多，注册发现性能提高了30%，并显著提升了系统的扩展性和稳定性。

业务背景介绍

猫眼业务介绍

猫眼娱乐是中国领先的科技加全文娱服务平台，业务包括在线票务、文娱内容服务、广告营销等，覆盖电影、现场娱乐、网生内容、短视频等各个领域。拥有票务、产品、数据、营销四大平台，覆盖了从 IP 开发、投资出品、宣传发行、在线票务等文娱全产业链。

猫眼的业务涉及到多个高并发、大数据量的操作场景，对系统的稳定性、扩展性和故障恢复能力有着极高的要求。随着业务规模的不断扩大，猫眼原有的微服务架构逐渐暴露出性能瓶颈和扩展性问题。

技术现状

猫眼使用 Dubbo 框架作为微服务框架，开源注册中心 Nacos。随着业务的不断扩展，尤其在演唱会门票开售等具秒杀高并发场景下，猫眼遇到了几个关键痛点：

数据生效时效性：

Nacos 是 CP+AP 的架构，强依赖一致性同步协议，导致服务实例上下线存在时效性问题，在猫眼的业务场景下，生效时延容易出现10+s的情况。

注册中心扩展性问题：

同样因为 Nacos 架构的限制，导致 Nacos 集群水平扩展困难，而且扩展后带来性能提升的收益并不是同比例提升的，相反会因为节点数增多导致注册节点时的一致性协议处理耗时变长出现队列堆积的情况，集群的吞吐量未必会有多少提升。

注册中心容量瓶颈：

注册中心会随注册服务数和订阅服务数的增加而导致计算量大幅增加，从而注册中心的压力急剧增长。在未来，这种非线性的增长存在可预见的容量瓶颈，无法满足猫眼对高并发和高可用的需求。

故障影响：

○ 当 Nacos 集群超过半数节点故障后，会导致注册中心集群部分的功能不可用，影响服务的平滑发布，此期间服务发布和重启都会出现问题，对业务伤害比较大。

○ 尤其当 Nacos 数据同步出现异常时，Nacos 缺乏有效的问题排查手段，无法快速人工介入恢复，会导致业务受损。

迁移目标

为了解决上述问题，猫眼需要一种能够提供更高性能、更强扩展性和更高稳定性的微服务解决方案。具体诉求包括：

减少服务注册数据量：通过 Dubbo3.x 应用级服务注册方式，降低注册中心的压力。
提高注册中心扩展性和稳定性：能够支持大规模服务节点的扩展，并在扩展过程中保持系统的高可用性和稳定性。
增强注册中心故障容错能力：提供更好的故障隔离和恢复机制，确保服务的连续性和稳定性。

注册中心选型

北极星简介

腾讯云北极星（Polaris）是腾讯开源的注册中心、配置中心和治理中心，专为解决分布式和微服务架构中的服务可见性、故障容错、流量控制、分布式配置和可观测性问题而设计。北极星在腾讯内部已经得到大规模验证，服务注册数量超过百万，日接口调用量超过十万亿次，表现出良好的稳定性和可扩展性。

以下是北极星的整体架构：

猫眼选型北极星的原因

存算分离架构，扩展性强

传统注册中心 Eureka/Zookeeper 等，因架构设计，容易出现以下问题：

传统注册中心一般基于数据同步的方式维护集群数据一致性，单集群管理2000以上节点容易出现高负载，8000节点可用性容易无法保障。
传统注册中心存储计算合一，不支持数据分片，平行扩展困难，拓展过程中极易出现问题。
多级缓存定时切换，存在数据变更不实时问题（默认30s才可以变更）。

北极星注册中心作为新一代注册中心，在架构设计上，充分考虑传统注册中心存在的局限性。具有以下优势：

北极星注册中心支持计算存储分离、控制面无状态，可以随着接入节点的增加平行扩展，轻松支持百万节点。
北极星服务端支持数据分片，并发性能和存储容量也可平行扩展。
只保留一层只读缓存，通过增量加载进行变更，数据可实时变更。

高可用部署架构

北极星注册中心除了引擎本身具有高性能、强可扩展性之外，还具有高可用特性：

多可用区/多地域容灾

计算、存储、网络资源支持同城跨多可用区、跨城多可用区的高可用架构。

多层数据缓存

支持 Server 节点、数据库节点短暂离线，不影响业务使用。

整体故障容灾表现更优

在面对部分节点宕机、节点网络故障等场景下，北极星极大程度保障业务不受影响，提供兜底策略，在极端场景下对业务的影响尽可能降到最低。

支持多种微服务框架和接入方式

北极星支持 Dubbo 3.x、SpringCloud 等多种微服务框架，以及 K8s 同步等接入方式。并且北极星支持丰富的 OpenAPI，快速方便和猫眼现有系统进行集成。

迁移方案

一般注册中心迁移有以下三种方案：

方案一：流量入口灰度切换

方案说明

迁移过程：

保留原有老集群不变，继续使用原注册中心。迁移到北极星的服务单独组建一套集群，与老集群隔离。
未迁移时，老集群继续处理业务流量，所有的测试验证都在新集群进行处理，相互之间互不影响。
迁移时，可以通过入口网关，将小批量流量切换到新集群，验证没问题后，再逐步进行切流量，直到最后100%流量切换完成。

迁移完成后：

流量切换到100%后，就代表迁移完成。老集群继续保留一段时间等业务跑稳定后，可以逐步下线。

方案优势

回滚便捷：新集群和老集群是隔离的，所以回滚过程无需进行代码或配置的变更，直接在流量入口切换使用老集群即可。
风险可控：可以进行按小批量流量灰度切换验证，切换过程发现有问题可以立刻回切。
验证充分：切换前期可以进行全链路的验证，测试的场景比较充分。

方案缺点

会增加额外的资源成本。

方案二：双注册双发现

方案说明

迁移过程：

在迁移使用北极星 SDK 的应用节点开启双注册双发现，同时基于原注册中心及北极星注册中心进行服务注册和发现。未迁移的节点继续使用原注册中心进行注册发现。
双注册可以保证未切换的节点基于原注册中心也可以发现已切换的节点地址。
双发现可以保证已切换的节点基于原注册中心也可以发现未切换的节点地址。
通过 Dubbo 的标准应用配置的方式支持双注册和双发现，通过配置可以控制注册到的具体注册中心，与官方保持一致。 https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/reference-manual/registry/multiple-registry/#22-多注册中心地址聚合

迁移完成后：

迁移完成后，需要对所有的服务发布一次 Dubbo 的应用配置，将双注册到原注册中心和北极星改成单注册到北极星。
后续在版本迭代中，可以逐步去掉原注册中心相关依赖。

方案优势

细粒度切换：可以进行服务实例粒度的切换，对未切换的服务的注册发现不会造成影响。
风险可控：切换过程中，如果发现问题，可以停止切换并进行回滚。
故障影响面较小：两边注册中心数据不互通，单个注册中心出现问题不会影响另外一个注册中心。

方案缺点

切换完成后，需要额外进行配置变更的操作，去掉往原注册中心的双注册双发现的配置，停止往原注册中心进行注册发现。
回滚操作较多：如果切换过程中，发现问题，需要对已切换的服务进行配置变更实现回滚（去掉注册到北极星的配置，保留原注册中心注册的配置）。如果服务数比较多，回滚过程可能耗时比较久。

方案三：数据同步

方案说明

迁移过程：

已迁移的服务，使用北极星 SDK 的通过北极星进行注册发现，不再依赖原注册中心；未迁移的节点继续使用原注册中心进行注册发现。
通过同步服务进行原注册中心和北极星之间的服务数据双向同步，保证两边注册中心的服务数据一致性。

迁移完成后：

确认服务数据已经全部注册到北极星后，停止同步服务。

方案优势

细粒度切换：可以进行服务实例粒度的切换，对未切换的服务的注册发现不会造成影响。
切换可以一步到位，无需切换后的配置变更操作。

方案缺点

存在单点问题：通过同步服务进行同步的节点，健康状态都由迁移工具来进行维护。由于 Nacos 2.x 的机制（连接断开后节点会立刻下线），如果同步服务在迁移过程中出现闪断或重启，这部分同步到 Nacos 的临时节点可能会出现短时间的下线。
故障影响面较大：两个注册中心之间的新增数据一致性由同步服务进行维护。如果注册中心出现数据一致性问题，或者同步服务出现问题，可能会影响正常注册中心的服务数据，可能对服务调用链路造成影响。
回滚操作较多：如果切换过程中，发现问题，需要对已切换的服务进行配置变更实现回滚（去掉注册到北极星的配置，恢复为 Nacos 注册的配置）。如果服务数比较多，回滚过程可能耗时比较久。

在整个迁移过程中，猫眼非常注重整体过程的稳定性，能做到风险可控、影响面小、迁移粒度细，可以分步骤逐步迁移。因此，从自身业务特性出发，最终选择了服务双注册双发现实现业务迁移。

迁移效果

猫眼将服务数据迁移到北极星后，可以解决上文描述的所碰到的问题：

（1）完美和现有系统进行集成

猫眼最终的服务治理架构是基于 Dubbo 和 Polaris 的服务治理体系，Polaris 无状态的设计使得集群之间各个节点互相独立、互不影响，可以提供良好的横向扩展性和可用性。依赖 Polaris 集群良好的横向扩展性，能够在服务大规模扩缩容时避免注册中心集群容量不足的问题。不再依赖 TCP keepalive 来监测节点状态，而是通过 SDK 主动的心跳任务来进行状态判断，能避免断网、宕机场景下 TCP 连接异常断开，TCP keepalive 检测时间过长而导致节点在注册中心未下线的问题。注册中心由推模式变为拉模式，对于注册中心集群来说极大减少了运算量，集群的可用性大大提高。