关于java:Dubbo-总结关于-Dubbo-的重要知识点

一 重要的概念

1.1 什么是 Dubbo?

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大外围能力：面向接口的近程办法调用，智能容错和负载平衡，以及服务主动注册和发现。简略来说 Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 近程服务调用计划，以及 SOA 服务治理计划。

Dubbo 目前曾经有靠近 23k 的 Star，Dubbo 的 Github 地址：https://github.com/apache/incubator-dubbo。另外，在开源中国举办的 2018 年度最受欢迎中国开源软件这个流动的评比中，Dubbo 更是凭借其超高人气仅次于 vue.js 和 ECharts 取得第三名的好问题。

Dubbo 是由阿里开源，起初退出了 Apache。正式因为 Dubbo 的呈现，才使得越来越多的公司开始应用以及承受分布式架构。

咱们下面说了 Dubbo 实际上是 RPC 框架，那么什么是 RPC 呢？

1.2 什么是 RPC?RPC 原理是什么?

什么是 RPC？

RPC（Remote Procedure Call）—近程过程调用，它是一种通过网络从近程计算机程序上申请服务，而不须要理解底层网络技术的协定。比方两个不同的服务 A、B 部署在两台不同的机器上，那么服务 A 如果想要调用服务 B 中的某个办法该怎么办呢？应用 HTTP 申请当然能够，然而可能会比拟麻烦。RPC 的呈现就是为了让你调用近程办法像调用本地办法一样简略。

RPC 原理是什么？

我这里这是简略的提一下。具体内容能够查看上面这篇文章：

http://www.importnew.com/22003.html

1. 服务生产方（client）调用以本地调用形式调用服务；
2. client stub 接管到调用后负责将办法、参数等组装成可能进行网络传输的音讯体；
3. client stub 找到服务地址，并将音讯发送到服务端；
4. server stub 收到音讯后进行解码；
5. server stub 依据解码后果调用本地的服务；
6. 本地服务执行并将后果返回给 server stub；
7. server stub 将返回后果打包成音讯并发送至生产方；
8. client stub 接管到音讯，并进行解码；
9. 服务生产方失去最终后果。

上面再贴一个网上的时序图：

说了这么多，咱们为什么要用 Dubbo 呢？

1.3 为什么要用 Dubbo?

Dubbo 的诞生和 SOA 分布式架构的风行有着莫大的关系。SOA 面向服务的架构（Service Oriented Architecture），也就是把工程依照业务逻辑拆分成服务层、体现层两个工程。服务层中蕴含业务逻辑，只须要对外提供服务即可。体现层只须要解决和页面的交互，业务逻辑都是调用服务层的服务来实现。SOA 架构中有两个次要角色：服务提供者（Provider）和服务使用者（Consumer）。

如果你要开发分布式程序，你也能够间接基于 HTTP 接口进行通信，然而为什么要用 Dubbo 呢？

我感觉次要能够从 Dubbo 提供的上面四点个性来说为什么要用 Dubbo：

1. 负载平衡 ——同一个服务部署在不同的机器时该调用那一台机器上的服务。
2. 服务调用链路生成 ——随着零碎的倒退，服务越来越多，服务间依赖关系变得错踪简单，甚至分不清哪个利用要在哪个利用之前启动，架构师都不能残缺的形容利用的架构关系。Dubbo 能够为咱们解决服务之间相互是如何调用的。
3. 服务拜访压力以及时长统计、资源调度和治理 ——基于拜访压力实时治理集群容量，进步集群利用率。
4. 服务降级 ——某个服务挂掉之后调用备用服务。

另外，Dubbo 除了可能利用在分布式系统中，也能够利用在当初比拟火的微服务零碎中。不过，因为 Spring Cloud 在微服务中利用更加宽泛，所以，我感觉个别咱们提 Dubbo 的话，大部分是分布式系统的状况。

咱们刚刚提到了分布式这个概念，上面再给大家介绍一下什么是分布式？为什么要分布式？

1.4 什么是分布式?

分布式或者说 SOA 分布式重要的就是面向服务，说简略的分布式就是咱们把整个零碎拆分成不同的服务而后将这些服务放在不同的服务器上加重单体服务的压力进步并发量和性能。比方电商零碎能够简略地拆分成订单零碎、商品零碎、登录零碎等等，拆分之后的每个服务能够部署在不同的机器上，如果某一个服务的访问量比拟大的话也能够将这个服务同时部署在多台机器上。

1.5 为什么要分布式?

从开发角度来讲单体利用的代码都集中在一起，而分布式系统的代码依据业务被拆分。所以，每个团队能够负责一个服务的开发，这样晋升了开发效率。另外，代码依据业务拆分之后更加便于保护和扩大。

另外，我感觉将零碎拆分成分布式之后不光便于零碎扩大和保护，更能进步整个零碎的性能。你想一想嘛？把整个零碎拆分成不同的服务 / 零碎，而后每个服务 / 零碎 独自部署在一台服务器上，是不是很大水平上进步了零碎性能呢？

二 Dubbo 的架构

2.1 Dubbo 的架构图解

上述节点简略阐明：

• Provider： 裸露服务的服务提供方
• Consumer： 调用近程服务的服务生产方
• Registry： 服务注册与发现的注册核心
• Monitor： 统计服务的调用次数和调用工夫的监控核心
• Container： 服务运行容器

调用关系阐明：

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册核心注册本人提供的服务。
3. 服务消费者在启动时，向注册核心订阅本人所需的服务。
4. 注册核心返回服务提供者地址列表给消费者，如果有变更，注册核心将基于长连贯推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载平衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用工夫，定时每分钟发送一次统计数据到监控核心。

重要知识点总结：

• 注册核心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册核心交互，注册核心不转发申请，压力较小
• 监控核心负责统计各服务调用次数，调用工夫等，统计先在内存汇总后每分钟一次发送到监控核心服务器，并以报表展现
• 注册核心，服务提供者，服务消费者三者之间均为长连贯，监控核心除外
• 注册核心通过长连贯感知服务提供者的存在，服务提供者宕机，注册核心将立刻推送事件告诉消费者
• 注册核心和监控核心全副宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
• 注册核心和监控核心都是可选的，服务消费者能够直连服务提供者
• 服务提供者无状态，任意一台宕掉后，不影响应用
• 服务提供者全副宕掉后，服务消费者利用将无奈应用，并有限次重连期待服务提供者复原

2.2 Dubbo 工作原理

图中从下至上分为十层，各层均为单向依赖，左边的彩色箭头代表层之间的依赖关系，每一层都能够剥离下层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。

各层阐明 ：

• 第一层：service 层 ，接口层，给服务提供者和消费者来实现的
• 第二层：config 层 ，配置层，次要是对 dubbo 进行各种配置的
• 第三层：proxy 层 ，服务接口通明代理，生成服务的客户端 Stub 和服务器端 Skeleton
• 第四层：registry 层 ，服务注册层，负责服务的注册与发现
• 第五层：cluster 层 ，集群层，封装多个服务提供者的路由以及负载平衡，将多个实例组合成一个服务
• 第六层：monitor 层 ，监控层，对 rpc 接口的调用次数和调用工夫进行监控
• 第七层：protocol 层 ，近程调用层，封装 rpc 调用
• 第八层：exchange 层 ，信息替换层，封装申请响应模式，同步转异步
• 第九层：transport 层 ，网络传输层，形象 mina 和 netty 为对立接口
• 第十层：serialize 层 ，数据序列化层，网络传输须要

三 Dubbo 的负载平衡策略

3.1 先来解释一下什么是负载平衡

先来个官网的解释。

维基百科对负载平衡的定义：负载平衡改善了跨多个计算资源（例如计算机，计算机集群，网络链接，地方处理单元或磁盘驱动的的工作负载散布。负载平衡旨在优化资源应用，最大化吞吐量，最小化响应工夫，并防止任何单个资源的过载。应用具备负载平衡而不是单个组件的多个组件能够通过冗余进步可靠性和可用性。负载平衡通常波及专用软件或硬件。

下面讲的大家可能不太好了解，再用艰深的话给大家说一下。

比方咱们的零碎中的某个服务的访问量特地大，咱们将这个服务部署在了多台服务器上，当客户端发动申请的时候，多台服务器都能够解决这个申请。那么，如何正确抉择解决该申请的服务器就很要害。如果，你就要一台服务器来解决该服务的申请，那该服务部署在多台服务器的意义就不复存在了。负载平衡就是为了防止单个服务器响应同一申请，容易造成服务器宕机、解体等问题，咱们从负载平衡的这四个字就能显著感触到它的意义。

3.2 再来看看 Dubbo 提供的负载平衡策略

在集群负载平衡时，Dubbo 提供了多种平衡策略，默认为 random 随机调用。能够自行扩大负载平衡策略，参见：负载平衡扩大。

备注: 上面的图片来自于：尚硅谷 2018Dubbo 视频。

3.2.1 Random LoadBalance(默认，基于权重的随机负载平衡机制)

• 随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大散布越平均，而且按概率使用权重后也比拟平均，有利于动静调整提供者权重。

3.2.2 RoundRobin LoadBalance(不举荐，基于权重的轮询负载平衡机制)

• 轮循，按公约后的权重设置轮循比率。
• 存在慢的提供者累积申请的问题，比方：第二台机器很慢，但没挂，当申请调到第二台时就卡在那，长此以往，所有申请都卡在调到第二台上。

3.2.3 LeastActive LoadBalance

• 起码沉闷调用数，雷同沉闷数的随机，沉闷数指调用前后计数差。
• 使慢的提供者收到更少申请，因为越慢的提供者的调用前后计数差会越大。

3.2.4 ConsistentHash LoadBalance

• 一致性 Hash，雷同参数的申请总是发到同一提供者。(如果你须要的不是随机负载平衡，是要一类申请都到一个节点，那就走这个一致性 hash 策略。)
• 当某一台提供者挂时，本来发往该提供者的申请，基于虚构节点，平摊到其它提供者，不会引起激烈变动。
• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
• 缺省只对第一个参数 Hash，如果要批改，请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用 160 份虚构节点，如果要批改，请配置 <dubbo:parameter key="hash.nodes" value="320" />

3.3 配置形式

xml 配置形式

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />

客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />

服务端办法级别

<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

客户端办法级别

<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

注解配置形式：

生产方基于基于注解的服务级别配置形式：

@Reference(loadbalance = "roundrobin")
HelloService helloService;

四 zookeeper 宕机与 dubbo 直连的状况

zookeeper 宕机与 dubbo 直连的状况在面试中可能会被常常问到，所以要引起器重。

在理论生产中，如果 zookeeper 注册核心宕掉，一段时间内服务生产方还是可能调用提供方的服务的，实际上它应用的本地缓存进行通信，这只是 dubbo 健壮性的一种体现。

dubbo 的健壮性体现：

1. 监控核心宕掉不影响应用，只是失落局部采样数据
2. 数据库宕掉后，注册核心仍能通过缓存提供服务列表查问，但不能注册新服务
3. 注册核心对等集群，任意一台宕掉后，将主动切换到另一台
4. 注册核心全副宕掉后，服务提供者和服务消费者仍能通过本地缓存通信
5. 服务提供者无状态，任意一台宕掉后，不影响应用
6. 服务提供者全副宕掉后，服务消费者利用将无奈应用，并有限次重连期待服务提供者复原

咱们后面提到过：注册核心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册核心交互，注册核心不转发申请，压力较小。所以，咱们能够齐全能够绕过注册核心——采纳 dubbo 直连 ，即在服务生产方配置服务提供方的地位信息。

xml 配置形式：

<dubbo:reference id="userService" interface="com.zang.gmall.service.UserService" url="dubbo://localhost:20880" />

注解形式：

 @Reference(url = "127.0.0.1:20880")   
 HelloService helloService;