Dubbo介绍

一.重要的概念

1.1什么是Dubbo

Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的
RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成。Dubbo 框架，是基于容器
运行的.。容器是 Spring。
官方网站 : http://dubbo.apache.org/
阿里巴巴已经将 dubbo 框架捐献给了 Apache 软件基金会

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

什么是RPC
远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底
层网络技术的协议。RPC 协议假定某些传输协议的存在，如 TCP 或 UDP，为通信程序之间
携带信息数据。在 OSI 网络通信模型中，RPC 跨越了传输层和应用层。RPC 使得开发包括
网络分布式多程序在内的应用程序更加容易。

RPC的原理
参考文章:RPC原理详细介绍

1. 服务消费方（client）调用以本地调用方式调用服务；
2. client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3. client stub找到服务地址，并将消息发送到服务端；
4. server stub收到消息后进行解码；
5. server stub根据解码结果调用本地的服务；
6. 本地服务执行并将结果返回给server stub；
7. server stub将返回结果打包成消息并发送至消费方；
8. client stub接收到消息，并进行解码；
9. 服务消费方得到最终结果。

1.3 为什么要用Dubbo

1.3.1产生背景

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服
务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此
时，用于简化增删改查工作量的数据访问框架(ORM)是关键。
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个
应用，以提升效率。此时，用于加速前端页面开发的 Web 框架(MVC)是关键。
分布式服务架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐
渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务
复用及整合的分布式服务框架(RPC)是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中
心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调
度和治理中心(SOA)是关键。

1.3.2需求

在大规模服务化之前，应用可能只是通过 RMI 或 Hessian 等工具，简单的暴露和引用远程服
务，通过配置服务的 URL 地址进行调用，通过 F5 等硬件进行负载均衡。
当服务越来越多时，服务 URL 配置管理变得非常困难，F5 硬件负载均衡器的单点压力也越来
越大。 此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。并通过在消
费方获取服务提供方地址列表，实现软负载均衡和 Failover，降低对 F5 硬件负载均衡器的依赖，
也能减少部分成本。
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，
架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助
架构师理清理关系。
接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什
么时候该加机器？ 为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统
计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一
直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，
再以此访问量乘以机器数反推总容量

1.3.3什么是分布式

分布式或者说 SOA 分布式重要的就是面向服务，说简单的分布式就是我们把整个系统拆分成不同的服务然后将这些服务放在不同的服务器上减轻单体服务的压力提高并发量和性能。比如电商系统可以简单地拆分成订单系统、商品系统、登录系统等等，拆分之后的每个服务可以部署在不同的机器上，如果某一个服务的访问量比较大的话也可以将这个服务同时部署在多台机器上。

1.3.4 为什么要分布式

开发角度来讲单体应用的代码都集中在一起，而分布式系统的代码根据业务被拆分。所以，每个团队可以负责一个服务的开发，这样提升了开发效率。另外，代码根据业务拆分之后更加便于维护和扩展。
另外，我觉得将系统拆分成分布式之后不光便于系统扩展和维护，更能提高整个系统的性能。你想一想嘛？把整个系统拆分成不同的服务/系统，然后每个服务/系统 单独部署在一台服务器上，是不是很大程度上提高了系统性能呢？

二.Dubbo的架构

2.1 Dubbo的架构图

上述节点简单说明

调用关系说明
0 .start: 启动 Spring 容器时,自动启动 Dubbo 的 Provider
1 .register: Dubbo 的 Provider 在启动后自动会去注册中心注册内容.注册的内容包括:
1.1 Provider 的 IP
1.2 Provider 的端口.
1.3 Provider 对外提供的接口列表.哪些方法.哪些接口类
1.4 Dubbo 的版本.
1.5 访问 Provider 的协议.
2 .subscribe: 订阅.当 Consumer 启动时,自动去 Registry 获取到所已注册的服务的信息.
3 .notify: 通知.当 Provider 的信息发生变化时, 自动由 Registry 向 Consumer 推送通知.
4. invoke: 调用. Consumer 调用 Provider 中方法
4.1 同步请求.消耗一定性能.但是必须是同步请求,因为需要接收调用方法后的结
果.
5. count:次数. 每隔 2 分钟,provoider 和 consumer 自动向 Monitor 发送访问次数.Monitor
进行统计.

总结

1. registry
   注册中心. 是用于发布和订阅服务的一个平台.用于替代 SOA 结构体系框架中的 ESB 服
   务总线的。
   开发服务端代码完毕后, 将服务信息发布出去. 实现一个服务的公开.
   客户端程序,从注册中心下载服务内容 这个过程是订阅.
   订阅服务的时候, 会将发布的服务所有信息,一次性下载到客户端.
   客户端也可以自定义, 修改部分服务配置信息. 如: 超时的时长, 调用的重试次数等.

2. consumer
   服务的消费者, 就是服务的客户端.
   消费者必须使用 Dubbo 技术开发部分代码. 基本上都是配置文件定义.

3. provider
   服务的提供者, 就是服务端.
   服务端必须使用 Dubbo 技术开发部分代码. 以配置文件为主.

4. container
   容器. Dubbo 技术的服务端(Provider), 在启动执行的时候, 必须依赖容器才能正常启动.
   默认依赖的就是 spring 容器. 且 Dubbo 技术不能脱离 spring 框架.
   在 2.5.3 版本的 dubbo 中, 默认依赖的是 spring2.5 版本技术. 可以选用 spring4.5 以下版
   本.
   在 2.5.7 版本的 dubbo 中, 默认依赖的是 spring4.3.10 版本技术. 可以选择任意的 spring
   版本.

5. monitor
   监控中心. 是 Dubbo 提供的一个 jar 工程.
   主要功能是监控服务端(Provider)和消费端(Consumer)的使用数据的. 如: 服务端是什么,
   有多少接口,多少方法, 调用次数, 压力信息等. 客户端有多少, 调用过哪些服务端, 调用了
   多少次等.

2.2Dubbo的工作原理

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

各层说明：

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

三.Dubbo的负载均衡策略

百度百科的介绍:
负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡（Load Balance）其意思就是分摊到多个操作单元上进行执行，例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任务。

3.1 Dubbo 提供的负载均衡策略

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

3.1.2 RoundRobin LoadBalance(不推荐，基于权重的轮询负载均衡机制)

3.1.3 LeastActive LoadBalance

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

3.1.4 ConsistentHash LoadBalance

一致性 Hash，相同参数的请求总是发到同一提供者。(如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。)
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
缺省只对第一个参数 Hash，如果要修改，请配置 <dubbo:parameter key=“hash.arguments” value=“0,1” />
缺省用 160 份虚拟节点，如果要修改，请配置 <dubbo:parameter key=“hash.nodes” value=“320” />

3.1.5 配置方式

服务端
<dubbo:service interface=“cn.grace.service.DubboService” ref=“dubboServiceImpl”></dubbo:service>

客户端
<dubbo:reference id=“dubboService” interface=“cn.grace.service.DubboService”></dubbo:reference>