服务化是企业业务与组织架构解耦的重要途径，随着业务复杂度的增加和开发团队规模的扩大，服务之间的流量路径变得更加复杂，从单向流到业务层、持久层，发展到任意两个服务之间可能的同步或异步调用。针对此场景，有总线型、星状和网状服务拓扑方案可供选择，各自对应不同的服务发现模式。饿了么在服务化初期，选择了网状服务拓扑，以服务网格形式构建服务间调用链。这种拓扑提高了对服务注册中心的依赖，注册中心成为所有服务的不可降级依赖。由于生产环境动态变化，服务注册发现中心的稳定性和可靠性至关重要，这也是饿了么建设服务注册发现中心的重要原因。早期，饿了么使用ZooKeeper作为服务注册和发现解决方案，基于其分布式协调器特性，符合服务注册中心的需求。然而，随着服务数量增长，直接服务连接ZooKeeper存在隐患，最终导致严重事故。事故促使饿了么意识到使用ZooKeeper的局限性，决定采取更稳健的方案。为了解决服务发现的高可用需求，饿了么设计了服务注册中心Huskar，利用ZooKeeper Recipe作为服务发现层，采用HTTP中间件连接ZooKeeper集群，避免了服务直连ZooKeeper的模式，降低了对ZooKeeper的依赖。Huskar通过ZooKeeper Recipe实现递归监听功能，确保服务发现的时序正确性和最终一致性，同时维持快照可读性，在网络中断时提供恢复机制。Huskar作为服务注册中心，托管了饿了么全公司的大量服务，实现了稳定的性能和可靠性。目前，Huskar已经完成了基础功能的开发，并且在服务发现、容载量、高可用性等方面表现出色，保持了高年 uptime 和零事故记录。未来，Huskar将更多地关注配置治理和流量治理等SOA相关话题，通过产品化、平台化增强服务治理能力，逐步实现从“数据平面”向“控制平面”的转型。这将使Huskar能够更细粒度地控制流量分配，支持流量路由、发布策略等功能，进一步提升服务管理和流量调度的效率和灵活性。作者张江阁，2016年加入饿了么，负责服务注册和配置管理中心（Huskar）项目，目前专注于服务治理相关话题和技术中间件产品化实践，致力于提升服务管理和流量调度的能力。
