Dubbo + zookeeper 是现在比较流行的架构，也是我们行部分系统正在使用的架构，例如支撑平台。下面就介绍一下为什么要使用这个架构和这个架构的工作流程。
上面这个图是dubbo官网的，简单介绍一下工作流程
0.服务器启动
1.生产者向注册中心注册服务
2.消费者向注册中心订阅服务
3.注册中心通知消费者，告知其对应服务器和服务
4.消费者invoke调用生产者服务
5.统计服务注册消费等信息dubbo有什么优点
Dubbo 便于横向扩展
Dubbo使用registry进行服务注册和订阅，当我们新增生产者服务时，只需要向注册中心注册便可，不同以往，需要修改消费者的配置文件才可以实现集群的扩展。
Dubbo 简化了开发过程
对于开发者来说，通过dubbo的框架，消费者和生产者在使用或提供服务时，只需要在配置文件里声明要使用或提供的服务，配上注册中心的配置，便可以使用和调用对应的服务，因此在消费者一侧，无需关心要调用哪台服务器的服务，IP、URL等等信息，调用远程接口的时候也不用像传统的new一个httpclient，然后输入url这样去调用，直接像调用本地接口一样，提高了开发的效率
Dubbo 简化了开发过程
对于开发者来说，通过dubbo的框架，消费者和生产者在使用或提供服务时，只需要在配置文件里声明要使用或提供的服务，配上注册中心的配置，便可以使用和调用对应的服务，因此在消费者一侧，无需关心要调用哪台服务器的服务，IP、URL等等信息，调用远程接口的时候也不用像传统的new一个httpclient，然后输入url这样去调用，直接像调用本地接口一样，提高了开发的效率
Dubbo采用了RPC调度
一个RPC调用服务的工作流程：
- 客户端调用（消费者调用服务）
- 客户端存根打包（通过RPC协议对请求报文进行序列化和打包，这里已经完成了注册中心的订阅，得到了服务的列表，把对应的服务器IP和端口写进报文头里，从而调用对应的服务）
- RPC发送请求（通过client stub发送报文）
- RPC接收（通过server stub 接收报文）
- 服务器端存根解包（通过RPC协议进行解包）
- 调用接口（调用本地接口）
- 返回信息（获得信息后向客户端存根发送返回结果）
- 服务器端存根打包（server stub通过RPC协议对报文进行序列化和打包，这里不用通过注册中心，原路返回）
- RPC请求（通过server stub发送报文）
- RPC接收（client stub接收报文）
- 客户端存根解包（RPC协议解包）
- 客户端获得调用结果（消费者获得返回结果）
可能有人会问，这么多的工作流程，http调用不香么？其实各有各的优点。HTTP调用，每次都会建立一次TCP连接，三次握手四次分手，像平时网银微信的服务器，访问的人多了，就出现很多ESTABLISHED和TIME_WAIT状态的连接，EST状态的连接就不说了，肯定会占用比较多的带宽资源，而TIMEWAIT状态的也会占用一定的资源去等待握手结束。这样对于应用性能和环境资源都不太友好。
而RPC调用通过两边stub进行通讯，这两个相当于一个代理，建立一次TCP连接，每次TCP连接可调用多个接口，这样不仅提高了应用程序的性能，还减少了网络资源的负担。
RPC调用与传统的HTTP调用不同有以下优点：
- 对于开发者，接口层以下都是透明的，只管调用接口
- 减轻了网络的负担
- 提升了程序的性能
zookeeper注册中心
从上面的分析应该可以得出，zookeeper不是dubbo必须的，只是zookeeper暴露的接口和内部机制比较适合作为dubbo的注册中心。
那么zookeeper作为dubbo的注册中心做了什么呢？引用dubbo的架构图，zookeeper做了以下三个步骤：
1. register（服务注册）
2. subscribe（订阅）
3. notify（通知）
这三个步骤主要调用了zookeeper提供的两种接口：
创建节点
zookeeper提供了两种节点，一种是持久节点，一种是临时节点，而dubbo注册服务其实就是在zookeeper上面创建一个节点，然后利用临时节点的特性，当生产者服务器崩溃时，不能提供服务，与zookeeper的连接断开会话结束，就会销毁创建的临时节点，也就是注销服务。这样消费者就不会调用崩溃的服务器的接口。这里可以试着在生产者的服务器上，用防火墙屏蔽其应用端口的出局，模拟应用程序的崩溃，这是监视zookeeper的节点数量，就会发现其节点的数量相比之前减少了，也就是所谓的临时节点被销毁了。
设置监视器
设置监视器的接口实现了订阅和通知，dubbo消费者端在zookeeper的节点上，对需要订阅的服务（也就是一个节点）设置一个监视器
