注册中心作为微服务架构的中心，承当服务调用进程中的服务注册与寻址的职责。注册中心的演进是跟着事务架构和需求的开展而进行演进的。腾讯当时内部服务数超百万级，日调用量超越万亿次，运用着一致的注册中心——北极星。腾讯注册中心也阅历 3 个阶段演进进程，下文首要分享腾讯内部注册中心的演进进程，以及依据运营进程中的优化实践。

服务注册中心概述

2008 年，zookeeper 诞生，作为最早被广泛运用的注册中心，供给了可自定义的依据树形架构的数据存储模型。业界常见的微服务运用场景是 dubbo 结构，运用 zookeeper 进行服务数据的办理；一起在大数据场景下，kafka/hadoop 运用 zookeeper 进行集群和分区的办理，归于泛服务注册发现的用法。因为 zookeeper 没有服务模型的概念，各结构运用约好的树形途径进行服务数据的存取，在运用和保护上比较杂乱。2014 年开端，跟着微服务架构的大规划运用，具有一致的服务模型和操控台的注册中心得到广泛的运用，最常用的包括 eureka、consul、nacos 等。2015 年起，k8s 开端大规划运用，k8s 依据 etcd+coredns 供给了依据域名的服务发现才能，运用直接依据 DNS 即可进行服务发现。

整体来说，服务注册发现有两种完成方案。

zookeeper/eureka/nacos/consul：优势在于作为独立注册中心，与详细运用布置环境无关，办理和运用都比较便利。限制在于这些注册中心架构都是存储核算合一的，单集群功用有限，无法独自针对读或许写进行水平扩展。

k8s service：服务数据依据 etcd 进行存储，经过 coredns 进行服务发现。优势在于服务注册中心内置在 k8s 渠道中，无需额定保护注册中心。限制点在于：

(1) 无法完成针对 pod/workload 粒度依据权重的流量灰度。

(2) 运用服务调用时，只能获取到单个 cluster ip，无法拿到依据的 pod ip 列表进行负载均衡，长链接运用场景下简略呈现负载不均的问题。

(3) 运用依据 TCP 连接无法拿到对端的 POD IP，出问题定位不便利。

(4)k8s 服务默认只支撑当时集群发现，跨集群调用的域名需求带入集群信息，运用进行服务调用时需区分并运用不同的域名。

(5) 只能依据 k8s 环境运用，非 k8s 环境布置的服务无法运用。

腾讯自研注册中心演进进程

第一阶段：分布式服务萌芽期

在 2012 年以前，腾讯内部干流开发言语是 C++，事务技能栈首要是 LAMP（Linux+Apache+MySQL+PHP）形式和 CGI+ 独立后端形式，前者常见于逻辑简略的单体 Web 运用，后者常见于大型偏核算类的运用，比方社交运用的后端等。

在这 2 种形式下，事务的长途调用（PHP 寻址 MySQL，CGI 寻址后端节点），需求依靠寻址。在没有注册中心之前，事务往往经过 VIP（四层负载均衡）的方法进行寻址，存在以下问题：

改变难度大：VIP 本身依据四层负载均衡设备完成，设备本身存在一个裁撤改变的危险，一旦呈现 VIP 改变，事务的代码需求进行改变，影响面比较广。

单点问题：VIP 本身成为了一个单点，一旦四层负载均衡设备呈现问题，会导致服务不可用。

在 2007 年，为了处理 VIP 寻址所带来的问题，腾讯自研了一款注册中心产品 L5，供给了依据操控台和 SDK 的服务注册发现、负载均衡功用，服务调用能够经过 L5 寻址后直连拜访，无需再依靠 VIP。

L5 是一套运用 C++ 开发的一体化注册中心，依据数据库进行服务数据的存储，客户端经过 Agent 与服务端进行拜访。L5 的架构存在以下问题：

架构封闭：注册一切的功用和负载均战略都写死在代码中，不具有任何扩展性，事务的新功用需求只能经过 L5 的保护团队来支撑。

第二阶段：多注册中心

在 2013 年后，跟着移动互联网的高速开展，社交、娱乐等事务的用户量也在增加，分布式服务架构进入快速开展期，对注册中心也提出了一些需求，比方支撑健康检查、支撑轻量化、支撑与基础设施或发布渠道打通等。可是因为原有 L5 缺乏定制性，而且 L5 的运维团队减缩，导致事务提的需求无法满意，因而部分事务都开端自研注册中心，其中运用比较广泛的是以下几个注册中心：

CMLB：全称 common load balance system，供给同 IDC、同城、同国、同洲等多级容灾布置及就近寻址功用，满意事务海外国内多地布置就近容灾的诉求。

TSeer：一个轻量级的注册中心，支撑 Agent 与 SDK2 种接入方法，满意轻量化的诉求。

Routersrv：是微信服务结构 SvrKit 的一部分，打通并关联渠道相关的基础设施及发布体系。多注册中心共存，不同注册中心上的数据是阻隔的，无法互通。

运用不同注册中心的事务团队要进行互通，服务供给者需求把服务一起注册到多个注册中心，才能支撑各个事务团队之间服务彼此发现。

这种运用方法会带来以下问题：

1.服务发布的杂乱度提高：服务的布置和发布一般和发布体系绑定，对接多个注册中心，对发布体系的完成会比较杂乱，简略呈现数据不一致的问题。

2.事务开发杂乱度提高：不同注册中心有不同的服务发现 API，事务开发者在调用服务之前，需求先确认服务注册在哪个注册中心，选用不同的 API 接口来进行服务发现。

第三阶段：大规划分布式服务互联互通

到了 2018 年，公司内部事务经过进一步的开展，节点数已经达到了百万级，日调用量也超越了万亿，内部服务跨事务团队之间互相拜访成为了常态。运用多注册中心所引发的问题，益发成为了影响事务开发和布置功率的瓶颈。

一致注册中心：北极星

2018 年到 2019 年头，在公司开源协同的背景下，为处理多注册中心带来的杂乱性问题，多个事务团队的同学们聚在一起，依据原有注册中心的运营和设计经验，经过内部开源的方法，协同共建了能够支撑百万级服务体量的注册中心——北极星。

注册中心如何无缝搬迁

新的注册中心上线，可是大量的存量服务节点在老注册中心上，事务团队需求进行渐进式搬迁，可是关于事务团队来说，不希望有任何的代码改造，不然这个搬迁进程成本太高。因而北极星支撑以下零代码改造的的渐进式搬迁方法：

1.双注册双发现

关于 Java 类运用，北极星经过供给 JavaAgent 的方法，支撑已搬迁的服务经过零改造的方法，进行双注册和双发现，一起存量注册中心也有全量的服务，未搬迁服务也可发现已搬迁服务。

2.单向同步 + 协议兼容

关于非 Java 类运用，北极星经过插件化供给协议兼容才能，兼容已有注册中心的接口，新服务改变一下注册中心地址即可完成搬迁。一起，为了处理未搬迁服务拜访已搬迁服务的问题，经过扩展存量注册中心的方法，完成存量服务数据的单向同步以及对已搬迁服务的增量拉取。

北极星 VS 其他注册中心

北极星在 2018 年底开端进行设计和开发，在 2019 年头上线，到现在已运营了超越 3 年时间，支撑了腾讯内部不同形状的事务接入，也阅历过大大小小的运营活动的洗礼，架构和稳定性也得到了打磨。从技能设计上，北极星处理了业界注册中心存在的单集群功用，水平扩展的问题，一起产品形状上也有自己的一些思考，下文会对这部分内容进行分享：

优势 1：可扩展性

注册中心要害的点是服务数据的一致性，依据一致性模型，注册中心会分为 2 类：

强一致性（CP）形式

注册中心集群中一切节点的数据都确保强一致，客户端从集群中同一时刻任意一个节点获取到的数据都是相同的。强一致性集群中，各个节点有自己的人物，一般分为 leader 和 follower。leader 一致和谐数据的写入与同步，follower 担任处理客户端的读恳求，常见的数据一致性协议有 Zab，Raft 等。

zookeeper 和 consul 都归于强一致性注册中心，其限制点在于单集群的写功用受制于一致性协议，有必要等待 leader 写入成功且集群中大大都的 follower 都同步成功，才完成一次写操作。当 leader 节点网络故障，需求从头选主，通常耗时 30~120 秒，推举期间集群不供给服务，这不符合可用性准则。

终究一致性（AP）形式

注册中心集群一切节点都是无状况对等的，服务数据能够在任意节点写入，写入后经过长途恳求同步到集群其他节点。客户端从集群中同一时刻不同节点获取到的数据可能会存在差异，可是终究会保持一致。

eureka 和 nacos 都归于终究一致性注册中心，其限制点在于集群每个节点都参与服务数据写入、同步、以及读取，核算存储合一。单集群的读功用会遭到写操作的影响，写操作过于频频引起高负载问题，对读操作功用存在影响。

考虑到作为注册中心，可用性、功用和吞吐量是比较要害的指标，短期的数据不一致是能够忍耐的，因而在架构模型上，北极星选用的是终究一致性的架构模型。

核算存储别离

腾讯内部服务调用链路是一个网状结构，各个 BG、各个事务之间都存在彼此调用，比方游戏事务需求对接支付体系，视频事务需求对接存储体系等。为了简化用户的运用方法，北极星经过一致集群来支撑内部一切的服务接入，以及跟着事务的开展，集群的功用也要能够支撑水平扩展。

因而，北极星选用核算存储别离的架构，操控面代码拆分红 cache（缓存）层和 store（存储）层，cache 层供给高功用缓存的才能，store 层担任对接后端存储，支撑联系数据库和本地磁盘；客户端及操控台把服务数据注册到 store 层，store 层经过异步的方法将数据写入数据库或许磁盘；cache 层订阅到改变后，从 store 层增量拉取服务数据，并更新本地缓存；客户端直接从 cache 层获取到所需的服务数据。操控面 cache 本身无状况，这意味着关于读写来说都能很好的水平扩展，在腾讯内部，从小规划集群（万级以下服务）到大规划公共集群（百万级服务）都有着出产事例。

优势 2：单集群功用

为了提高操控面功用，观察到大部分注册中心在服务发现进程中，都有着模型转换和编解码的进程，这一进程 CPU 基本都是消耗在了 protobuf 的编解码动作中（占 70%）。因而，依据空间换时间的思维，咱们在公共服务缓存基础上，增加了协议层热点缓存，对回来的编码后的数据进行复用，省去编解码进程的损耗；经现网实际数据验证，协议层缓存命中率高达 98%，功用比较之前提高了一倍，一起也优于同类注册中心。

功用对比

咱们针对北极星操控面进行了压测，关于不同标准下的北极星三节点集群、eureka 集群、consul 集群，压测数据如下：

1.服务注册

2.服务发现

3.测验定论

经过对北极星的注册以及发现功用，从接口层到存储层全调用链路的优化，从终究的压测结果能够看出：

(1)在服务注册的 TPS 上，北极星注册功用，关于平等标准的 eureka，最高有将近三倍的注册功用提高；关于平等标准的 consul，最高有将近四倍的注册功用提高。

(2)从服务发现的 TPS 上，北极星的发现功用，关于平等标准的 eureka，最高有将近十七倍的服务发现功用提高；关于平等标准的 consul，最高有将近两倍的服务发现功用提高。

优势 3：针对不同企业规划有不同的布置形式

针对企业不同的微服务规划，北极星供给 3 种形状的集群组网：

1.大规划集群组网，按功用拆分集群布置，可支撑百万级的服务接入；

2.小规划集群组网，全功用对等集群，可支撑十万级以下服务接入；

3.单机版别，供给轻量化的单机版别，供开发人员本地测验联调运用。

大规划集群（百万级服务）

北极星操控面是支撑模块化拼装的，各部分功用和接口，比方注册、发现、装备等，能够经过独自开关操控敞开和封闭。为了提高功用的可用性，完成故障阻隔，腾讯内部实践中，对北极星按照功用模块进行集群拆分，服务注册、服务发现、操控台操作划分为不同集群来进行处理，各集群彼此独立，可按照恳求量独立扩展。客户端经过埋点集群的二次寻址机制，为接口寻址到方针集群进行功用接口的调用。

小规划集群（万级以下服务）

大规划集群布置流程相对比较杂乱，且耗费资源较多，为了简化布置进程，北极星支撑全功用集群，可支撑万级以下等级的服务接入。每个北极星节点都是具有了全部的功用，如果当时北极星集群的负载高的话，只需对北极星集群执行水平扩容操作。

单机版（本地开发）

开发人员在程序开发联调进程中，往往需求依靠注册中心，而依靠公共集群注册中心简略产生环境冲突，导致联调结果不精确。北极星也供给单机版才能，开发人员能够在桌面机启动一个个人独占全功用的北极星注册中心进行调测，调测完可随时毁掉。

优势 4：注册中心、服务网格、装备中心一体化

早期的注册中心，如 zookeeper, eureka，只供给了服务注册和发现功用，关于简略的服务调用来说是比较适合的。可是在运用的整个生命周期中，服务调用往往触及杂乱的调度场景，比方在腾讯内部，运用测验阶段需求触及多测验环境的阻隔、在发布阶段需求进行灰度发布和金丝雀发布，在出产环境需求进行依据出产流量的 A/B 测验。这时候就需求依据恳求特性进行流量调度的才能，将服务流量进行精细化导入到对应的服务分组中，也便是现在常说的服务网格。要完成服务网格，除需求依靠注册中心下发服务数据外，还需求进行网格规矩（流量的调度战略等）的办理下发。此外，运用本身的运行所需求的事务装备信息，也需求依靠装备中心进行办理及订阅下发。

为了简化用户对服务网格的运用，业界像 consul 2.0 供给了注册中心、装备中心和服务网格的处理方案。与 consul 相似，北极星操控面将注册中心、服务网格、装备中心功用进行了整合，供给了一体式的服务网格操控面，一起也供给异构数据面及业界干流结构（Spring Cloud，gRPC，TARS 等）扩展，便于运用集成。

总结

腾讯内部服务架构的开展阅历了从单体到分布式再到微服务的开展进程，而服务架构的中心组件注册中心，也阅历了从 L5 单体注册中心，到多注册中心共存，终究一致到北极星的开展进程。北极星作为腾讯现阶段的企业级注册中心，支撑了腾讯万级服务，以及百万服务实例的日常事务恳求调用。依据事务不同的需求，支撑大规划集群、小规划集群、单机版等多种布置形状，在运营进程中经过多次的迭代优化，注册和发现功用均优于平等标准的开源注册中心。北极星已对外开源（开源后名字为 Polaris Mesh），支撑 Spring Cloud、Spring Boot、gRPC、dubbo 等干流结构运用直接接入，欢迎感兴趣的开发者、企业进行体验及参与一起共建。欢迎我们加入北极星交流群：

相关链接

北极星官网：北极星（polarismesh.cn/）

北极星代码库：Polaris Mesh GitHub（github.com/PolarisMesh…