服务化的演变
分布式应用架构体系对于业务逻辑复用的需求十分强烈，上层业务都想借用已有的底层服务，来快速搭建更多、更丰富的应用，降低新业务开展的人力和时间成本，快速满足瞬息万变的市场需求。公共的业务被拆分出来，形成可共用的服务，最大程度地保障了代码和逻辑的复用，避免重复建设，这种设计也称为SOA (Service-Oriented Architecture)。
SOA架构中，服务消费者通过服务名称，在众多服务中找到要调用的服务的地址列表，称为服务的路由。
当服务的规模较小时，可以采用硬编码的方式将服务地址和配置写在代码中，通过编码的方式来解决服务的路由和负载均衡问题，也可以通过传统的硬件负载均衡设备如F5等，或者采用LVS或Nginx等软件解决方案，通过相关配置，来解决服务的路由和负载均衡问题。
此时，需要一个能够动态注册和获取服务信息的地方，来统一管理服务名称和其对应的服务器列表信息，称之为服务配置中心。如图1-17所示，服务提供者在启动时，将其提供的服务名称、服务器地址注册到服务配置中心，服务消费者通过服务配置中心来获得需要调用的服务的机器列表，通过相应的负载均衡算法，选取其中一台服务器进行调用。当服务器宕机或者下线时，相应的机器需要能够动态地从服务配置中心里面移除，并通知相应的服务消费者，否则服务消费者就有可能因为调用到已经失效的服务而发生错误。在这个过程中，服务消费者只有在第一次调用服务时需要查询服务配置中心，然后将查询到的信息缓存到本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求到服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更(机器上线或者下线)。这种无中心化的结构解决了之前负载均衡设备所导致的单点故障问题，并且大大减轻了服务配置中心的压力。
基于ZooKeeper的持久和非持久节点，我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。通过集群间zab协议，使得服务配置信息能够保持一致。而ZooKeeper 本身容错特性和leader选举机制，能保障我们方便地进行扩容。通过ZooKeeper来实现服务动态注册、机器上线与下线的动态感知，扩容方便，容错性好，且无中心化结构能够解决之前使用负载均衡设备所带来的单点故障问题，只有当配置信息更新时才会去ZooKeeper上获取最新的服务地址列表，其他时候使用本地缓存即可。基于ZooKeeper的服务配置中心的搭建，后面章节会有详细介绍，此处不再赘述。