服务化改造实践（一）| Dubbo + ZooKeeper

“没有最好的技术，只有最合适的技术。”我想这句话也同样适用于微服务领域，没有最好的服务框架，只有最适合自己的服务改造。在 Dubbo 的未来规划中，除了保持自身技术上的领先性，关注性能、大流量、大规模集群领域的挑战外，围绕 Dubbo 核心来发展生态，将 Dubbo 打造成一个服务化改造的整体方案也是重点之一。从本期开始，我们将推出“服务化改造”系列文章，通过在一些外围系统和服务化基础组件上的开发实践，分享Dubbo 生态下的服务化改造收获和总结。

? 8月26日，Aliware Open Source 将首次在成都举办 Apache Dubbo 的meetup活动，Dubbo 、Sentinel和 Nacos 的小哥哥和小姐姐都会在现场进行技术分享，欢迎成都的朋友报名参加我们的活动喔，搜索“阿里巴巴中间件”公众号，后台发送“成都meetup”，获取报名链接。

一、改造背景

在现代的分布式应用中，往往会出现节点和节点之间的协调问题，其中就包括了：选主，集群管理，分布式锁，分布式配置管理，统一命名服务，状态同步等诉求。Apache ZooKeeper，正如它的名字所暗示的那样，动物园管理员，就是为了解决这些诉求的一个分布式协调服务框架。

为了保证系统的高可用，ZooKeeper本身也可以部署成集群模式，称之为ZooKeeper Ensemble。ZooKeeper集群中始终确保其中的一台为leader的角色，并通过ZAB（Zookeeper Atomic Broadcast Protocol）[1] 协议确保所有节点上的信息的一致。客户端可以访问集群中的任何一台进行读写操作，而不用担心数据出现不一致的现象。

O'Reilly的ebook-Zookeeper-Distributed Process Coordination

ZooKeeper中的数据存储方式与传统的UNIX文件系统相似，节点按照树状结构来组织，其中，节点被称之为znodes（ZooKeeper数据节点）