深度剖析Dubbo架构(二）Dubbo+Zookeeper
上次更新博客已经是一年前，这一年发生了很多事，并不顺利，甚至有些痛苦，不过不管怎样，不要停止学习，只有学习才能让你变强，应对更多不安定。
一、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 ） ：负责启动，加载，运行服务提供者
他们的调用关系如下：
-
服务容器负责启动，加载，运行服务提供者。
-
服务容器负责启动，加载，运行服务提供者。
-
服务消费者在启动时，向注册中心订阅自己所需的服务。
-
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
-
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
-
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
dubbo的架构非常清晰，也很容易理解，我们在学习的时候，先了解清楚架构情况，然后学会使用，然后再去看源码，了解基础的代码结构。
四、特性
Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性。
连通性：
-
注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
-
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
-
服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
-
服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
-
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
-
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
-
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
-
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
健壮性：
-
监控中心宕掉不影响使用，只是丢失部分采样数据
-
数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
-
注册中心对等集群，任意一台宕掉后，将自动切换到另一台
-
注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
-
服务提供者无状态，任意一台宕掉后，不影响使用
-
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
伸缩性：
-
注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
-
服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者
好了，Dubbo架构我们有了基础的了解，接下来，我们开始实际例子的开发。
最新2021整理收集的一些高频面试题（都整理成文档），有很多干货，包含mysql，netty，spring，线程，spring cloud、jvm、源码、算法以及最新的简历模板等学习资料，也有详细的学习规划图，面试题整理等，需要获取这些内容的朋友扫描下方二维码免费获取：暗号：【CSDN】
看完三件事❤️
如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
-
点赞，转发，有你们的 『点赞和评论』，才是我创造的动力。
-
关注公众号 『 java烂猪皮 』，不定期分享原创知识。
-
同时可以期待后续文章ing
-
.关注后回复【666】扫码即可获取学习资料包
