蚂蚁集团注册中心 SOFARegistry 开发实践之路
蚂蚁集团注册中心发展历程
蚂蚁集团注册中心 SOFARegistry 经历了五个主要演进阶段，以应对不断增长的业务需求和技术挑战：
V1：淘宝 configserver 架构
- 采用单节点 master/slave 备份架构
- 问题：容量瓶颈、容灾风险
V2：横向扩展架构
- 拆分 session/data 水平扩展
- session 处理连接，data 数据分片存储
- 问题：运维成本高（serverlist 维护）
V3/V4：LDC 支持和容灾架构
- 单元化支持，引入容灾机制
- 问题：运维成本高（serverlist 维护）、跨集群服务发现
V5（SOFARegistry）：新增 meta(raft) 和数据分片
- meta(raft) 维护 serverlist
- 数据分片采用一致性 hash，多副本容灾
V6（SOFARegistry）：架构优化
- meta 去强一致性依赖
- 数据分片采用 SlotTable
- 数据多副本容灾采用 diff sync
SOFARegistry 核心能力与特性对比
- 服务健康检查：支持多种检查方式（http/tcp/script/docker），定期健康检查或心跳保持会话
- Kv 存储服务：支持 Kv 存储
- 一致性：最终一致性（raft/ZAB/cap）
- 使用接口：支持 http 和多种语言客户端
- watch：支持服务端推送
- 安全：支持 acl 和 https
- 集成：支持 spring cloud
主要挑战与解决方案
挑战
- 数据规模增长：扩展能力需求
- 集群数增长：运维成本增加
- 业务 7*24 运维：可用性保障
- 云原生挑战：应用实例数快速增长、生命周期短、快速交付需求
解决方案
- 架构优化：应用级服务发现、降数据规模、移除 raft、节点无状态
- 数据分片：Slot 和 SlotTable 机制
- 容灾备份：集群容灾备份，2 分钟逃逸能力
SOFARegistry 6.0 目标
效能目标
- 架构：应用级服务发现、降数据规模、移除 raft、节点无状态、增强数据片管控能力
- 性能：优化数据通信性能，支撑更大规模
质量效能目标
- 测试：SOFARegistryChaos 自动化测试、功能回归、性能测试、疲劳测试、混沌测试
- 运维：nightly build、灰度环境自动发布、运维标准化、交付成本低、可观测、自愈
运维效能目标
- nightly build：自动化构建
- 故障演练：常规化线上故障攻防演练
- 定位诊断：快速定位和诊断问题
SOFARegistry 6.0 架构原则
- 最终一致性：明确可预期，时间延迟但数据完整性
- 数据分片存储：避免单节点存储全部数据，横向扩展
性能规模
- session：240 个节点
- data：50 个节点
- client：10 万+
- 地址列表 IP 数：1K~7.2K
- 包大小：250K~1.8M
应用级特性
- 数据模型：应用级数据模型
- 兼容性：平滑/遗留应用双集群双订阅发布切换
- 效果：数据下降 1 个数量级
SOFARegistryChaos 自动化测试
- 功能测试：基于 k8s 一键部署、横向扩展支持大规模压测、client 编排（pub/sub/disconnect）、故障编排
- 观测性：端到端推送延迟分步观测、数据完整性校验
- 失败 case：故障注入校验正确性/恢复时间
开源与共赢
强调开源社区的协作价值，通过共享技术实现共赢。
