Dubbo（八）------知识点整理

亦凉 2023-06-30 02:59 43阅读 0赞

## 一、Dubbo是什么？为什么要用Dubbo？ ##

[Dubbo（二）------Dubbo介绍][Dubbo_------Dubbo]

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。

Dubbo抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色，提供方提供服务，消费方消费服务。

Dubbo还具有注册中心和监控中心角色。注册中心：通过注册中心对服务进行注册和订阅，实现了软负载均衡和Failover（故障切换），降低对F5硬件负载均衡器的依赖，也能减少部分成本。监控中心：对服务进行监控，可以监控服务的调用次数和调用时间，达到合理分配资源的目的。

[Dubbo（六）------为什么要用Dubbo][Dubbo_------_Dubbo]

## 2、dubbo都支持什么协议，推荐用哪种？ ##

dubbo://（推荐）

rmi://

hessian://

http://

webservice://

thrift://

memcached://

redis://

rest://

## 3、Dubbo需要 Web 容器吗？ ##

dubbo不需要web容器，有三种启动方式。

[Dubbo（七）------服务运行的三种方式][Dubbo_------]

## 4、Dubbo内置了哪几种服务容器？ ##

Dubbo已经提供了内置的Container服务容器，所以不需要Tomcat/JBoss等Web容器去加载资源。

com.alibaba.dubbo.container.Main 是服务启动的主类

服务容器只提供一个简单的Main方法，并加载一个简单的Spring容器以暴露该服务。

Dubbo服务容器 Container，提供了实现类有 SpringContainer、Log4jContainer、JettyContainer、LogbackContainer。

并且Container支持自定义扩展

## 5、Dubbo里面有哪几种节点角色？ ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 1]

## 6、Dubbo注册中心？ ##

推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中心，但不推荐。

1、Zookeeper(官方推荐)

优点:支持分布式.很多周边产品.

缺点: 受限于 Zookeeper 软件的稳定性.Zookeeper 专门分布式辅助软件,稳定较优

2、Multicast

优点:去中心化,不需要单独安装软件.

缺点:Provider 和 Consumer 和 Registry 不能跨机房(路由)

3、Redis

优点:支持集群,性能高

缺点:要求服务器时间同步.否则可能出现集群失败问题.

4、Simple

优点: 标准 RPC 服务.没有兼容问题

缺点: 不支持集群

## 7、Dubbo有哪几种配置方式？ ##

**一、XML配置**

**二、属性配置**

如果公共配置很简单，没有多注册中心，多协议等情况，或者想多个 Spring 容器想共享配置，可以使用 dubbo.properties 作为缺省配置。一般情况下 properties 都是用来配置一些公共的信息，比如可能一个应用需要调用多个注册中心的服务，这时候它们的 application.name、dubbo.protocol.name等都是相同的，那么你可以用 properties 来配置这些公共信息。

Dubbo 将自动加载 classpath 根目录下的 dubbo.properties，可以通过JVM启动参数 -Ddubbo.properties.file=xxx.properties 改变缺省配置位置。

**三、API配置**

**四、注解配置**

## 8、Dubbo 核心的配置有哪些？ ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 2]

## 9、在 Provider 上可以配置的 Consumer 端的属性有哪些？ ##

1）timeout：方法调用超时

2）retries：失败重试次数，默认重试 2 次

3）loadbalance：负载均衡算法，默认随机

4）actives 消费者端，最大并发调用限制

## 10、Dubbo启动时如果依赖的服务不可用会怎样？ ##

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check=“true”，可以通过 check=“false” 关闭检查。

## 11、Dubbo推荐使用什么序列化框架，你知道的还有哪些？ ##

*  dubbo 序列化：阿里尚未开发成熟的高效 java 序列化实现，阿里不建议在生产环境使用它。
 *  hessian2 序列化：hessian 是一种跨语言的高效二进制序列化方式。但这里实际不是原生的 hessian2 序列化，而是阿里修改过的 hessian lite，它是 dubbo RPC 默认启用的序列化方式。
 *  json 序列化：目前有两种实现，一种是采用的阿里的 fastjson 库，另一种是采用 dubbo 中自己实现的简单 json 库，但其实现都不是特别成熟，而且 json 这种文本序列化性能一般不如上面两种二进制序列化。
 *  java 序列化：主要是采用 JDK 自带的 Java 序列化实现，性能很不理想。、

通常，这四种主要序列化方式的性能从上到下依次递减。  
对于 dubbo RPC 这种追求高性能的远程调用方式来说，实际上只有 1、2 两种高效序列化方式比较般配，而第 1 个 dubbo 序列化由于还不成熟，所以实际只剩下 2 可用，所以 dubbo RPC 默认采用 hessian2 序列化。

但 hessian 是一个比较老的序列化实现了，而且它是跨语言的，所以不是单独针对 Java 进行优化的。而 dubbo RPC 实际上完全是一种 Java to Java 的远程调用，其实没有必要采用跨语言的序列化方式（当然肯定也不排斥跨语言的序列化）。

最近几年，各种新的高效序列化方式层出不穷，不断刷新序列化性能的上限，最典型的包括：

*  专门针对 Java 语言的：Kryo，FST 等等
 *  跨语言的：Protostuff，ProtoBuf，Thrift，Avro，MsgPack 等等

这些序列化方式的性能多数都显著优于 hessian2（甚至包括尚未成熟的 dubbo 序列化）

有鉴于此，我们为 dubbo 引入 Kryo 和 FST 这两种高效 Java 序列化实现，来逐步取代 hessian2。

其中，Kryo 是一种非常成熟的序列化实现，已经在 Twitter、Groupon、Yahoo 以及多个著名开源项目（如 Hive、Storm）中广泛的使用。而 FST 是一种较新的序列化实现，目前还缺乏足够多的成熟使用案例。

在面向生产环境的应用中，目前更优先选择 Kryo。

## 12、Dubbo默认使用的是什么通信框架，还有别的选择吗？ ##

Dubbo 默认使用 Netty 框架，主流通信框架包括netty，mina，Grizzly

## 13、Dubbo有哪几种集群容错方案，默认是哪种？ ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 3]

## 14、Dubbo有哪几种负载均衡策略，默认是哪种？ ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 4]  
每个服务维护一个活跃数计数器。当A机器开始处理请求，该计数器加1，此时A还未处理完成。若处理完毕则计数器减1。而B机器接受到请求后很快处理完毕。那么A,B的活跃数分别是1，0。当又产生了一个新的请求，则选择B机器去执行(B活跃数最小)，这样使慢的机器A收到少的请求。

## 15、注册了多个同一样的服务，如果测试指定的某一个服务呢？ ##

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。

**对于服务提供者来说**

<dubbo:protocol name="dubbo" port="20880" />
    
    
    
    
    
    
    <dubbo:registry address="N/A" />

**对于服务消费者来说**

<dubbo:registry address="N/A" />
    <dubbo:reference id="testService" interface="com.yi.TestService"  url="dubbo://127.0.0.1:20880" />

## 16、Dubbo支持服务多协议和多注册中心吗？ ##

Dubbo 允许配置多协议和多注册中心，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

**生产者配置**

<dubbo:registry address="multicast://192.1.6.7:1234" id="mt"/> 
    
    <dubbo:registry address="zookeeper://192.168.242.130:2181" id="zk"/
    
    
    
    <dubbo:protocol name="dubbo" port="20880"/>
    
    <dubbo:protocol name="http" port="20991" />
    
    
    
    <dubbo:service interface="com.yi.helloWorld" ref="helloWorldService" protocol="dubbo" registry="zk,mt"/>
    
    <dubbo:service interface="com.helloWorld" ref="helloWorldService5" protocol="t,dubbo" registry="zk"/>

## 17、当一个服务接口有多种实现时怎么做？ ##

当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。

**生产者配置**

<dubbo:service interface="com.yi.helloWorld"  group="group1" />
    <dubbo:service interface="com.yi.helloWorld"  group="group2" />

**消费者配置**

<dubbo:reference id="helloWorld1" interface="com.yi.helloWorld"  group="group1" />
    
    <dubbo:reference id="helloWorld2" interface="com.yi.helloWorld"   group="group2" />
    
    <dubbo:reference id="helloWorld3" interface="com.yi.helloWorld"   group="*" />

## 18、服务上线怎么兼容旧版本？ ##

可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。

**生产者配置**

<dubbo:service  ref="helloWorld1"  interface="com.yi.helloWorld"  version="1.1.0" />
    <dubbo:service  ref="helloWorld2"  interface="com.yi.helloWorld"  version="1.1.1" />

**消费者配置**

<dubbo:reference  id="demoService1"  interface="com.yi.helloWorld"  version="1.1.0"   />
    <dubbo:reference  id="demoService2"  interface="com.yi.helloWorld"  version="1.1.1"   />
    
    <dubbo:reference  id="demoService3"  interface="com.yi.helloWorld"  version="*"   />

## 19、Dubbo可以对结果进行缓存吗？ ##

可以，Dubbo 提供了声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。

**dubbo提供了三种结果缓存机制：**

> lru：基于最近最少使用原则删除多余缓存，保持最热的数据被缓存  
> threadlocal：当前线程缓存  
> jcache：可以桥接各种缓存实现

**生产者配置**

生产者配置基本不用做改变

<dubbo:service  ref="helloWorld1"  interface="com.yi.helloWorld"    />

**消费者配置**

添加cache配置

<dubbo:reference id="demoService1" interface="com.yi.helloWorld" cache="lru"/>

## 20、Dubbo服务之间的调用是阻塞的吗？ ##

> 默认是同步的，等待结果是阻塞的，支持异步调用。

Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对象。

异步调用流程图如下。  
![在这里插入图片描述][20200114224832646.png]

> 1） 用户线程调用方法  
> 2） IO线程将请求发送到服务端  
> 3） IO线程setFuture  
> 4) 用户线程执行getFuture获取结果，若为空，通过wait方法等待 .  
> CompletableFuture，提供了非常强大的Future的扩展功能，可以帮助我们简化异步编程的复杂性，提供了函数式编程的能力，可以通过回调的方式处理计算结果，并且提供了转换和组合CompletableFuture的方法。  
> 5） 服务端响应结果，并写入Future

## 21、Dubbo支持分布式事务吗？ ##

**1、什么是分布式事务**

举一例子：比如两个系统【订单系统、库存系统】并且每个系统分布再不同的服务上，或者理解为每个系统具有一个数据库，当用户进行支付的时候，可以分为两个步骤【1、修改订单状态；2、库存数据同步更新】，但是如果在步骤2失败了，因为数据库事务处理，会进行回滚，但是因为是两个数据库，所以订单系统数据库不会进行回滚。造成数据一致性问题。

> 指一次大的操作由不同的小操作组成的，这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。  
> 从本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

**2、分布式事务产生的原因？**

**第一种、 数据库分库分表**

当数据库单表数据达到千万级别，就要考虑分库分表，那么就会从原来的一个数据库变成多个数据库。例如如果一个操作即操作了01库，又操作了02库，而且又要保证数据的一致性，那么就要用到分布式事务。

**第二种、多系统下**

多个系统具有多个数据库，比如前面的订单系统和库存系统。

**总结：本质上就是操作多数据库，并且要保证数据的一致性，而产生的分布式事务的。**

**3、dubbo分布式事务解决方案？**

目前暂时不支持.

**1、可与通过 tcc-transaction 框架实现**

介绍：tcc-transaction 是开源的 TCC 补偿性分布式事务框架

TCC-Transaction 通过 Dubbo 隐式传参的功能，避免自己对业务代码的入侵。

> Try操作作为一阶段，负责资源的检查和预留。  
> Confirm操作作为二阶段提交操作，执行真正的业务。  
> Cancel是预留资源的取消。

**Try 阶段**

从执行阶段来看，与传统事务机制中业务逻辑相同。但从业务角度来看，却不一样。TCC机制中的Try仅是一个初步操作，它和后续的确认一起才能真正构成一个完整的业务逻辑，这个阶段主要完成：

完成所有业务检查( 一致性 )

预留必须业务资源( 准隔离性 )

Try 尝试执行业务 TCC事务机制以初步操作（Try）为中心的，确认操作（Confirm）和取消操作（Cancel）都是围绕初步操作（Try）而展开。因此，Try阶段中的操作，其保障性是最好的，即使失败，仍然有取消操作（Cancel）可以将其执行结果撤销。

**Confirm / Cancel 阶段**

根据Try阶段服务是否全部正常执行，继续执行确认操作（Confirm）或取消操作（Cancel）。 Confirm和Cancel操作满足幂等性，如果Confirm或Cancel操作执行失败，将会不断重试直到执行完成。

Confirm：当Try阶段服务全部正常执行， 执行确认业务逻辑操作

这里使用的资源一定是Try阶段预留的业务资源。在TCC事务机制中认为，如果在Try阶段能正常的预留资源，那Confirm一定能完整正确的提交。Confirm阶段也可以看成是对Try阶段的一个补充，Try+Confirm一起组成了一个完整的业务逻辑。

Cancel：当Try阶段存在服务执行失败， 进入Cancel阶段

Cancel取消执行，释放Try阶段预留的业务资源，上面的例子中，Cancel操作会把冻结的库存释放，并更新订单状态为取消。

**2、结合MQ消息中间件实现的可靠消息最终一致性**

可靠消息最终一致性，需要业务系统结合MQ消息中间件实现，在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态

## 22、Dubbo 和 Spring Cloud 有什么区别？ ##

两个没关联，如果硬要说区别，有以下几点。

1）通信方式不同

Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。

2）组成部分不同  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 5]

## 23、Dubbo telnet 命令能做什么？ ##

Dubbo2.0.5以上版本服务提供端口支持telnet命令

*  连接服务

#telnet ip port
    telnet 172.16.9.1 20880

进入telnet窗口，键入回车进入dubbo命令模式。  
![在这里插入图片描述][20200115234515333.png]

*  ls

> ls (list services and methods)  
> ls : 显示服务列表。  
> ls -l : 显示服务详细信息列表。  
> ls XxxService：显示服务的方法列表。  
> ls -l XxxService：显示服务的方法详细信息列表。

*  ps

> ps 显示服务端口列表。  
> ps -l 显示服务地址列表。  
> ps 20880 显示端口上的连接信息。  
> ps -l 20880 显示端口上的连接详细信息。

*  invoke

调用接口时，以JSON格式传入参数，然后打印返回值和所用时间

> invoke XxxService.xxxMethod(\{“prop”: “value”\}) 调用服务的方法。  
> invoke xxxMethod(\{“prop”: “value”\}) 调用服务的方法(自动查找包含此方法的服务)。

*  status

> status 显示汇总状态，该状态将汇总所有资源的状态，当全部OK时则显示OK，只要有一个ERROR则显示ERROR，只要有一个WARN则显示WARN。  
> status -l 显示状态列表。

*  count

> count XxxService 统计1次服务任意方法的调用情况。  
> count XxxService 10 统计10次服务任意方法的调用情况  
> count XxxService xxxMethod 统计1次服务方法的调用情况。  
> count XxxService xxxMethod 10 统计10次服务方法的调用情况。

*  trace

> trace XxxService 跟踪1次服务任意方法的调用情况。  
> trace XxxService 10 跟踪10次服务任意方法的调用情况。  
> trace XxxService xxxMethod 跟踪1次服务方法的调用情况  
> trace XxxService xxxMethod 10 跟踪10次服务方法的调用情况。

*  clear

> clear 清除屏幕上的内容。  
> clear 10 清除屏幕上的指定行数的内容。

*  exit

> exit 退出当前telnet命令行

## 24、Dubbo支持服务降级吗？ ##

**什么是服务降级**

服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

即：在服务宕掉或者并发数太高导致的RpcException异常时，进行友好的处理或者提示，而不是内部报错导致系统不可用。

**服务降级方式**

**1、mock 返回固定的字符串**

<dubbo:reference id="xxxService" interface="com.x..service.xxxxService" check="false" mock="return 123456" />

配置了mock参数之后，假设在调用服务的时候，远程服务没有启动，或者各种网络异常了，那远程服务会把这个mock配置的值返回，也就是会返回123456

通过这种方式就可以避免了因为服务调用不了而出现异常错误而带来的程序不可用(起码是有值返回的，然后可以根据值进行业务逻辑处理判断等等)。

注：除了配置mock参数之外，其它地方不用变。

**2、自定义mock业务处理类**

<dubbo:reference id="xxxService" interface="com.x..service.xxxxService" check="false" mock="true" />

说明：配置了mock参数之后，假设在调用服务的时候，远程服务没有启动，或者各种网络异常了，那远程服务会去寻找自定义的mock业务处理类进行业务处理。

因此还需配置一个自定义mock业务处理类

在接口服务xxxxService的目录下创建相应的mock业务处理类，同时实现业务接口xxxxService()，接口名要注意命名规范：接口名+Mock后缀，mock实现需要保证有无参的构造方法。

public class xxxxServiceMock implements xxxxService {
        @Override
        public String getXXXX(int id) {
            return "this is exception 自定义....";
        }
    }

配置完成后，此时如果调用失败会调用自定义的Mock业务实现。  
注：除了以上两处之外，其它地方不用变。

**3、dubb-adming管理界面手动配置**

![在这里插入图片描述][20200223152750324.png]

屏蔽：force.mock （即：屏蔽请求，直接返回某个值，如上面的字符串，mock=“return 123456…”）;

容错：fail.mock （即：允许请求，在请求失败的时候，再返回某个值，如：mock=“fail:return 123456…”）;

参考：https://blog.csdn.net/vtopqx/article/details/79494599

## 25、Dubbo如何优雅停机？ ##

Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。

**原理**

**对于服务提供方**

停止时，先标记为不接受新的请求，新请求过来时直接报错，让客户端重试其他机器；  
然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭；

**对于服务消费方**

停止时，不在发起新的调用请求，所有新的调用在客户端即报错；  
然后，检测有没有请求的相应还没有返回，等待相应返回，，除非超时，则强制关闭；

**设置优雅停机超时时间**

设置优雅停机超时时间，缺省超时时间是10秒；(超时则强制关闭)

<dubbo:application ...>
        <dubbo:parameter key="shutdown.timeout" value="60000" />
    </dubbo:application>

如果ShutdownHock不能生效，可以自行调用：

ProtocolConfig.destoryAll();

## 26、服务提供者能实现失效踢出是什么原理？ ##

服务失效踢出基于 Zookeeper 的临时节点原理。

zookeeper中节点是有生命周期的.具体的生命周期取决于节点的类型.节点主要分为持久节点(Persistent)和临时节点(Ephemeral)

**持久节点**

所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点,也就是说不会因为创建该节点的客户端会话失效而消失

**临时节点**

临时节点的生命周期和客户端会话绑定,也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉

## 27、如何解决服务调用链过长的问题？ ##

可以结合zipkin实现分布式服务追踪。

https://blog.csdn.net/liaokailin/article/details/52077620

## 28、服务读写推荐的容错策略是怎样的？ ##

读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。  
写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

## 29、Dubbo必须依赖的包有哪些？ ##

Dubbo 必须依赖 JDK，其他为可选。

## 30、Dubbo的管理控制台能做什么？ ##

管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。

## 31、说说 Dubbo 服务暴露的过程。 ##

Dubbo 会在 Spring 实例化完 bean 之后，在刷新容器最后一步发布 ContextRefreshEvent 事件的时候，通知实现了 ApplicationListener 的 ServiceBean 类进行回调 onApplicationEvent 事件方法，Dubbo 会在这个方法中调用 ServiceBean 父类 ServiceConfig 的 export 方法，而该方法真正实现了服务的（异步或者非异步）发布。

## 32、Dubbo 停止维护了吗？ ##

2014 年开始停止维护过几年，17 年开始重新维护，并进入了 Apache 项目。

## 33、Dubbo 和 Dubbox 有什么区别？ ##

Dubbox 是继 Dubbo 停止维护后，当当网基于 Dubbo 做的一个扩展项目，如加了服务可 Restful 调用，更新了开源组件等。

## 34、你还了解别的分布式框架吗？ ##

别的还有 Spring cloud、Facebook 的 Thrift、Twitter 的 Finagle 等。

## 35、Dubbo 能集成 Spring Boot 吗？ ##

## 36、在使用过程中都遇到了些什么问题？ ##

Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议。

## 37、你读过 Dubbo 的源码吗？ ##

要了解 Dubbo 就必须看其源码，了解其原理，花点时间看下吧，网上也有很多教程，后续有时间我也会在公众号上分享 Dubbo 的源码。

## 38、你觉得用 Dubbo 好还是 Spring Cloud 好？ ##

扩展性的问题，没有好坏，只有适合不适合，不过我好像更倾向于使用 Dubbo, Spring Cloud 版本升级太快，组件更新替换太频繁，配置太繁琐，还有很多我觉得是没有 Dubbo 顺手的地方……

[Dubbo_------Dubbo]: https://blog.csdn.net/qq_29914837/article/details/103690751
[Dubbo_------_Dubbo]: https://blog.csdn.net/qq_29914837/article/details/104046492
[Dubbo_------]: https://blog.csdn.net/qq_29914837/article/details/104056575
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020011422461493.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200223150739694.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200114224651538.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200114224751619.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200114224806387.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70
[20200114224832646.png]: https://img-blog.csdnimg.cn/20200114224832646.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/2020011422455348.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3,size_16,color_FFFFFF,t_70
[20200115234515333.png]: https://img-blog.csdnimg.cn/20200115234515333.png
[20200223152750324.png]: https://img-blog.csdnimg.cn/20200223152750324.png