一、背景
单体架构到分布式集群架构带来各种服务之间的调用，有直接http调用与Rpc调用等
Http 和 Rpc 框架的区别
1.虽然现在服务间的调用越来越多地使用了 RPC 和消息队列，但是 HTTP 依然有适合它的场景。
RPC 的优势在于高效的网络传输模型（常使用 NIO 来实现 netty等），以及针对服务调用场景专门设计协议和高效的序列化术。
2.HTTP 的优势在于它的成熟稳定、使用实现简单、被广泛支持、兼容性良好、防火墙友好、消息的可读性高。所以 http 协议在开放 API、跨平台的服务间调用、对性能要求不苛刻的场景中有着广泛的使用。
微服务通信带来的问题
1-目标服务肯定会做扩容，扩容以后，客户端会带来一些变化
2-客户端对于目标服务如何进行负载均衡
3-客户端如何维护目标服务的地址信息
4-服务端的服务状态变化，如何让客户端尽心感知
引入注册中心
服务注册中心主要用于实现服务的注册和服务的发现功能，在微服务架构中，它起到了非常大的作用。
注册中心的实现：
Dubbo 体系中的 Zookeeper、 Spring Cloud 中的 Eureka 和 Consul
二、Zookeeper是什么？
概括
Apache ZooKeeper 是一个高可靠的分布式协调中间件。
设计目的
ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
摘自《从Paxos到Zookeeper 》第四章第一节的某段内容 ：
在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。
功能
ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
Zookeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。 服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。
三、zk基本功能设计
防止单点故障
在分布式架构中，任何的节点都不能以单点的方式存在，因此我们需要解决单点的问题。常见的解决单点问题的方式就是集群
这个集群需要满足：
-1. 集群中要有主节点和从节点（也就是集群要有角色）
-2. 集群要能做到数据同步，当主节点出现故障时，从节点能够顶替主节点继续工作，但是继续工作的前提是数据必须要主节点保持一致
-3. 主节点挂了以后，从节点接替成为主节点
Leader 角色
Leader 服务器是整个 zookeeper 集群的核心，主要的工作任务有两项
-1. 事物请求的唯一调度和处理者，保证集群事物处理的顺序性
-2. 集群内部各服务器的调度者
Follower 角色
Follower 角色的主要职责是
-1. 处理客户端非事物请求、转发事物请求给 leader 服务器
-2. 参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据;
Leader 发起的提案，要求 Follower 投票）
-3. 参与 Leader 选举的投票
Observer 角色
Observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，
不参与任何形式的投票，包括事物请求 Proposal 的投票和 leader 选举的投票 ，
observer 服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力
leader选举
当 leader 挂了，需要从其他 follower 节点中选择一个新的节点进行处理， 这个时候就需要涉及到 leader 选举
zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。 每个 server 都维护的内存状态镜像以及持久化存储的事务日志和快照。
对于 2n+1 台 server，因为只要有 n+1台（过半数形成有效投票） server 可用，就整个系统保持可用 ，允许N台挂掉
数据同步
要满足这样的一个高性能集群，应该每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据一致性，就势必要一个 leader 节点负责协调和数据同步操作。
如果在这样一个集群中没有 leader 节点，每个节点都可以接收所有请求，那么这个集群的数据同步的复杂度是非常大
leader 节点要和其他节点保证数据一致性，并且要求是强一致的。
在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获
取其他分布式节点的操作结果。
所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有 2PC 协议和 3PC 协议
2PC 提交
2PC顾名思义分为两个阶段，其实施思路可概括为：
（1）投票阶段（voting phase）：参与者（各节点）将操作结果通知协调者（leader）；
（2）提交阶段（commit phase）：协调者（leader）收到参与者的通知后，协调者再根据各参与者（各节点）反馈情况决定各参与者是否要提交还是回滚；
四、 Zookeeper 的安装部署
安装
zookeeper 有两种运行模式：集群模式和单击模式。
下载 zookeeper 安装包： http://apache.fayea.com/zookeeper/
下载完成，通过 tar -zxvf 解压
常用命令
-1. 启动 ZK 服务:
bin/zkServer.sh start
-2. 查看 ZK 服务状态:
bin/zkServer.sh status
-3. 停止 ZK 服务:
bin/zkServer.sh stop
-4. 重启 ZK 服务:
bin/zkServer.sh restart
-5. 连接服务器
zkCli.sh -timeout 0 -r -server ip:port
单机环境安装
一般情况下，在开发测试环境，没有这么多资源的情况下，而且也不需要特别好的稳定性的
前提下，我们可以使用单机部署；
初次使用 zookeeper，需要将 conf目录下的zoo_sample.cfg 文件 copy 一份重命名为 zoo.cfg修改 dataDir 目录， dataDir 表示日志文件存放的路径， 在新建的dataDir目录下，新建一个myid文件，就填写为1
然后 bin/zkServer.sh start
集群环境安装
在 zookeeper 集群中，各个节点总共有三种角色，分别是： leader， follower， observer
集群模式我们采用模拟 3 台机器来搭建 zookeeper 集群。分别复制安装包到三台机器上并解
压，同时 copy 一份 zoo.cfg。
1. 修改每个zoo.cfg 配置文件
修改端口（知道彼此 1是谁 2是谁）
server.1=IP1:2888:3888 【2888：访问 zookeeper 的端口； 3888：重新选举 leader 的端口】
server.2=IP2.2888:3888
server.3=IP3.2888:2888
解释：
server.A=B:C:D
其中 A 是一个数字，表示这个是第几号服务器；
B 是这个服务器的 ip 地址；
C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；
D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。
2. myid文件
在dataDir所指定的目录下创建一个文件名为myid的文件，文件中的内容只有一行，为本主机对应的id值，也就是上步中的序号id
3.启动
启动：bin/zkServer.sh start