饿了么服务注册中心（Huskar）的发展历程可分为早期探索、架构优化、稳定性提升和未来治理四个阶段，其核心目标是通过服务化架构支撑业务增长，同时解决高可用、可扩展性和治理能力等关键问题。以下是具体发展路径：
服务化背景饿了么业务复杂化后，采用网状拓扑（Service Mesh）替代总线型或星状拓扑，以减少内网带宽浪费和运维成本。但这一选择高度依赖服务注册中心，因其故障会导致所有服务调用中断。
ZooKeeper 初期方案
技术选型：早期仅支持 Python 服务时，选择 ZooKeeper 作为注册中心，基于其分布式协调能力和时序一致性。
实现方式：
注册：服务节点写入 ZooKeeper 对应目录，成功即视为启动完成。
发现：通过 watch 原语监听实例节点变更，更新本地缓存供连接池使用。
跨语言支持：引入 Java 和 Go 服务后，将 Python SDK 逻辑封装为 HTTP 服务，通过 HTTP Comet Polling 推送变更事件。
初期问题
竞态条件：ZooKeeper Recipe 实现不稳定，易出现数据竞争。
事故触发：网络抖动导致 ZooKeeper session 重建风暴，引发 P2 级事故，关键服务长时间不可用。
问题根源分析
容载能力不匹配：服务发现需求随业务迭代动态变化，而 ZooKeeper 的 observer 节点在高并发场景下成为瓶颈。
高可用缺陷：ZooKeeper 决议成员（Leader/Follower）重启或网络分区会导致 observer 停止服务，违背服务发现“高可用”要求。
Session 压力：客户端重建 session 需 Leader 投票，大量请求导致事务日志写入延迟，形成恶性循环。
架构重构
中间件层引入：下线 Python 服务直连 ZooKeeper 的 SDK，改用 HTTP 中间件（Huskar）统一封装 ZooKeeper Recipe。
连接优化：
Huskar 节点数目有限，减少对 ZooKeeper 决议集群的压力。
移除 observer 节点，直接连接决议集群，避免跨城域网络抖动风险。
技术栈：基于 Python 的 Gevent + Gunicorn 实现多进程协程处理 IO，使用 Kazoo 作为 ZooKeeper 客户端。
关键改进：TreeCache 移植
问题：原递归监听实现存在消息丢失和乱序。
解决方案：移植 Netflix Curator 的 TreeCache 算法，通过维护内存快照（Snapshot）和比对 Znode 元信息（zxid）保证事件时序正确性和最终一致性。
效果：
高可用：Session 可靠时持续更新，丢失时保留快照。
可扩展：Huskar 作为弱状态服务支持横向扩容。
规模化托管
托管全公司 2000+ 服务，实例、配置项、开关数目接近百万。
部署双活机房，通过复制中间件实现 ZooKeeper 跨地域非强一致复制。
性能指标
日常 HTTP Comet 长连接数约 5 万，推送事件峰值 2kps。
年 Uptime 达 99.996%，保持零事故记录。
社区贡献
修复 TreeCache 实现问题并回馈上游，提升开源生态。
治理能力升级
集群路由：Huskar 动态决定服务调用方推送的集群成员列表，实现流量无感切换。
细粒度管控：参考 Netflix 实践，探索 Canary 发布、自动流量回退等场景，与发布平台、容器平台打通。
产品化目标
定位为 SOA 的“控制平面”，与“数据平面”（如连接池、软负载）协同，提升服务治理效率。
目标：80% 精力投入治理而非开发，解决易开发难治理的痛点。
Huskar 的发展历程体现了饿了么从服务化初期探索到规模化治理的技术演进：
这一过程不仅解决了业务增长带来的技术挑战，也为服务化架构的治理提供了可复制的实践路径。
