｜引 言｜
服务发现是构建分布式系统的最重要的依赖之一， 在蚂蚁集团承担该职责的是注册中心和 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 倍，是一个乘积的关系。同时推送的性能也决定了同一时间可以支持的最大运维业务实例数，例如应急场景下，业务大规模重启。如果这个是瓶颈，就会影响故障的恢复时间。
集群规模可以认为是最有挑战性的，核心的架构决定了它的上限，确定后改造成本非常高。而且往往等到发现瓶颈的时候已经是兵临城下了，我们要选择能拉高产品技术天花板的架构。
运维的挑战
SOFARegistry 立项时的一个主要目标是具备比 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 重构的主要目标。
