Dubbo之——Dubbo高级

发表于 更新于 分类于 阅读次数： 本文字数： 24k 阅读时长 ≈ 22 分钟

1. 基础知识

1.1 分布式基础理论

1

2

3

1.1 分布式系统概述

《分布式系统原理与范型》定义：

“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”

分布式系统（distributed system）是建立在网络之上的软件系统。

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

1.2 发展演变

4

1.2.1 单一应用架构

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

5

适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。

缺点：

1、性能扩展比较难

2、协同开发问题

3、不利于升级维护

1.2.2 垂直应用架构

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

6

通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。

缺点： 公用模块无法重复利用，开发性的浪费

1.2.3 分布式服务架构

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

7

8

1.2.3 流动计算架构

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

9

1.3 RPC

1.3.1 什么是RPC

RPC【Remote Procedure Call】是指远程过程调用，是一种进程间通信方式，他是一种技术的思想，而不是规范。

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

1.3.2 RPC基本原理

RPC两个核心模块：通讯，序列化。

10

1.2 dubbo核心概念

1.2.1 简介

Apache Dubbo |ˈdʌbəʊ| 提供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

11

官网：

http://dubbo.apache.org/

12

https://dubbo.apache.org/zh/docs/concepts/service-discovery/

1.2.2 基本概念

服务提供者（Provider）：暴露服务的服务提供方，服务提供者在启动时，向注册中心注册自己提供的服务。

服务消费者（Consumer）: 调用远程服务的服务消费方，服务消费者在启动时，向注册中心订阅自己所需的服务，服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

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

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

调用关系说明：

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

13

1.3 dubbo环境搭建（了解）

Nacos 作为注册中心，已搭建无需重复搭建。

1.3.1【windows】-安装dubbo-admin管理控制台

dubbo本身并不是一个服务软件。它其实就是一个jar包能够帮你的java程序连接到nacos，并利用nacos消费、提供服务。所以你不用在Linux上启动什么dubbo服务。

但是为了让用户更好的管理监控众多的dubbo服务，官方提供了一个可视化的监控程序，不过这个监控即使不装也不影响使用。

  1. 下载dubbo-admin https://github.com/apache/dubbo-admin
  2. 进入目录，修改dubbo-admin配置 修改 src\main\resources\application.properties 指定nacos地址
  3. 打包dubbo-admin mvn clean package -Dmaven.test.skip=true
  4. 运行dubbo-admin java -jar dubbo-admin-0.0.1-SNAPSHOT.jar

> 注意：【有可能控制台看着启动了，但是网页打不开，需要在控制台按下ctrl+c即可】 默认使用root/root 登陆

1.3.2【linux】-安装dubbo-admin管理控制台

2 安装dubbo-admin

  1. 下载dubbo-admin https://github.com/apache/dubbo-admin
  2. 进入目录，修改dubbo-admin配置 修改 src\main\resources\application.properties 指定nacos地址
  3. 打包dubbo-admin
1
mvn clean package -Dmaven.test.skip=true
  1. 运行dubbo-admin java -jar dubbo-admin-0.0.1-SNAPSHOT.jar 默认使用root/root 登陆

1.4 搭建监控中心（了解）

1.4.1 dubbo-admin

图形化的服务管理页面；安装时需要指定注册中心地址，即可从注册中心中获取到所有的提供者/消费者进行配置管理

参考官网

1.4.2 dubbo-monitor-simple

简单的监控中心；

  1. 安装

1、下载 dubbo-ops https://github.com/apache/incubator-dubbo-ops

2、修改配置指定注册中心地址 进入 dubbo-monitor-simple\src\main\resources\conf 修改 dubbo.properties文件

nacos地址和http访问端口（Jetty）

4、解压 tar.gz 文件，并运行start.bat 【 如果缺少servlet-api，自行导入servlet-api再访问监控中心】

5、启动访问8080

  1. 监控中心配置
1
2
3
所有服务配置连接监控中心，进行监控统计
<!-- 监控中心协议，如果为protocol="registry"，表示从注册中心发现监控中心地址，否则直连监控中心 -->
<dubbo:monitor protocol="registry"></dubbo:monitor>

Simple Monitor 挂掉不会影响到 Consumer 和 Provider 之间的调用，所以用于生产环境不会有风险。

Simple Monitor 采用磁盘存储统计信息，请注意安装机器的磁盘限制，如果要集群，建议用mount共享磁盘。

1.5 SpringCloud Alibaba Dubbo【重要】

导入资料基础工程

1、引入依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.itheima.dubbo</groupId>
    <artifactId>dubbo-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
    <modules>
        <module>dubbo-interface</module>
        <module>dubbo-producer</module>
        <module>dubbo-web</module>
    </modules>
    <packaging>pom</packaging>

    <name>dubbo-parent</name>
    <url>http://www.example.com</url>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <interFace.version>1.0-SNAPSHOT</interFace.version>
        <!--spring-cloud-alibaba版本-->
        <spring-cloud-alibaba.version>2.1.4.RELEASE</spring-cloud-alibaba.version>
        <!--spring-boot版本-->
        <spring.boot.version>2.1.6.RELEASE</spring.boot.version>

    </properties>

    <!--声明jar-->
    <dependencyManagement>
        <dependencies>
            <!--接口定义层-->
            <dependency>
                <groupId>com.itheima.dubbo</groupId>
                <artifactId>dubbo-interface</artifactId>
                <version>${interFace.version}</version>
            </dependency>
            <!---spring-cloud-alibaba主配置-->
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>${spring-cloud-alibaba.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <!---springboot主配置-->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>${spring.boot.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <build>
        <plugins>
            <!--jdk插件-->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.2</version>
                <configuration>
                    <source>8</source>
                    <target>8</target>
                </configuration>
            </plugin>

            <!--springboot的打包插件-->
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <version>2.3.0.RELEASE</version>
            </plugin>

            <!-- maven-surefire-plugin 测试包 -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.4.2</version>
                <configuration>
                    <!-- 全局是否执行maven生命周期中的测试：是否跳过测试 -->
                    <skipTests>true</skipTests>
                    <!-- 解决测试中文乱码-->
                    <forkMode>once</forkMode>
                    <argLine>-Dfile.encoding=UTF-8</argLine>
                </configuration>
            </plugin>

        </plugins>
    </build>
</project>

注意：版本的控制

14

2、配置application.properties

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
### 提供者配置：
#服务配置
server:
  #端口
  port: 8080
  #服务编码
  tomcat:
    uri-encoding: UTF-8
#spring相关配置
spring:
  #应用配置
  application:
    #应用名称
    name: dubbo-producer
  main:
    allow-bean-definition-overriding: true
  cloud:
    #nacos注册中心
    nacos:
      discovery:
        server-addr: 192.168.200.129:8848
dubbo:
  #dubbo服务版本
  application:
    version: 1.1.0
    logger: slf4j
  #dubbo接口扫描路径
  scan:
    base-packages: com.itheima.dubbo
  #dubbo服务注册
  registry:
    address: spring-cloud://192.168.200.129
  #dubbo服务协议类型及端口，线程数【这里是默认配置】
  protocol:
    name: dubbo
    port: 20880
    threads: 200
    accesslog: logs/dubbo-producer-01.log

  cloud:
    subscribed-services:

消费方：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#服务配置
server:
  #端口
  port: 8081
  #服务编码
  tomcat:
    uri-encoding: UTF-8
#spring相关配置
spring:
  #应用配置
  application:
    #应用名称
    name: dubbo-web
  main:
    allow-bean-definition-overriding: true
  #nacos注册中心
  cloud:
    nacos:
      discovery:
        server-addr: 192.168.200.129:8848

#dubbo消费端配置
dubbo:
  application:
    version: 1.0.0
    logger: slf4j
  cloud:
#    #表示要订阅服务的服务名，可以配置'*'，代表订阅所有服务，不推荐使用。若需订阅多应用，使用 "," 分割。
    subscribed-services: dubbo-producer
  scan:
    #扫描路径
    base-packages: com.itheima.dubbo.web
  registry:
    address: spring-cloud://192.168.200.129
    #dubbo服务协议类型及端口，线程数【这里是默认配置】
  protocol:
    name: dubbo
    port: 28081
    threads: 200
    accesslog: logs/dubbo-web-01.log

3、添加dubbo注解

服务提供方：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package com.itheima.dubbo.service;

import com.itheima.dubbo.UserInterface;
import org.apache.dubbo.config.annotation.DubboService;

/**
 * @Description: 幂等性操作
 * @Version: V1.0
 */
@DubboService
public class UserServiceImpl implements UserInterface {

    @Override
    public String hello(String username) {
        System.out.println("UserServiceImpl......");
        return "Hello Dubbo username: " + username;
    }
}

消费方：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

package com.itheima.dubbo.web;

import com.itheima.dubbo.UserInterface;
import org.apache.dubbo.config.annotation.DubboReference;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

/**
 * @Description:
 * @Version: V1.0
 */
@RestController
@RequestMapping("user")
public class UserController {

    @DubboReference
    UserInterface userInterface;


    @GetMapping("hello")
    public String hello(String username) {
        return userInterface.hello(username);
    }

}

注意：【如果没有在配置中写dubbo.scan.base-package,还需要使用@EnableDubbo注解】

4、启动测试

2. dubbo配置

2.1 配置原则

15

https://dubbo.apache.org/zh/docsv2.7/user/configuration/configuration-load-process/

JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。

XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。

Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。

dubbo.properties 配置文件是Dubbo默认会加载的一个配置文件，名称是固定的。一般这个配置文件配置的是通用信息

2.2 重试次数

失败自动切换，当出现失败，重试其它服务器，但重试会带来更长延迟。可通过 retries=“2” 来设置重试次数(不含第一次)。

retries=””:重试次数，不包含第一次调用，0代表不重试。

关于幂等性操作（设置重试次数）【查询、删除、修改】、非幂等（不能设置重试次数）【新增】

无论前端发送多少次请求，得到结果是相同

1
2
3
4
5
6
7
8
9

重试次数配置如下：
<dubbo:service retries="2" />
或
<dubbo:reference retries="2" />
或
<dubbo:reference>
    <dubbo:method name="findAll" retries="2" />
</dubbo:reference>

2.3 超时时间

由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。默认调用的时间是 1s。

2.3.1 Dubbo服务消费方

1
2
3
4
5
6
7
8

全局超时配置
<dubbo:consumer timeout="5000" />

指定接口以及特定方法超时配置
<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

2.3.2 Dubbo服务提供方

1
2
3
4
5
6
7
8

全局超时配置
<dubbo:provider timeout="5000" />

指定接口以及特定方法超时配置
<dubbo:provider interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:provider>

2.3.3 配置原则【重要】

dubbo推荐在Provider上尽量多配置Consumer端属性：

1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等

2、在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的

==配置的覆盖规则：==

  • 方法级配置别优于接口级别，即小Scope优先

  • Consumer端配置 优于 Provider配置 优于 全局配置，

  • 最后是Dubbo Hard Code的配置值

16

http://dubbo.apache.org/zh-cn/docs/user/configuration/xml.html

2.4 灰度发布-版本号

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。可以按照以下的步骤进行版本迁移：

在低压力时间段，先升级一半提供者为新版本

再将所有消费者升级为新版本

然后将剩下的一半提供者升级为新版本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<!-- 老版本服务提供者配置：-->
<dubbo:service interface="com.foo.BarService" version="1.0.0" />

<!-- 新版本服务提供者配置：-->
<dubbo:service interface="com.foo.BarService" version="2.0.0" />

<!-- 老版本服务消费者配置：-->
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />

<!-- 新版本服务消费者配置：-->
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />

<!-- 如果不需要区分版本，可以按照以下的方式配置：-->
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

2.5 上下文信息

通过上下文存放当前调用过程中所需的环境信息

上下文中存放的是当前调用过程中所需的环境信息。所有配置信息都将转换为 URL 的参数，参见 schema 配置参考手册 中的对应URL参数一列。

RpcContext 是一个 ThreadLocal 的临时状态记录器，当接收到 RPC 请求，或发起 RPC 请求时，RpcContext 的状态都会变化。比如：A 调 B，B 再调 C，则 B 机器上，在 B 调 C 之前，RpcContext 记录的是 A 调 B 的信息，在 B 调 C 之后，RpcContext 记录的是 B 调 C 的信息。

2.5.1 服务消费方

1
2
3
4
5
6
7
8
9
10
11

// 远程调用
xxxService.xxx();
// 本端是否为消费端，这里会返回true
boolean isConsumerSide = RpcContext.getContext().isConsumerSide();
// 获取最后一次调用的提供方IP地址
String serverIP = RpcContext.getContext().getRemoteHost();
// 获取当前服务配置信息，所有配置信息都将转换为URL的参数
String application = RpcContext.getContext().getUrl().getParameter("application");
// 注意：每发起RPC调用，上下文状态会变化
yyyService.yyy();

2.5.2 服务提供方

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class XxxServiceImpl implements XxxService {
 
    public void xxx() {
        // 本端是否为提供端，这里会返回true
        boolean isProviderSide = RpcContext.getContext().isProviderSide();
        // 获取调用方IP地址
        String clientIP = RpcContext.getContext().getRemoteHost();
        // 获取当前服务配置信息，所有配置信息都将转换为URL的参数
        String application = RpcContext.getContext().getUrl().getParameter("application");
        // 注意：每发起RPC调用，上下文状态会变化
        yyyService.yyy();
        // 此时本端变成消费端，这里会返回false
        boolean isProviderSide = RpcContext.getContext().isProviderSide();
    } 
}

小结：Dubbo上下文对象用于存储调用链路中的数据环境信息

2.6 隐式参数

通过 Dubbo 中的 Attachment 在服务消费方和提供方之间隐式传递参数

可以通过 RpcContext 上的 setAttachment 和 getAttachment 在服务消费方和提供方之间进行参数的隐式传递。

注意：

path, group, version, dubbo, token, timeout 几个 key 是保留字段，请使用其它值。

17

在服务消费方端设置隐式参数：

setAttachment 设置的 KV 对，在完成下面一次远程调用会被清空，即多次远程调用要多次设置。

1
2
3
4

RpcContext.getContext().setAttachment("index", "1"); // 隐式传参，后面的远程调用都会隐式将这些参数发送到服务器端，类似cookie，用于框架集成，不建议常规业务使用
xxxService.xxx(); // 远程调用
// ...

在服务提供方端获取隐式参数：

1
2
3
4
5
6
7
8

public class XxxServiceImpl implements XxxService {
 
    public void xxx() {
        // 获取客户端隐式传入的参数，用于框架集成，不建议常规业务使用
        String index = RpcContext.getContext().getAttachment("index"); 
    }
}

高可用

3.1 nacos宕机与dubbo直连

现象：nacos注册中心宕机，还可以消费dubbo暴露的服务。

是生产环境还是开发环境？

原因：

健壮性

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

高可用：通过设计，减少系统不能提供服务的时间；

dubbo 直连方式调用，绕过nacos注册中心实现：

@Reference(url=“127.0.0.1:20880”) 直接连接服务的提供方的地址

1
<dubbo:reference  url="192.168.25.1:20880">

面试题：

  1. 注册中心是否可以替换？ 如果可以替换那么可以用什么来替换？ 为什么？
  2. redis作为注册中心的原因是什么？ 数据结构是什么？ 怎么实现？

实现步骤：

  • 引入依赖
1
2
3
4
<dependency>
	<groupId>redis.clients</groupId>
	<artifactId>jedis</artifactId>
</dependency>
  • 修改配置（将原先配置nacos链接信息，修改为redis）
1
2
3
yaml
  registry:
    address: redis://192.168.25.142:6379

==注意：服务端和消费端都需要修改此配置==

18

3.2 集群下dubbo负载均衡配置

在集群负载均衡时，Dubbo 提供了多种均衡策略，==缺省为 random 加权随机调用。==

负载均衡策略【重点】

3.2.1 Random LoadBalance

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

19

3.2.2 RoundRobin LoadBalance

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

20

3.2.3 LeastActive LoadBalance

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

21

3.2.4 ConsistentHash LoadBalance

一致性 Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

22

算法参见：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 整合hystrix，服务熔断与降级处理

3.3.1 服务降级

什么是服务降级？

当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。

可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。

向注册中心写入动态配置覆盖规则：

1
2
3
4
5

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("nacos://10.20.153.10:2181"));

registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));

其中：

  • mock=force:return null 表示==消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。==用来屏蔽不重要服务不可用时对调用方的影响。
  • 还可以改为 mock=fail:return null ==表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。==用来容忍不重要服务不稳定时对调用方的影响。

3.3.2 集群容错

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

集群容错

23

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

重试次数配置如下：
<dubbo:service retries=“2” />
或
<dubbo:reference retries=“2” />
或
< dubbo:reference>
​ <dubbo:method name=“findFoo” retries=“2” />
< /dubbo:reference>

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

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

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

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

Broadcast Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。

集群模式配置
按照以下示例在服务提供方和消费方配置集群模式
<dubbo:service cluster=“failsafe” />
或
<dubbo:reference cluster=“failsafe” />

3.3.3 整合hystrix

Hystrix 旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能

1、配置spring-cloud-starter-netflix-hystrix

spring boot官方提供了对hystrix的集成，直接在pom.xml里加入依赖：

1
2
3
4
5

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

然后在Application类上增加@EnableHystrix来启用hystrix starter

2、配置Provider端

在Dubbo的Provider上增加@HystrixCommand配置，这样子调用就会经过Hystrix代理。

1
2
3
4
5
6
7
8
9
10
11
12
13

@Service(version = "1.0.0")
public class HelloServiceImpl implements HelloService {
     @HystrixCommand(commandProperties = {
     @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
     @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") })
    @Override
    public String sayHello(String name) {
        // System.out.println("async provider received: " + name);
        // return "annotation: hello, " + name;
        throw new RuntimeException("Exception to show hystrix enabled.");
    }
}

3、配置Consumer端

对于Consumer端，则可以增加一层method调用，并在method上配置@HystrixCommand。当调用出错时，会走到fallbackMethod = “reliable”的调用里。

1
2
3
4
5
6
7
8
9
10
11

@Reference(version = "1.0.0")
private HelloService demoService;

@HystrixCommand(fallbackMethod = "reliable")
public String doSayHello(String name) {
    return demoService.sayHello(name);
}
public String reliable(String name) {
    return "hystrix fallback value";
}

Dubbo示例代码

dubbo原理

参考官网：https://dubbo.apache.org/zh/docsv2.7/dev/implementation/

4.1 RPC原理

24

一次完整的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）服务消费方得到最终结果。==

RPC框架的目标就是要2~8这些步骤都封装起来，这些细节对用户来说是透明的，不可见的。

dubbo 是基于RPC框架来实现的远程调用，意思是Dubbo的底层一定会有当前RPC调用的每一步的细节。

4.2 netty通信原理

Netty是一个异步事件驱动的网络应用程序框架， 用于快速开发可维护的高性能协议服务器和客户端。它极大地简化并简化了TCP和UDP套接字服务器等网络编程。

BIO：(Blocking IO) 阻塞式IO

25

NIO (Non-Blocking IO)非阻塞式IO

26

Selector 一般称 为选择器 ，也可以翻译为 多路复用器，

Connect（连接就绪）、Accept（接受就绪）、Read（读就绪）、Write（写就绪）

Netty基本原理：

27

4.3 dubbo原理

Dubbo SPI

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。

需要特别说明的是，本篇文章以及本系列其他文章所分析的源码版本均为 dubbo-2.6.4。因此大家在阅读文章的过程中，需注意将代码版本切换到 dubbo-2.6.4 tag 上。

Dubbo IOC

Dubbo IOC 是通过 setter 方法注入依赖。Dubbo 首先会通过反射获取到实例的所有方法，然后再遍历方法列表，检测方法名是否具有 setter 方法特征。若有，则通过 ObjectFactory 获取依赖对象，最后通过反射调用 setter 方法将依赖设置到目标对象中。整个过程对应的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

private T injectExtension(T instance) {
    try {
        if (objectFactory != null) {
            // 遍历目标类的所有方法
            for (Method method : instance.getClass().getMethods()) {
                // 检测方法是否以 set 开头，且方法仅有一个参数，且方法访问级别为 public
                if (method.getName().startsWith("set")
                    && method.getParameterTypes().length == 1
                    && Modifier.isPublic(method.getModifiers())) {
                    // 获取 setter 方法参数类型
                    Class<?> pt = method.getParameterTypes()[0];
                    try {
                        // 获取属性名，比如 setName 方法对应属性名 name
                        String property = method.getName().length() > 3 ? 
                            method.getName().substring(3, 4).toLowerCase() + 
                            	method.getName().substring(4) : "";
                        // 从 ObjectFactory 中获取依赖对象
                        Object object = objectFactory.getExtension(pt, property);
                        if (object != null) {
                            // 通过反射调用 setter 方法设置依赖
                            method.invoke(instance, object);
                        }
                    } catch (Exception e) {
                        logger.error("fail to inject via method...");
                    }
                }
            }
        }
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
    }
    return instance;
}

在上面代码中，objectFactory 变量的类型为 AdaptiveExtensionFactory，AdaptiveExtensionFactory 内部维护了一个 ExtensionFactory 列表，用于存储其他类型的 ExtensionFactory。Dubbo 目前提供了两种 ExtensionFactory，分别是 SpiExtensionFactory 和 SpringExtensionFactory。前者用于创建自适应的拓展，后者是用于从 Spring 的 IOC 容器中获取所需的拓展。这两个类的类的代码不是很复杂，这里就不一一分析了。

Dubbo IOC 目前仅支持 setter 方式注入，总的来说，逻辑比较简单易懂。

4.3.1 dubbo原理 -框架设计

参考官网：https://dubbo.apache.org/zh/docsv2.7/dev/design/

28

图例说明：

  • 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。
  • 图中从下至上分为十层，各层均为单向依赖，右边的黑色箭头代表层之间的依赖关系，每一层都可以剥离上层被复用，其中，Service 和 Config 层为 API，其它各层均为 SPI。
  • 图中绿色小块的为扩展接口，蓝色小块为实现类，图中只显示用于关联各层的实现类。
  • 图中蓝色虚线为初始化过程，即启动时组装链，红色实线为方法调用过程，即运行时调时链，紫色三角箭头为继承，可以把子类看作父类的同一个节点，线上的文字为调用的方法。

各层说明：

  • config 配置层：对外配置接口，以 ServiceConfig, ReferenceConfig 为中心，可以直接初始化配置类，也可以通过 spring 解析配置生成配置类
  • proxy 服务代理层：服务接口透明代理，生成服务的客户端 Stub 和服务器端 Skeleton, 以 ServiceProxy 为中心，扩展接口为 ProxyFactory
  • registry 注册中心层：封装服务地址的注册与发现，以服务 URL 为中心，扩展接口为 RegistryFactory, Registry, RegistryService
  • cluster 路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以 Invoker 为中心，扩展接口为 Cluster, Directory, Router, LoadBalance
  • monitor 监控层：RPC 调用次数和调用时间监控，以 Statistics 为中心，扩展接口为 MonitorFactory, Monitor, MonitorService
  • protocol 远程调用层：封装 RPC 调用，以 Invocation, Result 为中心，扩展接口为 Protocol, Invoker, Exporter
  • exchange 信息交换层：封装请求响应模式，同步转异步，以 Request, Response 为中心，扩展接口为 Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
  • transport 网络传输层：抽象 mina 和 netty 为统一接口，以 Message 为中心，扩展接口为 Channel, Transporter, Client, Server, Codec
  • serialize 数据序列化层：可复用的一些工具，扩展接口为 Serialization, ObjectInput, ObjectOutput, ThreadPool

4.3.2 dubbo原理 -启动解析、加载配置信息

配置文件的标签解析对象，用来解析XML文件中配置的Dubbo的属性

29

那么如何知道当前的解析Bean的class的呢？

我们观察 当前的构造对象， 调用的前一步中包含了一个对象 叫做 DubboNamespaceHandler 中的 init() 方法

30

基于 dubbo.jar 内的 META-INF/spring.handlers 配置，Spring 在遇到 dubbo 名称空间时，会回调 DubboNamespaceHandler。

所有 dubbo 的标签，都统一用 DubboBeanDefinitionParser 进行解析，基于一对一属性映射，将 XML 标签解析为 Bean 对象。

在 ServiceConfig.export() 或 ReferenceConfig.get() 初始化时，将 Bean 对象转换 URL 格式，所有 Bean 属性转成 URL 的参数。

然后将 URL 传给 协议扩展点，基于扩展点的 扩展点自适应机制，根据 URL 的协议头，进行不同协议的服务暴露或引用。

4.3.3 dubbo原理 -服务暴露

31

32

33

Invoker 是 Dubbo 领域模型中非常重要的一个概念，当前Invoker其实包含的就是 当前实现类以及暴露这个服务的ip端口信息的组合，相当于对原有实现类的封装。

  1. 只暴露服务端口DubboProtocol：

在没有注册中心，直接暴露提供者的情况下，ServiceConfig 解析出的 URL 的格式为：dubbo://service-host/com.foo.FooService?version=1.0.0。

基于扩展点自适应机制，通过 URL 的 dubbo:// 协议头识别，直接调用 DubboProtocol的 export() 方法，打开服务端口。启动 netty服务器监听Dubbo协议的端口

34

  1. 向注册中心暴露服务RegistryProtocol：

在有注册中心，需要注册提供者地址的情况下，ServiceConfig 解析出的 URL 的格式为: registry://registry-host/org.apache.dubbo.registry.RegistryService?export=URL.encode("dubbo://service-host/com.foo.FooService?version=1.0.0")，

基于扩展点自适应机制，通过 URL 的 registry:// 协议头识别，就会调用 RegistryProtocol 的 export()方法，将 export 参数中的提供者 URL，先注册到注册中心。

再重新传给 Protocol 扩展点进行暴露： dubbo://service-host/com.foo.FooService?version=1.0.0，然后基于扩展点自适应机制，通过提供者 URL 的 dubbo:// 协议头识别，就会调用 DubboProtocol 的 export()方法，打开服务端口。

35

4.3.4 dubbo原理 -服务引用

36

1. 直连引用服务：

在没有注册中心，直连提供者的情况下 ，==ReferenceConfig==解析出的 URL 的格式为：[dubbo://service-host/com.foo.FooService?version=1.0.0。

基于扩展点自适应机制，通过 URL 的 dubbo:// 协议头识别，直接调用 DubboProtocol 的 refer() 方法，返回提供者引用。 从注册中心远程获取当前服务的地址

37

2. 从注册中心发现引用服务：

在有注册中心，通过注册中心发现提供者地址的情况下，==ReferenceConfig== 解析出的 URL 的格式为：registry://registry-host/org.apache.dubbo.registry.RegistryService?refer=URL.encode("consumer://consumer-host/com.foo.FooService?version=1.0.0")。

38

基于扩展点自适应机制，通过 URL 的 registry:// 协议头识别，就会调用 RegistryProtocol 的 refer()方法，基于 refer 参数中的条件，查询提供者 URL，如： dubbo://service-host/com.foo.FooService?version=1.0.0。

39

40

基于扩展点自适应机制，通过提供者 URL 的 dubbo:// 协议头识别，就会调用 DubboProtocol 的 refer()方法，得到提供者引用。

然后 RegistryProtocol 将多个提供者引用，通过 Cluster 扩展点，伪装成单个提供者引用返回。

41

4.3.5 dubbo原理 -服务调用

http://dubbo.apache.org/zh-cn/docs/dev/design.html

http://dubbo.apache.org/zh-cn/docs/source_code_guide/loadbalance.html

42

43

44

45

上图是服务消费的主过程：

首先 ReferenceConfig 类的 init 方法调用 Protocol 的 refer 方法生成 Invoker 实例(如上图中的红色部分)，这是服务消费的关键。接下来把 Invoker 转换为客户端需要的接口(如：HelloWorld)。

关于每种协议如 RMI/Dubbo/Web service 等它们在调用 refer 方法生成 Invoker 实例的细节和上一章节所描述的类似。

由于 Invoker 是 Dubbo 领域模型中非常重要的一个概念，很多设计思路都是向它靠拢。这就使得 Invoker渗透在整个实现代码里，对于刚开始接触 Dubbo 的人，确实容易给搞混了。 下面我们用一个精简的图来说明最重要的两种 Invoker：服务提供 Invoker 和服务消费 Invoker：

46

为了更好的解释上面这张图，我们结合服务消费和提供者的代码示例来进行说明：

服务消费者代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

public class DemoClientAction {
 
    private DemoService demoService;
 
    public void setDemoService(DemoService demoService) {
        this.demoService = demoService;
    }
 
    public void start() {
        String hello = demoService.sayHello("world" + i);
    }
}

上面代码中的 DemoService 就是上图中服务消费端的 proxy，用户代码通过这个 proxy 调用其对应的 Invoker，而该 Invoker 实现了真正的远程服务调用。

服务提供者代码：

1
2
3
4
5
6
7

public class DemoServiceImpl implements DemoService {
 
    public String sayHello(String name) throws RemoteException {
        return "Hello " + name;
    }
}

上面这个类会被封装成为一个 AbstractProxyInvoker 实例，并新生成一个 Exporter 实例。这样当网络通讯层收到一个请求后，会找到对应的 Exporter 实例，并调用它所对应的 AbstractProxyInvoker 实例，从而真正调用了服务提供者的代码。Dubbo 里还有一些其他的 Invoker 类，但上面两种是最重要的。

其它：

性能报告

推荐用法

分布式事务问题

Dubbo协议