到底发生了什么？
在电商架构中，早期是单体架构，可以很快的解决交互问题和产品初期的迭代。但是随着架构的发展，后端无法支撑大流量。一开始的解决办法是增加服务器等垂直解决方法，但是这样的效率太低并且成本太高。因此开发者开始考虑水平伸缩来提高整体的性能。
首先是对产品的拆分：按照类型拆分成不同的模块，那么模块之间的交互就需要实现远程调用，比如webservice。这样其实就简单的形成了一个分布式架构。服务越来越多，我们就拆分的越来越细，随着流量不断提升，后端规模越来越大。举个例子：用户调用订单服务，它是通过http协议来调用，那么首先订单服务那必须给用户一个地址。如果说订单系统是一个大的集群，那么可能我们就需要维护多个这样的地址。那么应该如何解决大规模地址管理？集群里的地址如何去转发？如果其中一个节点down机了怎么办，怎么去管理服务动态上下线感知？
那我们就通过解决以上三个问题来引出本文的主角---Zookeeper
我们可以考虑设置一个中间件，它的存在可以让我们的服务发布的时候注册上去，充当一个电话本，记住你所有的地址，并且及时了解你是不是断开。用户服务只需要拿到中间件的地址，就可以获得对应的相关的调用的目标服务的信息，拿到这个信息，根据负载均衡算法，就可以做一个转发。
Zookeeper是一个什么东西呢？它是一个文件存储类似的树型结构，entry是key-value。每个子节点由父节点管理，子节点是父节点详细的分类。比如说，对于订单服务系统，它的子节点存放着各种地址。Zookeeper适不适合作为一个注册中心？很多人说不是很合适，但是目前大部分企业仍然用它来做注册中心的功能。Zookeeper的学术名称为分布式协调服务，它的本意是解决分布式锁的，比如说几个服务访问共享资源，就会出现资源竞争的问题，这时候就会需要一个协调者来解决这个问题，Zookeeper就是用来解决这个问题的，可以看作一个交警。这样一来共享资源就变成了一个单点访问资源，你先来我中间件里来，我再判断让不让你去访问。当然为了保持单点的特点，Zookeeper一般是以集群出现，在满足单点的功能，提高其可用性。集群的出现带来的问题众所周知，那就是数据同步。Zookeeper内部角色分为Leader、Follower、observer，数据提交方式基于二阶提交，写数据写在follower上，其他的follower去同步数据。请求命令放在leader上，然后让其他的节点知道，这里满足一个CAP原则。
Zookeeper作为一个分布式协调服务，目标是为了解决分布式架构中一致性问题。
Zookeeper客户端可以提供增删改查节点的功能，删除的时候必须一层一层的删除。而且节点具有唯一性，可以参考电脑文件结构。同时节点还分为临时节点 -e和持久化节点、有序节点 -s和无序节点。
Zookeeper应用场景
注册中心、配置中心（和注册中心大同小异，类似于application.properties，用来统一维护配置信息）、负载均衡（知道机器的状态以及选举leader）和分布式锁。
[zk: localhost:2181(CONNECTED) 0] create /userservice 0 Created /userservice [zk: localhost:2181(CONNECTED) 2] ls / [zookeeper, userservice] [zk: localhost:2181(CONNECTED) 3] ls /userservice []