Zookeeper＋Dubbo 搭建RPC框架架构原理详述

Zookeeper是什么？

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户，简单来说，他就是代替了我们以前的数据库去存储一些key值。

Dubbo是什么？

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）

其核心部分包含:

1. 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

2. 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

3. 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

dubbo服务容器是一个standalone的启动程序，因为后台服务不需要Tomcat或JBoss等Web容器的功能，如果硬要用Web容器去加载服务提供方，增加复杂性，也浪费资源。 服务容器只是一个简单的Main方法，并加载一个简单的Spring容器，用于暴露服务。 服务容器的加载内容可以扩展，内置了spring, jetty, log4j等加载，可通过Container扩展点进行扩展，参见：Container Spring Container 自动加载META-INF/spring目录下的所有Spring配置。

RPC框架是什么？

RPC全称为Remote Procedure Call，翻译过来为“远程过程调用”。目前，主流的平台中都支持各种远程调用技术，以满足分布式系统架构中不同的系统之间的远程通信和相互调用。远程调用的应用场景极其广泛，实现的方式也各式各样。

正如上边所说，如果我们有一个很大的系统，系统里有一些通用的功能，比如支付模块、登陆模块、客服模块等等，这是我们就可以将他们独立出来，在不同的地方用同一个模块，RPC正是这种思想的扩展，我们将这些独立出来的模块称为微服务，架构图如下：

Zookeeper+Dubbo搭建RPC

以Zookeeper服务为基础，我们使用Dubbo框架去监视和调度我们的各个服务，生产者在zookeeper上注册服务，消费者去zookeeper上调用服务，前提是双方都允许，zookeeper就是中间的控制方，起到运维的作用。

工作原理简介

1、zookeeper服务器相当于一个中介，把生产者的服务提供给消费者。

2、生产者相当于提供服务的一方，生产者写。好自己的服务后在zookeeper服务器上注册一下，会获得一个带有自己标识的key，然后zookeeper服务器就能加载到这个生产者所提供的服务列表，当生产者的某台服务器宕机时，zookeeper服务器会更新到，然后更新此生产者服务列表。

3、消费者就是使用某些服务的一方，消费者在zookeeper服务器上注册自己的信息也会获得一个key，当消费者需要生产者的某个服务是，就回去zookeeper获取相应生产者的key然后加载到相应的服务列表。

在后续的访问中消费者会将生产者的ip域名之类的东西缓存到本地，下次就可以直接去访问消费者服务器，不用再通过zookeeper去查找了。

那么问题来了，如果有一台消费者服务器宕机了咋办？

我们的消费者访问会有一定的容错量，当请求失败后会继续请求几次，如果还会失败就回去请求zookeeper，获得生产者的备用服务器，并更新列表可用生产者服务器的列表。