Dubbo 从入门到精通

文章目录

Dubbo

什么是Dubbo

架构的演变 使用

Spring中使用SpringCloud整合Dubbo 配置优先级

xml配置属性配置 启动时检查负载均衡集群容错线程模型直连提供者多注册中心服务分组服务泛化引用

Dubbo 什么是Dubbo

dubbo：是一个基于soa思想的rpc框架

soa思想：面向服务的架构

给每一个模块暴露对应的ip和端口，当做一个服务进行运行重点在于服务的管理（负载均衡，容灾模式，服务的横向扩展） 架构的演变

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

单一应用架构

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

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

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

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

使用 Spring中使用

引入依赖

    org.springframework
    spring-core
    4.3.2.RELEASE


    org.springframework
    spring-beans
    4.3.2.RELEASE


    org.springframework
    spring-context
    4.3.2.RELEASE


    com.alibaba
    dubbo
    2.5.3


    org.apache.zookeeper
    zookeeper
    3.4.6

编写服务提供者

// 服务提供者接口
public interface UserService {
   
   String findName(String name);
   void addUser(String username);
}

public class UserServiceImpl implements UserService {
	@Override
	public String findName(String name) {
		System.out.println("姓名：" + name);
		return "hello" + name;
	}

	@Override
	public void addUser(String username) {
		System.out.println("添加用户，用户名为：" + username);
	}
}

spring.xml

开启服务

public class TestDubbo {
   public static void main(String[] args) throws IOException {
      ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring-dubbo.xml");
      context.start();
      System.out.println("服务提供者，开始提供服务。。。。");

      System.in.read();
   }
}

编写服务消费者

需要将服务提供接口拷贝到当前服务下

public interface UserService {
   
   String findName(String name);
   void addUser(String username);
}

测试

public class TestDubbo {
    public static void main(String[] args) throws IOException {

        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring-dubbo.xml");
        UserService userService = (UserService) context.getBean("userService");

        userService.addUser("小陈");

        String name = userService.findName("xiaoming");
        System.out.println(name);
    }
}

SpringCloud整合Dubbo

在服务提供方和消费放引入依赖

    com.alibaba.cloud
    spring-cloud-starter-dubbo

服务提供方

// 服务提供者接口
public interface ProductService {
  
   String findName(String name);
}

public class ProductServiceImpl implements ProductService {
	@Override
	public String findName(String name) {
		System.out.println("姓名：" + name);
		return "hello" + name;
	}
}

application.yaml

dubbo:
  application:
    name: product     # 服务名
  protocol:
    name: dubbo       # 暴露的协议名称
    port: 20880       # 暴露的协议端口
  registry:
    address: spring-cloud://192.168.44.129:8848 # Dubbo 服务注册中心配置，其中子属性address 的值 "spring-cloud://192.168.44.129"，说明挂载到 Spring Cloud 的注册中心

主启动类

服务消费方

同样需要将服务方的接口copy到消费放的项目目录下

public interface ProductService {
   
   String findName(String name);
}

dubbo:
  application:
    name: users
  protocol:
    name: dubbo
    port: 20880
  registry:
    address: spring-cloud://192.168.44.129:8848
  cloud:
    subscribed-services: * # 表示要订阅服务的服务名，可以配置'*'，代表订阅所有服务，不推荐使用。若需订阅多应用，使用 "," 分割。

调用服务

public class UsersServiceImpl implements UserService {

   @Reference
   private ProductService productService;

   
   @GetMapping("/users")
   public String getUsers() {
      String result = productService.findName("xiaochen");
      return "users ok!!!  result:" + result;
   }
}

测试

配置优先级 xml配置

不同粒度配置的覆盖关系

以 timeout 为例，其它 retries, loadbalance, actives 等类似：

方法级优先，接口级次之，全局配置再次之。如果级别一样，则消费方优先，提供方次之。

（建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置）。

属性配置

从Dubbo支持的配置来源说起，默认有6种配置来源：

JVM System Properties，JVM -D 参数System environment，JVM进程的环境变量Externalized Configuration，外部化配置，从配置中心读取Application Configuration，应用的属性配置，从Spring应用的Environment中提取"dubbo"打头的属性集API / XML /注解等编程接口采集的配置可以被理解成配置来源的一种，是直接面向用户编程的配置采集方式从classpath读取配置文件 dubbo.properties

下图展示了配置覆盖关系的优先级，从上到下优先级依次降低：

API配置：https://dubbo.apache.org/zh/docs/references/configuration/api/

注解配置：https://dubbo.apache.org/zh/docs/references/configuration/annotation/

启动时检查

https://dubbo.apache.org/zh/docs/advanced/preflight-check/

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 check="true"。

可以通过 check="false" 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 check="false"，总是会返回引用，当服务恢复时，能自动连上。

通过 spring 配置文件

关闭某个服务的启动时检查 (没有提供者时报错)：

关闭所有服务的启动时检查 (没有提供者时报错)：

关闭注册中心启动时检查 (注册订阅失败时报错)：

通过 dubbo.properties

dubbo.reference.com.foo.BarService.check=false
dubbo.consumer.check=false
dubbo.registry.check=false

通过 -D 参数

java -Ddubbo.reference.com.foo.BarService.check=false
java -Ddubbo.consumer.check=false 
java -Ddubbo.registry.check=false

负载均衡

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

具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。

目前 Dubbo 内置了如下负载均衡算法，可直接配置使用：

算法	特性	备注
Random LoadBalance	加权随机	默认算法，默认权重相同
RoundRobin LoadBalance	加权轮询	借鉴于 Nginx 的平滑加权轮询算法，默认权重相同，
LeastActive LoadBalance	最少活跃优先 + 加权随机	背后是能者多劳的思想
ShortestResponse LoadBalance	最短响应优先 + 加权随机	更加关注响应速度
ConsistentHash LoadBalance	一致性 Hash	确定的入参，确定的提供者，适用于有状态请求

配置

服务端服务级别

客户端服务级别

服务端方法级别

客户端方法级别

集群容错

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

Failover Cluster

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

Failfast Cluster

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

Failsafe Cluster

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

Failback Cluster

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

Forking Cluster

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

Broadcast Cluster

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

配置服务提供方和消费方集群模式

或

线程模型

如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。

但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。

如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。

因此，需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:

Dispatcher

all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。direct 所有消息都不派发到线程池，全部在 IO 线程上直接执行。message 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。execution 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。connection 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。

ThreadPool

fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)cached 缓存线程池，空闲一分钟自动删除，需要时重建。limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。eager 优先创建Worker线程池。在任务数量大于corePoolSize但是小于maximumPoolSize时，优先创建Worker来处理任务。当任务数量大于maximumPoolSize时，将任务放入阻塞队列中。阻塞队列充满时抛出RejectedExecutionException。(相比于cached:cached在任务数量超过maximumPoolSize时直接抛出异常而不是将任务放入阻塞队列) 直连提供者

在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。

如果是线上需求需要点对点，可在 中配置 url 指向提供者，将绕过注册中心，多个地址用分号隔开，配置如下：

多注册中心

Dubbo 支持同一服务向多注册中心同时注册，或者不同服务分别注册到不同的注册中心上去，甚至可以同时引用注册在不同注册中心上的同名服务。另外，注册中心是支持自定义扩展的。

多注册中心注册

不同服务使用不同注册中心

多注册中心引用

如果只是测试环境临时需要连接两个不同注册中心，使用竖号分隔多个不同注册中心地址：

服务分组

使用服务分组区分服务接口的不同实现

当一个接口有多种实现时，可以用 group 区分。

服务

引用

任意组：

服务泛化引用

泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况，参数及返回值中的所有 POJO 均用 Map 表示，通常用于框架集成，比如：实现一个通用的服务测试框架，可通过 GenericService 调用所有服务实现。

通过 Spring 使用泛化调用

在 Spring 配置申明 generic="true"：

在 Java 代码获取 barService 并开始泛化调用：

GenericService barService = (GenericService) applicationContext.getBean("barService");
Object result = barService.$invoke("sayHello", new String[] { "java.lang.String" }, new Object[] { "World" 

更多高级用法请参考：https://dubbo.apache.org/zh/docs/advanced/