Dubbo体系式梳理（概述、模型架构、核心要点、应用及配置、部分原理）

1、Dubbo是什么？

Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA治理方案。最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。

2、为什么用Dubbo？

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

（2） 软负载均衡及容错机制: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

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

（4）提供完善的管理控制台dubbo-admin与简单的控制中心dubbo-monitor。

（5）Dubbo提供了伸缩性很好的插件模型，很方便进行扩展（ExtensionLoader）。

（6） 支持多协议 。(dubbo、RMI、Hessian、http等)

3、Dubbo怎么用？

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入， 只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

4、Dubbo模型架构

 

4.1节点角色说明

  Provider: 暴露服务的服务提供方。

  Consumer: 调用远程服务的服务消费方。

  Registry: 服务注册与发现的注册中心。

  Monitor: 统计服务的调用次调和调用时间的监控中心。

  Container: 服务运行容器。

4.2调用关系说明

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

（2）服务提供者在启动时，向注册中心注册自己提供的服务。

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

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

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

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

5、Dubbo核心要点

Dubbo是Alibaba开源的分布式服务框架,按分层结构方式架构,以达到各层间松耦合。可抽象出服务提供方和服务消费方两个角色。

（1）服务定义：服务是围绕服务提供方和服务消费方的，服务提供方实现服务，而服务消费方调用服务。

（2）服务注册：对于服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。

通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。Dubbo提供的注册中心有如下几种类型可供选择：Zookeeper、Redis、Multicast、Simple注册中心。

（3）服务监控：无论是服务提供方，还是服务消费方，他们都需要对服务调用的实际状态进行有效的监控，从而改进服务质量。

（4）远程通信与信息交换:远程通信需要指定通信双方所约定的协议，在保证通信双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通信框架，主要包括如下几个：Netty、Mina、Grizzly。

（5）服务调用：（1）服务提供方发布服务到服务注册中心；

（2）服务消费方从服务注册中心订阅服务；

（3）服务消费方调用已经注册的可用服务

（6）注册/注销服务：服务的注册与注销，是对服务提供方角色而言。

（7）服务订阅/取消:为了满足应用系统的需求，服务消费方的可能需要从服务注册中心订阅指定的有服务提供方发布的服务，在得到通知可以使用服务时，就可以直接调用服务。反过来，如果不需要某一个服务了，可以取消该服务。

（8）协议支持：dubbo支持多种协议,如下所示：Dubbo、HTTP、Thrift、Redis、RMI。在通信过程中，不同的服务等级一般对应着不同的服务质量，那么选择合适的协议便是一件非常重要的事情。你可以根据你应用的创建来选择。例如，使用RMI协议，一般会受到防火墙的限制，所以对于外部与内部进行通信的场景，就不要使用RMI协议，而是基于HTTP协议或者Hessian协议。

参考补充（源码模块概述）：

dubbo-common 公共逻辑模块，包括Util类和通用模型。

dubbo-remoting 远程通讯模块,相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。

dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。

dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡、容错、路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。

dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。

dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。

dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细节。

dubbo-container 容器模块，是一个Standalone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。

6、Dubbo常用配置

（1）服务提供者暴露服务配置 标签：

version	服务版本，建议使用两位数字版本，如：1.0，通常在接口不兼容时版本号才需要升级
group	服务分组，当一个接口有多个实现，可以用分组区分
delay	延迟注册服务时间(毫秒) ，设为-1时，表示延迟到Spring容器初始化完成时暴露服务
timeout	远程服务调用超时时间(毫秒)
retries	远程服务调用重试次数，不包括第一次调用，不需要重试请设为0

（2）服务消费者引用服务配置 ：

version	服务版本，与服务提供者的版本一致
group	服务分组，当一个接口有多个实现，可以用分组区分，必需和服务提供方一致
timeout	服务方法调用超时时间(毫秒)
retries	远程服务调用重试次数，不包括第一次调用，不需要重试请设为0
check	启动时检查提供者是否存在，true报错，false忽略
url	点对点直连服务提供者地址，将绕过注册中心

 

 

 

 

 

附录：

Dubbo负载均衡策略：

（1）Random LoadBalance（随机）：按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。(权重可以在dubbo管控台配置)

（2）RoundRobin LoadBalance（轮询）:按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

（3）LeastActive LoadBalance(最少活跃调用数)：最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

（4）ConsistentHash LoadBalance（一致性哈希）：相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。缺省只对第一个参数Hash，如果要修改，请配置。

Dubbo安全机制：

通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

Dubbo服务集群配置：

（1）Failover Cluster(默认)：失败自动切换，当出现失败，重试其它服务器。(缺省)通常用于读操作，但重试会带来更长延迟。可通过retries="2"来设置重试次数(不含第一次)。

（2）Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。

 

（3）Failsafe Cluster:失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

（4）Failback Cluster:失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。

（5）Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过forks="2"来设置最大并行数。

Dubbo为什么不能传大包：

因dubbo协议采用单一长连接，如果每次请求的数据包大小为500KByte，假设网络为千兆网卡(1024Mbit=128MByte)，每条连接最大7MByte(不同的环境可能不一样，供参考)，单个服务提供者的TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14。如果能接受，可以考虑使用，否则网络将成为瓶颈。

Dubbo通信协议dubbo协议为什么采用异步单一长连接：

因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者多，可能整个网站都在访问该服务，比如Morgan的提供者只有6台提供者，却有上百台消费者，每天有1.5亿次调用，如果采用常规的hessian服务，服务提供者很容易就被压跨，通过单一连接，保证单一消费者不会压死提供者，长连接，减少连接握手验证等，并使用异步IO，复用线程池，防止C10K问题。

Dubbo通信协议适用范围及适用场景：

（1）Dubbo协议：适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。适用场景：常规远程服务方法调用。

（2）RMI协议：RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式，Java标准的远程调用协议。适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。适用场景：常规远程服务方法调用，与原生RMI服务互操作。

（3）Hessian协议：Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。适用场景：页面传输，文件传输，或与原生hessian服务互操作

（4）http协议：采用Spring的HttpInvoker实现,基于http表单的远程调用协议。序列化：表单序列化（JSON）适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。适用场景：需同时给应用程序和浏览器JS使用的服务。

（5）Webservice:序列化：SOAP文本序列化；适用场景：系统集成，跨语言调用。

（6）Thrif:Thrift是Facebook捐给Apache的一个RPC框架，当前 dubbo 支持的 thrift 协议是对 thrift 原生协议的扩展，在原生协议的基础上添加了一些额外的头信息，比如service name，magic number等

 

 

 

 

 

 

 

 

 

 

 

 

 

参考博客：

（1）http://bbs.itheima.com/forum.php?mod=viewthread&tid=386556（附录）

（2）http://shiyanjun.cn/archives/325.html（架构设计，核心要点）