Dubbo引入与概述

引入

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

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起

优点：以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

缺点：

1. 所有功能都部署在一起，当部分功能发生改变时，整个应用都需要重新打包部署，不容易扩展；
2. 协同开发不方便：所有开发者都在这个应用上面去开发，导致开发维护不方便
3. 当单体应用功能越来越多，应用变得越来越大，服务器跑单个大的应用，服务器压力也比较大。增加服务器的集群已经不能带来性能上的提升。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率（每个应用都是一个完整的包含前后端的应用）。此时，用于加速前端页面开发的Web框架(MVC)是关键。技术架构如下图：

优点：

1. 拆分出来的每个应用独立部署在不同的服务器上面，当某个应用的访问压力变大时，可以对该应用单独进行扩容。
2. 开发维护相对容易，不同的团队负责不同的应。
3. 提升性能相对容易，可以针对单个应用进行扩容。

缺点：
应用可能会变的越来越多，并且应用之间不可能完全独立，大量的应用之间需要相互交互。

如业务架构图：订单系统，物流系统，支付系统，商品系统都会调用用户系统，支付系统又会调用商品系统，物流系统也可能会调用商品系统，应用的数量之多，导致系统之间的调用关系也变得更加复杂；其次，每个应用都包含前后端，如果仅仅想更改一下前段界面，后端业务也得跟着重新部署一次，增加了开发维护工作量。

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免（如上图），因此需要将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

如上图所示，此时，前端是一个独立的工程，后端的核心业务抽取为一个单独的服务并单独部署。

以图为例，用户Web前端系统部署在A服务器上，只需要把服务器A重新部署一下就可以了，用户业务不受影响。

而用户的业务系统部署在B服务器上，A服务器上的用户Web想要调用B服务器上的用户业务功能，就不再是单进程内的简单调用了（直接调用相应的方法），此时，需要一个RPC技术来完成远程过程调用。

此外，用户除了调用用户系统的业务，还要调用订单系统，商品系统，支付系统的业务，而用户业务，订单业务，商品业务，支付业务之间，也会存在相互调用的过程，使得服务之间的调用关系也变得复杂起来。

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。如下图所示

概述

Dubbo是一款高性能、轻量级的开源Java RPC 框架，它提供了三大核心能力：

1. 面向接口的远程方法调用；
2. 智能容错和负载均衡；
3. 服务自动注册和发现；
   简单来说Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

什么是 RPC

RPC（Remote Procedure Call）-远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

比如两个不同的服务A，B部署在两台不同的机器上，那么服务A如果想要调用服务B中的某个方法该怎么办呢？使用HTTP请求当然可以，但是可能会比较慢而且一些优化做的并不好。

RPC允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。

RPC原理说明

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

为什么要用 Dubbo

Dubbo的诞生和SOA分布式架构的流行有着莫大的关系。

SOA面向服务的架构(Service Oriented Architecture):
把工程按照业务逻辑拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

SOA架构中有两个角色：
• 服务提供者(Provider)
• 服务使用者(Consumer)

从Dubbo提供的下面四点特性来说为什么要用Dubbo
负载均衡：同一个服务部署在不同的机器时该调用那一台机器上的服务。

服务调用链路生成：随着系统的发展，服务越来越多，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。Dubbo可以为我们解决服务之间互相是如何调用的。

服务访问压力以及时长统计、资源调度和治理：基于访问压力实时管理集群容量，提高集群利用率。

服务降级：某个服务挂掉之后调用备用服务。

Dubbo架构图解

Provider：暴露服务的服务提供方。
Consumer：调用远程服务的服务消费方。
Registry：服务注册与发现的注册中心。
Monitor：统计服务的调用次数和调用时间的监控中心。
Container：服务运行容器。

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

重点知识说明

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

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

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

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

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

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

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

服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

工作原理各层说明

图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为SPI(Service Provider Interface,是一种服务发现机制)。

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

负载均衡策略

负载均衡：负载均衡改善了跨多个计算资源(例如计算机，计算机集群，网络链接，中央处理单元或磁盘驱动)的工作负载分布。

负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间，并避免任何单个资源的过载。使用多个组件的负载平衡可以通过冗余提高可靠性和可用性。

比如我们的系统中的某个服务的访问量特别大，我们将这个服务部署在了多台服务器上，当客户端发起请求的时候，多台服务器都可以处理这个请求。而你仅有一台服务器来处理请求，就不能实现负载均衡。那么，如何正确选择处理该请求的服务器就很关键。负载均衡本就是为了避免单个服务器响应同一请求，容易造成服务器宕机、崩溃等问题。

在集群负载均衡时，Dubbo提供了多种均衡策略，默认为random随机调用。可以自行扩展负载均衡策略。

Random LoadBalance(推荐，基于权重的随机负载均衡机制)：随机，按权重设置随机概率。在一个服务上使用的概率越高，调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

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

ConsistentHash LoadBalance(一致性Hash)：相同参数的请求总是发到同一提供者。(如果你需要的不是随机负载均衡，是一类请求都到一个节点，那就走这个一致性hash策略)。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

Dubbo的健壮性表现

监控中心宕掉不影响使用，只是丢失部分采样数据。
数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务。
注册中心对等集群，任意一台宕掉后，将自动切换到另一台。
注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
服务提供者无状态，任意一台宕掉后，不影响使用。
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

Dubbo的优势

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

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

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

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

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

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

以上总结就是：
• 1.RPC调用性能高
• 2.提供负载均衡实现
• 3.服务注册与发现
• 4.可扩展能力强
• 5.有监控系统，可流控
• 6.方便运维控制