关于服务发现:降本提效注册中心在蚂蚁集团的蜕变之路

文|林育智（花名：源三 )

蚂蚁团体高级专家 专一微服务 / 服务发现相干畛域

校对|李旭东

本文 8624 字 浏览 18 分钟

|引 言|

服务发现是构建分布式系统的最重要的依赖之一，在蚂蚁团体承当该职责的是注册核心和 Antvip，其中注册核心提供机房内的服务发现能力，Antvip 提供跨机房的服务发现能力。

本文探讨的重点是注册核心和多集群部署状态（IDC 维度），集群和集群之间不波及到数据同步。

PART. 1 背 景

回顾注册核心在蚂蚁团体的演进，大略起始于 2007/2008 年，至今演进超过 13 年。时至今日，无论是业务状态还是本身的能力都产生了微小的变动。

简略回顾一下注册核心的历代倒退：

V1：引进淘宝的 configserver

V2：横向扩大

从这个版本开始，蚂蚁和阿里开始独立的演进，最次要的差别点是在数据存储的方向抉择上。蚂蚁抉择了横向扩大，数据分片存储。阿里抉择了纵向扩大，加大 data 节点的内存规格。

这个抉择影响到若干年后的 SOFARegistry 和 Nacos 的存储架构。

V3 / V4：LDC 反对和容灾

V3 反对 LDC 单元化。

V4 减少了决策机制和运行时列表，解决了单机宕机时须要人工染指解决的问题，肯定水平上晋升高可用和缩小运维老本。

V5：SOFARegistry

前四个版本是 confreg，17 年启动 V5 我的项目 SOFARegistry，指标是：

1. 代码可维护性：confreg 代码历史包袱较重

• 大量模块应用 guice 做依赖治理，但大部分模块是动态类交互，不容易拆散外围模块和扩大模块，不利于产品开源。
• 客户端与服务端的交互模型嵌套简单，了解老本极高且对多语言不敌对。

2. 运维痛点：引入 Raft 解决 serverlist 的保护问题，整个集群的运维包含 Raft，通过 operator 来简化。

3. 鲁棒性：在一致性 hash 环减少多节点备份机制（默认 3 正本），2 正本宕机业务无感。

4. 跨集群服务发现：站内跨集群服务发现额定须要 antvip 撑持，心愿能够对立 2 套设施的能力，同时商业化场景也有跨机房数据同步的需要。

这些指标局部实现了，局部实现的还不够好，例如运维痛点还残留一部分，跨集群服务发现在面对主站的大规模数据下稳定性挑战很大。

V6：SOFARegistry 6.0

2020 年 11 月，SOFARegistry 总结和排汇外部 / 商业化打磨的教训，同时为了应答将来的挑战，启动了 6.0 版本大规模重构打算。

历时 10 个月，实现新版本的开发和降级工作，同时铺开了利用级服务发现。

PART. 2 挑 战

当下面临的问题

集群规模的挑战

• 数据增长：随着业务的倒退，业务的实例数在一直增长，pub/sub 的数量也相应增长。以其中一个集群为例，2019 年的数据为基准数据，在 2020 年 pub 靠近千万级。

下图是该集群历年双十一时的数据比照和切换利用级的优化成果。相比 2019 年双十一，2021 年双十一接口级的 pub 增长 200%，sub 增长 80%。

• 故障爆炸半径增长：集群接入的实例越多，故障影响的业务和实例数也就越多，保障业务的稳固是最根底也是优先级最高的要求。
• 考验横向扩大能力：集群达到肯定的规模后，是否还具备持续横向扩大的能力，须要集群具备良好的横向扩大能力，从 10 扩到 100 和从 100 扩到 500 是不一样的难度。
• HA 能力：集群实例数多了后，面临的节点总体的硬件故障率也相应增高，各种机器故障集群是否能疾速复原？有运维教训的同学都晓得，运维一个小集群和运维一个大集群面临的艰难几乎是指数级增长。
• 推送性能：大多数服务发现的产品都抉择了数据的最终一致性，然而这个最终在不同集群的规模下到底是多久？相干的产品其实都没有给出明确的数据。

然而实际上，咱们认为这个指标是服务发现产品的外围指标。这个时长对调用有影响：新加的地址没有流量；删除的地址没有及时摘除等。蚂蚁团体的 PaaS 对注册核心的推送时延是有 SLO 束缚的：如果变更推送列表延时超过约定值，业务端的地址列表就是谬误的。咱们历史上也曾产生过因推送不及时导致的故障。

业务实例规模减少的同时也带来推送的性能压力：公布端 pub 上面的实例数减少；订阅端业务实例数减少；一个简略的估算，pub/sub 增长 2 倍，推送的数据量是 2*2，增长 4 倍，是一个乘积的关系。同时推送的性能也决定了同一时间能够反对的最大运维业务实例数，例如应急场景下，业务大规模重启。如果这个是瓶颈，就会影响故障的复原工夫。

集群规模能够认为是最有挑战性的，外围的架构决定了它的下限，确定后革新老本十分高。而且往往等到发现瓶颈的时候曾经是兵临城下了，咱们要抉择能拉高产品技术天花板的架构。

运维的挑战

SOFARegistryX 立项时的一个次要指标是具备比 confreg 更好的运维能力：引入 meta 角色，通过 Raft 选举和存储元信息，提供集群的管制面能力。然而事实证明，咱们还是低估了可运维的重要性，正如鲁迅学生说：【程序员的工作只有两件事件，一件是运维，另一件还是运维】。

三年前的指标放到明天曾经重大滞后了。

• 集群数增长：蚂蚁团体外部的业务是分站点部署的（简略了解为每个站点是一块绝对比拟独立的业务，须要不同级别的隔离），同时一个站点须要部署多套集群：容灾须要分机房部署；开发须要分多环境。部署站点的数目增长超出咱们的想像。当初曾经达到数百个集群了，还在迅速增长中，增长速度参考最近几年美联储的货币供应量增长速度。以前认为有些运维工作能够苟且，人肉顶一下，集群数增长后，苟且次数太多了，挤占了开发 / 运维同学的精力，齐全没资源去布局诗和远方。

• 业务打搅：业务的运维是全天候 7*24 的，容量自适应 / 自愈 /MOSN 每月一版本把全站利用犁一遍等等。下图是每分钟运维的机器批数，能够看到，就算是周末和深夜，运维工作也是一直的。

蚂蚁团体的同学对注册核心的运维布告应该是比拟相熟和痛恨的。因为业务的敏感性，注册核心之前始终是停机公布和运维，这个时候须要锁定全站的公布 / 重启动作。为了尽量少影响业务，注册核心相干的同学只能献祭一头黑发，在深夜低峰期做相干的操作。即便这样，依然没方法做到对业务零打搅。

云原生时代 naming 的挑战

云原生的技术时代下，能够察看到一些趋势：

• 微服务 /FaaS 的推广导致轻型利用增多：实例数增多，须要能撑持更大的业务规模
• 利用实例的生命周期更短：FaaS 按需应用，autoscale 容量自适应等伎俩导致实例的落潮涨潮更频繁，注册核心的性能次要体现在实例变更的响应速度上
• 多语言反对：在过来，蚂蚁团体次要的开发体系是 Java，非 Java 语言对接基础设施都是二等公民，随着 AI 和创新性业务的需要，非 Java 体系的场景越来越多。如果依照每种语言一个 SDK，保护老本会是个噩梦，当然 sidecar（MOSN）是个解法，然而本身是否能反对低侵入性的接入形式，甚至 sdk-free 的能力？
• 服务路由：在过来绝大部分的场景都能够认为 endpoint 是平等的，注册核心只提供通信的地址列表是能够满足需要的。在 Mesh 的准确路由场景外面，pilot 除了提供 eds（地址列表）也同时提供 rds（routing），注册核心需丰盛本身的能力。
• K8s：K8s 以后曾经成为事实上的分布式操作系统，K8s-service 如何和注册核心买通？更进一步，是否能解决 K8s-service 跨 multi-cluster 的问题？

「总结」

综上，除了好高鹜远，解决当下的问题，还须要俯视星空。具备解决云原生趋势下的 naming 挑战的可能性，也是 V6 重构的次要指标。

PART. 3 SOFARegistry 6.0：面向效力

SOFARegistry 6.0 不只是一个注册核心引擎，须要和周边的设施配合，晋升开发、运维、应急的效力，解决以下的问题。（红色模块是比拟有挑战性的畛域）

SOFARegistry 6.0 相干的工作包含：

架构优化

架构的革新思路：在保留 V5 的存储分片架构的同时，重点的指标是优化元信息 meta 一致性和确保推送正确的数据。

元信息 meta 一致性

V5 在 meta 角色中引入 Raft 的强一致性进行选举 leader 和寄存元信息，其中元信息包含节点列表和配置信息。数据的分片通过获取 meta 的节点列表做一致性 hash，这外面存在两个问题：

• Raft/operator 运维简单

  （1）定制运维流程：须要反对 change peer 等编排。在蚂蚁团体，特化的运维流程老本较高，同时也不利于输入。

  （2）实现一个生产强壮的 operator 老本十分高，包含接入变更管控 operator 本身的变更三板斧等。

  （3）对于网络 / 磁盘的可用性比拟敏感。在输入的场景，会面临比拟顽劣的硬件状况，排查老本较高。

• 软弱的强一致性

meta 信息的应用建设在满足强一致性的状况下，如果呈现网络问题，例如有 session 网络分区连不上 meta，谬误的路由表会导致数据决裂。须要机制确保：即便 meta 信息不统一也能在短时间内维持数据的正确性，留有应急的缓冲工夫。

推送正确的数据

当 data 节点大规模运维时，节点列表激烈变动导致数据一直迁徙，推送进来的数据存在完整性 / 正确性的危险。V5 通过引 3 副原本防止这种状况，只有有一个正本可用，数据就是正确的，然而该限度对运维流程累赘很大，咱们要确保每次操作少于两个正本或者挑选出满足束缚的运维序列。

对于 V5 及之前的版本，运维操作是比拟毛糙的，一刀切做停机公布，通过锁 PaaS 禁止业务变更，等 data 节点稳固后，再关上推送能力来确保防止推送谬误数据的危险。

此外，预期的运维工作能够这样做，然而对于突发的多 data 节点宕机，这个危险依然是存在的。

咱们须要有机制确保：data 节点列表变动导致数据迁徙时，容忍承受额定的轻微推送时延，确保推送数据正确。

「成绩」

• meta 存储 / 选举 组件插件化，站内去 Raft，应用 db 做 leader 选举和存储配置信息，升高运维老本。
• 数据应用固定 slot 分片，meta 提供调度能力，slot 的调度信息通过 slotTable 保留，session/data 节点可容忍该信息的弱一致性，晋升鲁棒性。
• 多正本调度缩小 data 节点变动时数据迁徙的开销，当火线上的数据量 follower 降级 leader 大略 200ms (follower 持有绝大部分的数据)，间接调配 leader 数据同步耗时 2s-5s。
• 优化数据通信 / 复制链路，晋升性能和扩大能力。
• 大规模运维不须要深夜锁 PaaS，缩小对业务打搅和保住运维人员头发，晋升幸福感。

数据链路和 slot 调度：

• slot 分片参考 Redis Cluster 的做法，采纳虚构哈希槽分区，所有的 dataId 依据哈希函数映射到 0 ~ N 整数槽内。
• meta 的 leader 节点，通过心跳感知存活的 data 节点列表，尽可能平均的把 slot 的多正本调配给 data 节点，相干的映射关系保留在 slotTable，有变更后被动告诉给 session/data。
• session/data 同时通过心跳获取最新的 slotTable，防止 meta 告诉生效的危险。
• slot 在 data 节点上有状态机 Migrating -> Accept -> Moved。迁徙时确保 slot 的数据是最新的才进入 Accept 状态，才能够用于推送，确保推送数据的完整性。

data 节点变动的数据迁徙：

对一个接入 10w+ client 的集群进行推送能力压测，分钟级 12M 的推送量，推送提早 p999 能够放弃在 8s 以下。session cpu20%，data cpu10%，物理资源水位较低，还有较大的推送 buffer。

同时咱们也在线上验证横向扩大能力，集群尝试最大扩容到 session370，data60，meta*3；meta 因为要解决所有的节点心跳，CPU 达到 50%，须要 8C 垂直扩容或者进一步优化心跳开销。依照一个 data 节点的平安水位撑持 200w pub，一个 pub 大略 1.5K 开销，思考容忍 data 节点宕机 1/3 依然有服务能力，须要保留 pub 上涨的 buffer，该集群可撑持 1.2 亿的 pub，如果配置双正本则可撑持 6kw 的 pub。

利用级服务发现

注册核心对 pub 的格局保留很强的灵活性，局部 RPC 框架实现 RPC 服务发现时，采纳一个接口一个 pub 的映射形式，SOFA/HSF/Dubbo2 都是采纳这种模式，这种模型比拟天然，然而会导致 pub/sub 和推送量收缩十分厉害。

Dubbo3 提出了利用级服务发现和相干原理【1】。在实现上，SOFARegistry 6.0 参考了 Dubbo3，采纳在 session 端集成服务的元数据中心模块的计划，同时在兼容性上做了一些适配。

「利用级服务 pub 数据拆分」

「兼容性」

利用级服务发现的一个难点是如何低成本的兼容接口级 / 利用级，尽管最初大部分的利用都能降级到利用级，降级过程中会面临以下问题：

• 利用数多，同时各个利用降级到利用级的工夫点差距比拟大
• 局部利用无奈降级，例如一些远古利用

咱们采纳以利用级服务为主，同时兼容接口级的解决方案：

在降级时同时存在新旧版本的两个 SOFARegistry，不同版本的 SOFARegistry 对应到不同的域名。降级后的利用端（图中的 MOSN）采纳双订阅双公布的形式逐渐灰度切换，确保切换过程中，没有降级接入 MOSN 或者没有关上开关的利用不受影响。

在实现绝大多数利用的利用级迁徙后，降级后的利用都曾经到了 SOFARegistry 6.0 版本的注册核心上，但依然存在大量利用因为没有接入 MOSN，这些余留的 old app 也通过域名切换到 SOFARegistry 6.0，持续以接口级订阅公布和注册核心交互。为了确保已降级的和没降级的利用可能相互订阅，做了一些反对：

• 提供利用级 Publisher 转接到口级 Publisher 的能力：接口级订阅端是无奈间接订阅利用级公布数据的，针对接口级订阅按需从 AppPublisher 转换出 InterfacePublisher，没有接入 MOSN 的利用能够顺利的订阅到这部分数据，因为只有大量利用没有接入 MOSN，须要转化的利用级 Publisher 很少。
• 利用级订阅端在订阅的时候额定发动一个接口级的订阅，用于订阅没有接入降级的利用公布数据。因为这部分利用非常少，理论绝大多数的服务级订阅都不会有推送工作，因而对推送不会造成压力。

「成果」

上图是一个集群切换利用级后的成果，其中切换后残余局部接口级 pub 是为了兼容转换进去的数据，接口级 sub 没缩小也是为了兼容接口级公布。如果不思考兼容性，pub 数据缩小高达 97%。极大的加重了数据规模的对集群的压力。

SOFARegistryChaos：自动化测试

注册核心的最终一致性的模型始终是个测试难题：

• 最终是多久？
• 达到最终前有没有推送谬误的数据
• 达到最终前有没有推送少数据
• 集群产生故障 / 数据迁徙时对数据的正确性和时延的影响
• client 端频繁依照各种顺序调用 API 的影响
• client 端频繁连贯断连的影响

针对该系列问题，咱们开发了 SOFARegistryChaos，特地针对最终一致性提供齐备的测试能力，除此还提供性能 / 性能 / 大规模压测 / 混沌测试等能力。同时，通过插件化的机制，也反对接入测试其余服务发现产品的能力，基于 K8s 的部署能力，能让咱们疾速的部署测试组件。

具备以上的能力后，不单能够测试本身的产品能力，例如还能够疾速的测试 zookeeper 在服务发现方面的相干性能来做产品比拟。

测试观测性

提供的要害数据的观测能力，通过 metrics 透出，对接 Prometheus 即可提供可视化能力：

• 推送时延
• 设定工夫内的最终一致性检测
• 产生故障注入的工夫点
• 最终统一期间推送数据的完整性
  该能力的测试是一个比拟有意思的翻新点，通过固化一部分的 client 和对应的 pub，校验每次其余各种变更导致的推送数据，这部分数据都必须是要残缺和正确的。
• 推送次数
• 推送数据体积

失败 case 的排查

测试场景中，client 操作时序和故障注入都是随机编排的，咱们在 SOFARegistryChaos master 端记录和收集了所有的操作命令时序。当 case 失败时，可通过失败的数据明细和各个 client 的 API 调用状况来疾速定位问题。

例如下图的失败 case 显示在某个 Node 上的订阅者对某个 dataId 的订阅数据没通过校验，预期是应该要推空，然而推送了一条数据下来。同时显示了该 dataId 所有相干的 publisher 在测试期间的相干操作轨迹。

黑盒探测

大家是否经验过相似的 case：

• 忽然被业务告知零碎呈现问题，一脸懵的我：零碎没异样啊
• 发现零碎呈现故障时，理论曾经对业务造成了重大影响

注册核心因为自身的个性，对业务的影响往往是滞后的，例如 2K 个 IP 只推送了 1K 个，这种谬误不会导致业务马上感知到异样。然而理论自身曾经出问题了。对于注册核心，更须要有提前发现治末病的能力。

这里咱们引入黑盒探测的形式：模仿狭义上的用户行为，探测链路是否失常。

SOFARegistryChaos 实际上就能够作为一个注册核心的用户，并且是加强版的，提供端到端的告警能力。

咱们把 SOFARegistryChaos 部署到线上，开启小流量作为一个监控项。当注册核心异样但还没对业务造成可感知的影响时，咱们有机会及时染指，缩小危险事件升级成大故障的危险。

磨刀不误砍柴工

通过 SOFARegistryChaos，外围能力的验证效率极大晋升，品质失去保障的同时，开发同学写代码也轻松了许多。从 7 月份到 10 月中的 3 个半月工夫里，咱们迭代并公布了 5 个版本，靠近 3 周 1 个版本。这个开发效率在以前是不敢设想的，同时也取得欠缺的端到端告警能力。

运维自动化

nightly build

尽管咱们集群数目十分多，然而因为是辨别了多环境，局部环境对于稳定性的要求绝对生产流量要求略微低一些，例如灰度以下的环境。这些环境的集群是否能够在新版本保证质量的状况下，疾速低成本的 apply。联合 SOFARegistryChaos，咱们和品质 /SRE 的同学正在建设 nightly build 设施。

SOFARegistryChaos 作为变更门禁，新版本自动化的部署，承受 SOFARegistryChaos 的测试通过后，自动化部署到灰度以下的集群，仅在生产公布时候人工染指。

通过 nightly build，极大的加重非生产环境的公布老本，同时新版本能尽早承受业务流量的测验。

故障演练

尽管咱们做了大量的品质相干的工作，然而在线上面对各种故障时到底体现如何？是骡子还是马，还是要拉进去溜一溜。

咱们和 SRE 的同学在线上会定期做故障容灾演练，包含但不限于网络故障；大规模机器宕机等。另外演练不能是一锤子买卖的事件，没有保鲜的容灾能力其实等于 0。在仿真 / 灰度集群，进行容灾常态化，演练 - 迭代循环。

定位诊断

故障容灾演练常态化后，如何疾速的定位到故障源成了摆在桌子上的一个问题，否则每次演练都鸡飞狗跳的，效率太低了。

SOFARegistry 各个节点做了大量的可观测性的改良，提供丰盛的可观测能力，SRE 的诊断系统通过相干数据做实时诊断，例如这个 case 里就是一个 session 节点故障导致 SLO 破线。有了定位能力后，自愈零碎也能够发挥作用，例如某个 session 节点被诊断出网络故障，自愈零碎能够触发故障节点的自动化替换。

目前，咱们的容灾演练应急绝大部分 case 曾经不须要人肉染指，也只有这样低成本的演练能力常态化。

「收益」

通过一直的演练裸露问题和疾速迭代修复，SOFARegistry 的稳定性逐渐晋升。

「总结」

SOFARegistry 6.0 除了本身的优化，在测试 / 运维 / 应急方面做了大量的工作，指标是晋升研发 / 品质 / 运维人员的效力，让相干同学解脱低效的人肉工作，晋升幸福感。

PART. 4 开源：一个人能够走得很快，但一群人能够走的更远

SOFARegistry 是一个开源我的项目，也是开源社区 SOFAStack 重要的一环，咱们心愿用社区的力量推动 SOFARegistry 的后退，而不是只有蚂蚁团体的工程师去开发。

在过来一年，SOFARegistry 因为重心在 6.0 重构上，社区简直处于停滞状态，这个是咱们做得不够好的中央。

咱们制订了将来半年的社区打算，在 12 月份会基于外部版本开源 6.0，开源的代码蕴含外部版本的所有外围能力，惟一区别是外部版本多了对 confreg-client 的兼容性反对。

另外从 6.1 后，咱们心愿后继的方案设计 / 探讨也是基于社区来发展，整个研发过程更通明和凋谢。

PART. 5 咱们仍在路上

2021 年是 SOFARegistry 扫视过来，全面夯实根底，晋升效力的一年。

当然，咱们以后还依然处在初级阶段，后面还有很长的路要走。例如往年双十一的规模面临一系列十分辣手的问题：

• 一个集群内单利用实例数过多（热点利用单集群高达 7K 个实例）导致业务端收到地址推送时 CPU/memory 开销过大。
• 全地址列表推送，导致的连接数过多等。

还有其余的挑战：

• 增量推送，缩小推送数据量和 client 端的资源开销
• 对立服务发现，反对跨集群
• 适应云原生下的新趋势
• 社区的经营
• 产品易用性

「参 考」

【1】Dubbo3 提出了利用级服务发现和相干原理：

https://dubbo.apache.org/zh/b…

对于咱们：

蚂蚁应用服务团队是服务于整个蚂蚁团体的核心技术团队，打造了世界领先的金融级分布式架构的基础设施平台，是 Service Mesh 等云原生畛域的领先者，开发运维着寰球最大的 Service Mesh 集群，蚂蚁团体的消息中间件每天撑持上万亿的音讯流转。

欢送对 Service Mesh/ 微服务 / 服务发现 等畛域感兴趣的同学退出咱们。

分割邮箱：yuzhi.lyz@antgroup.com

本周举荐浏览

稳定性大幅度晋升：SOFARegistry v6 新个性介绍

咱们做出了一个分布式注册核心

Prometheus on CeresDB 演进之路）

如何在生产环境排查 Rust 内存占用过高问题