Dubbo+Zookeeper(二）Dubbo架构

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

1、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设计（固然，我是经过实际架构反推出来，手动狗头）

2、Dubbo 核心概念

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

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

学习一门技术，若是有官网的话咱们尽可能从官网上学习：http://dubbo.apache.org/

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

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

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

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

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

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

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

3、架构图

咱们先来看看架构图：

 

 

架构分为5个节点：

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

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

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

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

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

他们的调用关系以下：

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

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

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

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

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

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

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

4、特性

Dubbo 架构具备如下几个特色，分别是连通性、健壮性、伸缩性。

连通性：

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

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

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

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

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

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

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

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

健壮性：

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

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

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

• 注册中心所有宕掉后，服务提供者和服务消费者仍能经过本地缓存通信

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

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

伸缩性：

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

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

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