Dubbo+Zookeeper(二）Dubbo架构

上次更新博客已经是一年前，这一年发生了很多事，并不顺利，甚至有些痛苦，不过不管怎样，不要停止学习，只有学习才能让你变强，应对更多不安定。

一、RPC概念

Dubbo服务是一个RPC框架，那我们首先就要先理解什么叫做RPC， Remote Procedure Call 即远程过程调用。

远程过程调用相对的是本地过程调用，本地过程调用就不用说了，简单理解成本地方法调用函数即可，而远程调用是指调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数。而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

RPC的基本架构图如下：

 RPC框架就是图中的client stub 和说server stub，服务间要相互调用，需要先建立连接。当客户端调用client stub，可能需要传递参数，而在网络间传递，需要进行序列化，序列化完全后将需要调用的消息发送给server stub，服务端收到信息后，先反序列化，然后再调用本地服务，调用完本地服务后，返回处理结果，结果也需要进行序列化，序列化完成之后再返回消息，而client stub 收到消息，也需要再次反序列化，再转换成调用结果，这就是一个完整的RPC过程，如图所示：

RPC 框架就是要实现像那小助手一样的东西，目的就是让我们使用远程调用像本地调用一样简单方便，并且解决一些远程调用会发生的一些问题 ，对于我们来说是无感知的。

在示例图中我们也可以看出，RPC的核心模块就是通讯，序列化。

那如果让我们来设计一个RPC框架，我们的设计思路应该是怎么样的呢？

首先从服务调用者开始，这是一个消费方，我们要消费一个服务，那么这种服务应该是一个接口形式的，这个接口一般是一个公用jar包来定义，当我知道需要调用什么接口时，具体的实现不需要清楚，这些都应该是框架代理来做的，我只需要带接口和参数即可。

消费方不需要知道其中细节，不需要知道要调用那台服务器上的服务，这个时候应该有一个注册中心，这个注册中心有点类似公司大楼的前台物业，他负责指引来客人找到找入驻本栋大楼的公司，每个公司类似服务提供者，公司入驻大大楼后，将自己的楼层和门牌号告诉前台，前台把公司的情况贴在前台指引，那么当有人要找到公司提供服务时，可以直接通过门牌找到想要去的公司，而这个公司搬走后，前台物业又将此公司去掉，消费者需要的服务器是可以直接找到对应公司。

当然，如果你直接告诉了客户你的具体位置，那么客户可以不需要去注册中心找你，也就是注册中心可以不需要。

那作为服务提供者，你要告诉别人你公司能提供的服务器，去实现对应的接口 ，然后暴露出去，也就是去向注册中心注册自己，暴露自己所能提供的服务。 然后有消费者请求过来需要处理，提供者需要用和消费者协商好的协议来处理这个请求，然后做反序列化。

面对众多的服务，精细化的监控和方便的运维必不可少。 这个时候我们需要监控运维 ，也就是监控中心，当然如果你要这么莽，就是不需要监控，当然也是可以的。

到此，我们能想到的架构就是如此，接下里我们就来看看dubbo设计（当然，我是通过实际架构反推出来，手动狗头）

二、Dubbo 核心概念

Dubbo 是阿里巴巴 2011年开源的一个基于 Java 的 RPC 框架，中间沉寂了一段时间，不过其他一些企业还在用 Dubbo 并自己做了扩展，比如当当网的 Dubbox，还有网易考拉的 Dubbok。

在 2018 年和 Dubbox 进行了合并，并且进入 Apache 孵化器，在 2019 年正式成为 Apache 顶级项目。

学习一门技术，如果有官网的话我们尽量从官网上学习：http://dubbo.apache.org/

首先我们要知道Dubbo有哪些特性：

• 面向接口代理的高性能RPC调用： 提供高性能的基于代理的远程调用能力，服务以接口为粒度，为开发者屏蔽远程调用底层细节。

• 智能负载均衡： 内置多种负载均衡策略，智能感知下游节点健康状况，显著减少调用延迟，提高系统吞吐量。

• 服务自动注册与发现： 支持多种注册中心服务，服务实例上下线实时感知。

• 高度可扩展能力： 遵循微内核+插件的设计原则，所有核心能力如Protocol、Transport、Serialization被设计为扩展点，平等对待内置实现和第三方实现。

• 运行期流量调度： 内置条件、脚本等路由策略，通过配置不同的路由规则，轻松实现灰度发布，同机房优先等功能。

• 可视化的服务治理与运维： 提供丰富服务治理、运维工具：随时查询服务元数据、服务健康状态及调用统计，实时下发路由策略、调整配置参数。

三、架构图

我们先来看看架构图：

架构分为5个节点：

服务提供者（ Provider ）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。

服务消费者（ Consumer ）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

注册中心（ Registry ）：注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者

监控中心（ Monitor ）：服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

服务运行容器 （ Container ） ：负责启动，加载，运行服务提供者

他们的调用关系如下：

1. 服务容器负责启动，加载，运行服务提供者。

2. 服务容器负责启动，加载，运行服务提供者。

3. 服务消费者在启动时，向注册中心订阅自己所需的服务。

4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

dubbo的架构非常清晰，也很容易理解，我们在学习的时候，先了解清楚架构情况，然后学会使用，然后再去看源码，了解基础的代码结构。

四、特性

Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性。

连通性：

• 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小

• 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示

• 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销

• 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销

• 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

• 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者

• 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表

• 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

健壮性：

• 监控中心宕掉不影响使用，只是丢失部分采样数据

• 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务

• 注册中心对等集群，任意一台宕掉后，将自动切换到另一台

• 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯

• 服务提供者无状态，任意一台宕掉后，不影响使用

• 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

伸缩性：

• 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心

• 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

好了，Dubbo架构我们有了基础的了解，接下来，我们开始实际例子的开发。