Dubbo 入门

Dubbo介绍

Dubbo是阿里开源的分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA（Service Oriented Architecture面向服务的架构）服务治理方案。

Dubbo定位：一款RPC框架
这就和springcloud区别开来了。springcloud的目标是微服务架构下的一站式解决方案。

其核心功能：
远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式
集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持
自动发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器

为什么选择Dubbo

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

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

分布式应用架构

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

流计算架构

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

以上是从架构层面分析应用的演变历程，那么从实际的开发者角度来看的话，我们也可以这么分析：

单一应用架构
应用和数据库单独部署
应用和数据库集群部署
数据库压力变大，读写分离
使用缓存技术加快速度
数据库分库分表
应用按照类型进行拆分
等等

应用发展到这个阶段，我们发现应用和应用之间的关系已经十分复杂了，就会出现以下问题：

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

以上是 Dubbo 最基本的几个需求。

[图片上传失败...(image-9eaf56-1604481906145)]

从上面的Dubbo服务治理图我们可以看到，Dubbo很好的解决了上面所出现的问题。所以，当你的架构发展到这种阶段的时候，就需要考虑使用Dubbo了。

Dubbo框架

一、技术架构
[图片上传失败...(image-affea9-1604481906145)]

上面就是Dubbo的技术架构，看起来似乎很简单，实际上里面的细节很复杂哟。

节点	角色说明
Provider	暴露服务的服务提供方
Consumer	调用服务的服务消费方
Registry	服务注册与发现的注册中心
Monitor	统计服务调用次数和调用时间的监控中心
Container	服务运行容器

调用关系说明：

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

二、Dubbo特点

Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。

连通性

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销服务
消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

健壮性

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

伸缩性

注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

升级性

当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力。下图是未来可能的一种架构：
[图片上传失败...(image-58d692-1604481906145)]

节点	角色说明
Deployer	自动部署服务的本地代理
Repository	仓库用于存储服务应用发布包
Scheduler	调度中心基于访问压力自动增减服务提供者
Admin	统一管理控制台
Registry	服务注册与发现的注册中心
Monitor	统计服务的调用次数和调用时间的监控中心

Dubbo优劣势

优点

透明化的远程方法调用，像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入；
软负载均衡及容错机制，可在内网替代nginx lvs等硬件负载均衡器；
服务注册中心自动注册&配置管理，不需要写死服务提供者地址，注册中心基于接口名自动查询提供者ip；
服务接口监控与治理,Dubbo-admin与Dubbo-monitor提供了完善的服务接口管理与监控功能，针对不同应用的不同接口，可以进行多版本、多协议、多注册中心管理。

缺点

只支持Java语言
Dubbo 只支持 RPC 调用。这使得服务提供方与调用方在代码上产生了强依赖，服务提供方需要不断将包含公共代码的 Jar 包打包出来供消费方使用。一旦打包出现问题，就会导致服务调用出错。
Registry 严重依赖第三方组件（ZooKeeper 或者 Redis），当这些组件出现问题时，服务调用很快就会中断。（虽然消费者本地会有缓存服务列表）

入门demo

1. 服务端
首先把服务端接口写好，简单来说，Dubbo就是给消费端提供接口的。

package com.cmos.dubbo.provider.service;

/**
 * TODO
 *
 * @AUTHOR ZhaoChengcai
 * @DATE 2020/9/1
 */
public interface ProviderService {
    String sayHello(String name);
}

这个接口很简单，只有一个sayHello方法。
接着，定义该接口的实现类。

package com.cmos.dubbo.provider.service.impl;

import com.cmos.dubbo.provider.service.ProviderService;

/**
 * TODO
 *
 * @AUTHOR ZhaoChengcai
 * @DATE 2020/9/1
 */
public class ProviderServiceImpl  implements ProviderService {
    public String sayHello(String name) {
        return name;
    }
}

这样，我们的接口就写好了，接下来就考虑把服务暴露出去。
导入相应的maven依赖：



    4.0.0

    com.cmos
    dubbo-provider
    1.0-SNAPSHOT

    
        
            log4j
            log4j
            1.2.12
        
        
            com.alibaba
            dubbo
            2.6.6
        
        
            org.apache.zookeeper
            zookeeper
            3.4.10
        
        
            com.101tec
            zkclient
            0.5
        
        
            io.netty
            netty-all
            4.1.32.Final
        
        
            org.apache.curator
            curator-framework
            2.8.0
        
        
            org.apache.curator
            curator-recipes
            2.8.0

这里我们的Dubbo使用版本2.6.6，另外，使用zookeeper作为注册中心。

截至目前，dubbo需要的环境已经ok了，接下来，我们考虑把上面定义的接口暴露出去。

1.1 暴露接口（xml配置方法）

resource目录下新建provider.xml文件，如下图

[图片上传失败...(image-30227f-1604481906145)]

provider.xml内容，

上面的文件类似spring配置文件，况且dubbo底层就是spring。
①节点：dubbo:application
就是整个项目在分布式架构中的唯一名称，可以在name属性中配置，另外还可以配置owner字段，表示属于谁。
下面的参数是可以不配置的，这里配置是因为出现了端口冲突，所以配置。
②节点：dubbo：monitor
监控中心配置，用于配置连接监控中心相关信息，可以不配置，不是必须参数。
③节点：dubbo:registry
配置注册中心的信息，比如，这里我们可以配置zookeeper作为我们的注册中心。address是注册中心的地址，这里如果配置的是N/A表示由dubbo自动分配地址，或者说是一种直连的方式，不通过注册中心。
④节点：dubbo:protocol
服务发布的时候，dubbo依赖什么协议，可以配置dubbo，webservice，thrift，Hessain，http等。
⑤节点：dubbo:service
这个节点是重点，当我们服务发布的时候，就是通过这个配置将我们的服务发布出去，interface是接口的包路径，ref是配置的接口bean。
最后，我们需要像配置spring接口一样，配置接口的bean。

1.2 发布服务
到这一步，关于服务端的配置就完成了，下面通过main方法把接口发布出去。

package com.cmos.dubbo.provider;

import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 * TODO
 *
 * @AUTHOR ZhaoChengcai
 * @DATE 2020/9/1
 */
public class App {
    public static void main(String[] args) throws Exception{
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("provider.xml");
        context.start();
        System.in.read();
    }
}

发布接口很简单，因为dubbo底层就是依赖spring的，所以，我们只需要通过ClassPathXmlApplicationContext拿到我们配置好的xml，然后调用context.start()方法就启动了，看到下面的截图证明启动成功，并把服务发布出去了。
[图片上传失败...(image-2b7896-1604481906145)]

2 消费端
上面提到，我们服务端提供的服务是点对点的方式，也就是采用直连，没有用注册中心，所以消费端的配置要稍微有点区别。

2.1 消费端环境配置
[图片上传失败...(image-ee9c2d-1604481906145)]

分析：
1.发现这里的dubbo:application和dubbo:registry是一致的。

dubbo:reference:我们这里采用点对点的方式，所以需要配置服务端暴露的URL.

2.2 消费端maven依赖



    4.0.0

    com.cmos
    dubbo-consumer
    1.0-SNAPSHOT

    
        
            log4j
            log4j
            1.2.12
        
        
            com.alibaba
            dubbo
            2.6.6
        
        
            org.apache.zookeeper
            zookeeper
            3.4.10
        
        
            com.101tec
            zkclient
            0.5
        
        
            io.netty
            netty-all
            4.1.32.Final
        
        
            org.apache.curator
            curator-framework
            2.8.0
        
        
            org.apache.curator
            curator-recipes
            2.8.0
        
        
            com.cmos
            dubbo-provider
            1.0-SNAPSHOT

这里配置基本和服务端一样，唯一的不同就是，把服务端服务mvn intall,并在消费端引入服务端的依赖。

2.3 调用服务

package com.cmos.dubbo.consumer;

import com.cmos.dubbo.provider.service.ProviderService;
import org.springframework.context.support.ClassPathXmlApplicationContext;

/**
 * TODO
 *
 * @AUTHOR ZhaoChengcai
 * @DATE 2020/9/1
 */
public class AppConsumer {
    public static void main(String[] args)  throws Exception{
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("consumer.xml");
        context.start();
        ProviderService providerService = (ProviderService)context.getBean("providerService");
        String str = providerService.sayHello("xiaoming");
        System.out.println(str);
        System.in.read();
    }

}

启动服务，如下证明成功。
[图片上传失败...(image-168c73-1604481906145)]

3. 加入zookeeper作为注册中心的话，请参考上述服务端和消费端的注释配置信息。更改即可。

上面是通过xml配置方式进行了dubbo环境配置，官方还提供了api配置、注解配置方式。
但是api配置方式不是官方推荐的，官方推荐xml配置方式，但是随着微服务的普及，注解方式越来越得到大家的推崇，我在本地做demo的时候也实现了注解方式，具体代码请参考：
dubbo入门实例demo