Dubbo 作为轻量 RPC 框架解决组件通信问题 on Apache Dubbo

泛化实现

Mon, 01 Jan 0001 00:00:00 +0000

注意

请注意区分上一篇文档介绍的泛化调用，泛化调用是给消费端用的，而泛化实现是给提供端用的。

泛接口实现方式主要用于服务器端没有 API 接口及模型类元的情况，参数及返回值中的所有 POJO 均用 Map 表示，通常用于框架集成，比如：实现一个通用的远程服务 Mock 框架，可通过实现 GenericService 接口处理所有服务请求。

使用场景

注册服务: 服务提供者在服务注册表中注册服务，例如 Zookeeper，服务注册表存储有关服务的信息，例如其接口、实现类和地址。
部署服务: 服务提供商将服务部署在服务器并使其对消费者可用。
调用服务: 使用者使用服务注册表生成的代理调用服务，代理将请求转发给服务提供商，服务提供商执行服务并将响应发送回消费者。
监视服务：提供者和使用者可以使用 Dubbo 框架监视服务，允许他们查看服务的执行情况，并在必要时进行调整。

使用方式

本示例的完整源码请参考 dubbo-samples-generic-impl。

在 Java 代码中实现 GenericService 接口

package com.foo;
public class MyGenericService implements GenericService {

 public Object $invoke(String methodName, String[] parameterTypes, Object[] args) throws GenericException {
 if ("sayHello".equals(methodName)) {
 return "Welcome " + args[0];
 }
 }
}

通过 Spring 暴露泛化实现

在 Spring XML 配置申明服务的实现

<bean id="genericService" class="com.foo.MyGenericService" />
<dubbo:service interface="com.foo.BarService" ref="genericService" />

通过 API 方式暴露泛化实现

...
// 用org.apache.dubbo.rpc.service.GenericService可以替代所有接口实现
GenericService xxxService = new XxxGenericService();

// 该实例很重量，里面封装了所有与注册中心及服务提供方连接，请缓存
ServiceConfig<GenericService> service = new ServiceConfig<GenericService>();
// 弱类型接口名
service.setInterface("com.xxx.XxxService");
// if you need to set different version for service
service.setVersion("1.0.0");
// 指向一个通用服务实现
service.setRef(xxxService);

// 暴露及注册服务
service.export();

在设置 ServiceConfig 时，使用setGeneric("true")来开启泛化调用
在设置 ServiceConfig 时，使用 setRef 指定实现类时，要设置一个 GenericService 的对象。而不是真正的服务实现类对象
其他设置与正常 Api 服务启动一致即可

回声测试

Mon, 01 Jan 0001 00:00:00 +0000

特性说明

回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，能够测试整个调用是否通畅，可用于监控。执行回声测试，客户端发送一个包含特定值（如字符串）的请求。服务器应使用相同的值进行响应，从而验证请求是否已成功接收和处理。如果响应与请求不匹配，则表示服务运行不正常，应进一步调查。要求 Dubbo 服务器正在运行，并且服务器和客户端之间具有网络连接。在客户端，必须配置 Dubbo 客户端以连接到服务器，客户端将向服务器发送请求，然后服务器应返回与请求相同的响应。

使用场景

测试验证是否可以调用服务以及响应是否正确，对于在尝试在生产环境中使用服务之前验证服务特别有用。 echo 测试是验证 Dubbo 服务基本功能的一种简单有效的方法，在将服务部署到生产环境之前执行此测试非常重要，以确保服务按预期工作。

使用方式

本示例完整源码请参考 dubbo-samples-echo。

所有服务自动实现 EchoService 接口，只需将任意服务引用强制转型为 EchoService，即可使用。

如有以下 Dubbo proxy 实例：

@DubboReference
private DemoService demoService;

代码示例

EchoService echoService = (EchoService) demoService;

String status = (String) echoService.$echo("OK");

动态指定 IP 调用

Mon, 01 Jan 0001 00:00:00 +0000

特性说明

在发起 RPC 请求的时候，需要指定本次调用的服务端，常用的场景包括消息回调、流量隔离等。

使用方式

插件依赖

首先，需要添加以下插件依赖到项目中

<dependency>
 <groupId>org.apache.dubbo.extensions</groupId>
 <artifactId>dubbo-cluster-specify-address-dubbo3</artifactId>
 <version>3.3.0</version>
</dependency>

适配 Dubbo 2 版本

<dependency>
 <groupId>org.apache.dubbo.extensions</groupId>
 <artifactId>dubbo-cluster-specify-address-dubbo2</artifactId>
 <version>1.0.0</version>
</dependency>

调用示例

ReferenceConfig<DemoService> referenceConfig = new ReferenceConfig<>();
// ... init
DemoService demoService = referenceConfig.get();

// for invoke
// 1. find 10.10.10.10:20880 exist
// 2. if not exist, create a invoker to 10.10.10.10:20880 if `needToCreate` is true (only support in Dubbo 3.x's implementation)
UserSpecifiedAddressUtil.setAddress(new Address("10.10.10.10", 20880, true));
demoService.sayHello("world");


// for invoke
// 1. find 10.10.10.10:any exist
// 2. if not exist, create a invoker to 10.10.10.10:20880 if `needToCreate` is true (only support in Dubbo 3.x's implementation)
UserSpecifiedAddressUtil.setAddress(new Address("10.10.10.10", 0, true));
demoService.sayHello("world");

参数说明

指定 IP 调用的参数围绕 Address 对象展开。参数类型参考如下：

直连提供者

Mon, 01 Jan 0001 00:00:00 +0000

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

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

注解配置方式

@DubboReference(url="tri://localhost:50051")
private XxxService xxxService

xml配置方式

<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" />

调用触发事件通知

Mon, 01 Jan 0001 00:00:00 +0000

特性说明

在调用之前、调用之后、出现异常时，会触发 oninvoke、onreturn、onthrow 三个事件，可以配置当事件发生时，通知哪个类的哪个方法。

使用场景

调用服务方法前我们可以记录开始时间，调用结束后统计整个调用耗费，发生异常时我们可以告警或打印错误日志或者调用服务前后记录请求日志、响应日志等。

参考用例 dubbo-samples-notify

使用方式

服务提供者与消费者共享服务接口

interface IDemoService {
 public Person get(int id);
}

服务提供者实现

class NormalDemoService implements IDemoService {
 public Person get(int id) {
 return new Person(id, "charles`son", 4);
 }
}

服务提供者配置

<dubbo:application name="rpc-callback-demo" />
<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
<bean id="demoService" class="org.apache.dubbo.callback.implicit.NormalDemoService" />
<dubbo:service interface="org.apache.dubbo.callback.implicit.IDemoService" ref="demoService" version="1.0.0" group="cn"/>

服务消费者 Callback 接口

interface Notify {
 public void onreturn(Person msg, Integer id);
 public void onthrow(Throwable ex, Integer id);
}

服务消费者 Callback 实现

class NotifyImpl implements Notify {
 public Map<Integer, Person> ret = new HashMap<Integer, Person>();
 public Map<Integer, Throwable> errors = new HashMap<Integer, Throwable>();
 
 public void onreturn(Person msg, Integer id) {
 System.out.println("onreturn:" + msg);
 ret.put(id, msg);
 }
 
 public void onthrow(Throwable ex, Integer id) {
 errors.put(id, ex);
 }
}

服务消费者 Callback 配置

两者叠加存在以下几种组合情况：

服务端对客户端进行回调

Mon, 01 Jan 0001 00:00:00 +0000

特性说明

参数回调方式与调用本地 callback 或 listener 相同，只需要在 Spring 的配置文件中声明哪个参数是 callback 类型即可。Dubbo 将基于长连接生成反向代理，这样就可以从服务器端调用客户端逻辑。可以参考 dubbo 项目中的示例代码。

使用场景

回调函数通知客户端执行结果，或发送通知，在方法执行时间比较长时，类似异步调用，审批工作流中回调客户端审批结果。

使用方式

服务接口示例

CallbackService.java

package com.callback;
 
public interface CallbackService {
 void addListener(String key, CallbackListener listener);
}

CallbackListener.java

package com.callback;
 
public interface CallbackListener {
 void changed(String msg);
}

服务提供者接口实现示例

package com.callback.impl;
 
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
 
import com.callback.CallbackListener;
import com.callback.CallbackService;
 
public class CallbackServiceImpl implements CallbackService {
 
 private final Map<String, CallbackListener> listeners = new ConcurrentHashMap<String, CallbackListener>();
 
 public CallbackServiceImpl() {
 Thread t = new Thread(new Runnable() {
 public void run() {
 while(true) {
 try {
 for(Map.Entry<String, CallbackListener> entry : listeners.entrySet()){
 try {
 entry.getValue().changed(getChanged(entry.getKey()));
 } catch (Throwable t) {
 listeners.remove(entry.getKey());
 }
 }
 Thread.sleep(5000); // 定时触发变更通知
 } catch (Throwable t) { // 防御容错
 t.printStackTrace();
 }
 }
 }
 });
 t.setDaemon(true);
 t.start();
 }
 
 public void addListener(String key, CallbackListener listener) {
 listeners.put(key, listener);
 listener.changed(getChanged(key)); // 发送变更通知
 }
 
 private String getChanged(String key) {
 return "Changed: " + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
 }
}

服务提供者配置示例

<bean id="callbackService" class="com.callback.impl.CallbackServiceImpl" />
<dubbo:service interface="com.callback.CallbackService" ref="callbackService" connections="1" callbacks="1000">
 <dubbo:method name="addListener">
 <dubbo:argument index="1" callback="true" />
 <!--也可以通过指定类型的方式-->
 <!--<dubbo:argument type="com.demo.CallbackListener" callback="true" />-->
 </dubbo:method>
</dubbo:service>

服务消费者配置示例

<dubbo:reference id="callbackService" interface="com.callback.CallbackService" />

服务消费者调用示例

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:consumer.xml");
context.start();
 
CallbackService callbackService = (CallbackService) context.getBean("callbackService");
 
callbackService.addListener("foo.bar", new CallbackListener(){
 public void changed(String msg) {
 System.out.println("callback1:" + msg);
 }
});

服务降级（本地伪装）

Mon, 01 Jan 0001 00:00:00 +0000

特性说明

在 Dubbo3 中有一种机制可以实现轻量级的服务降级，也就是本地伪装。

Mock 是 Stub 的一个子集，便于服务提供方在客户端执行容错逻辑，因经常需要在出现 RpcException (比如网络失败，超时等)时进行容错，而在出现业务异常(比如登录用户名密码错误)时不需要容错，如果用 Stub，可能就需要捕获并依赖 RpcException 类，而用 Mock 就可以不依赖 RpcException，因为它的约定就是只有出现 RpcException 时才执行。

使用场景

本地伪装常被用于服务降级。比如某验权服务，当服务提供方全部挂掉后，假如此时服务消费方发起了一次远程调用，那么本次调用将会失败并抛出一个 RpcException 异常。为了避免出现这种直接抛出异常的情况出现，那么客户端就可以利用本地伪装来提供 Mock 数据返回授权失败。

其他使用场景包括：

某服务或接口负荷超出最大承载能力范围，需要进行降级应急处理，避免系统崩溃
调用的某非关键服务或接口暂时不可用时，返回模拟数据或空，业务还能继续可用
降级非核心业务的服务或接口，腾出系统资源，尽量保证核心业务的正常运行
某上游基础服务超时或不可用时，执行能快速响应的降级预案，避免服务整体雪崩

使用方式

完整示例源码请参见 dubbo-samples-mock

开启 Mock 配置

在 Spring XML 配置文件中按以下方式配置：

<dubbo:reference interface="com.foo.BarService" mock="true" />

或

<dubbo:reference interface="com.foo.BarService" mock="com.foo.BarServiceMock" />

在工程中提供 Mock 实现 [^2]：在 interface 旁放一个 Mock 实现，它实现 BarService 接口，并有一个无参构造函数。同时，如果没有在配置文件中显式指定 Mock 类的时候，那么需要保证 Mock 类的全限定类名是 原全限定类名+Mock 的形式，例如 com.foo.BarServiceMock，否则将会 Mock 失败。

package com.foo;
public class BarServiceMock implements BarService {
 public String sayHello(String name) {
 // 你可以伪造容错数据，此方法只在出现RpcException时被执行
 return "容错数据";
 }
}

使用 return 关键字 Mock 返回值

使用 return 来返回一个字符串表示的对象，作为 Mock 的返回值。合法的字符串可以是：

本地存根

Mon, 01 Jan 0001 00:00:00 +0000

特性说明：

远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑。

使用场景

做 ThreadLocal 缓存，提前验证参数，调用失败后伪造容错数据等等，此时就需要在 API 中带上 Stub，客户端生成 Proxy 实例，会把 Proxy 通过构造函数传给 Stub ¹，然后把 Stub 暴露给用户，Stub 可以决定要不要去调 Proxy。

使用方式

完整示例源码请参见 dubbo-samples-stub

spring 配置文件配置

<dubbo:consumer interface="com.foo.BarService" stub="true" />

或

<dubbo:consumer interface="com.foo.BarService" stub="com.foo.BarServiceStub" />

提供 Stub 的实现 ²

package com.foo;
public class BarServiceStub implements BarService {
 private final BarSer vice barService;
 
 // 构造函数传入真正的远程代理对象
 public BarServiceStub(BarService barService){
 this.barService = barService;
 }
 
 public String sayHello(String name) {
 // 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等
 try {
 return barService.sayHello(name);
 } catch (Exception e) {
 // 你可以容错，可以做任何AOP拦截事项
 return "容错数据";
 }
 }
}

Stub 必须有可传入 Proxy 的构造函数。 ↩︎

本地调用

Mon, 01 Jan 0001 00:00:00 +0000

特性说明

本地调用使用了 injvm 协议，是一个伪协议，它不开启端口，不发起远程调用，只在 JVM 内直接关联，但执行 Dubbo 的 Filter 链。

使用场景

当我们需要调用远程服务时，远程服务并没有开发完成，使用 injvm 协议在本地实现类似服务，调用此服务时可以调用我们本地的实现服务。

使用方式

定义 injvm 协议

<dubbo:protocol name="injvm" />

设置默认协议

<dubbo:provider protocol="injvm" />

设置服务协议

<dubbo:service protocol="injvm" />

优先使用 injvm

<dubbo:consumer injvm="true" .../>
<dubbo:provider injvm="true" .../>

或

<dubbo:reference injvm="true" .../>
<dubbo:service injvm="true" .../>

注意

Dubbo 从 2.2.0 每个服务默认都会在本地暴露，无需进行任何配置即可进行本地引用，如果不希望服务进行远程暴露，只需要在 provider 将 protocol 设置成 injvm 即可。

自动暴露

从 2.2.0 开始，每个服务默认都会在本地暴露。在引用服务的时候，默认优先引用本地服务。如果希望引用远程服务可以使用一下配置强制引用远程服务。

<dubbo:reference ... scope="remote" />

动态配置调用行为

从3.2开始，Dubbo提供api可以让用户在使用中动态地去配置单一次调用时为本地调用或者远程调用，当没配置的时候将默认优先引用本地服务

配置单一次调用为远程调用

RpcContext.getServiceContext().setLocalInvoke(false);

配置单一次调用为本地调用

RpcContext.getServiceContext().setLocalInvoke(true);

并发控制

Mon, 01 Jan 0001 00:00:00 +0000

功能说明

多种并发控制功能，帮助用户管理其应用程序和服务。

使用场景

限制从同一客户端到同一服务的并发请求数，防止恶意请求使服务器过载，确保服务的稳定性，并防止使用过多资源。

控制某些服务的最大并发请求数，确保其他服务的资源可用性。系统过载和确保系统稳定性。

允许在需求增加时更平滑地扩展服务。

确保服务在高峰使用时间保持可靠和稳定。

这种方式要求用户准确的预先评估系统能处理的并发数，而准确的评估系统处理能力并不是一件容易的事情，因此 Dubbo 还提供了自适应限流模式，根据系统负载自动识别系统健康程度并进行限流保护，可以在此查看使用文档。

使用方式

样例一

限制 com.foo.BarService 的每个方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个

<dubbo:service interface="com.foo.BarService" executes="10" />

样例二

限制 com.foo.BarService 的 sayHello 方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个

<dubbo:service interface="com.foo.BarService">
 <dubbo:method name="sayHello" executes="10" />
</dubbo:service>

样例三

限制 com.foo.BarService 的每个方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个

<dubbo:service interface="com.foo.BarService" actives="10" />

或

<dubbo:reference interface="com.foo.BarService" actives="10" />

样例四

限制 com.foo.BarService 的 sayHello 方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个

<dubbo:service interface="com.foo.BarService">
 <dubbo:method name="sayHello" actives="10" />
</dubbo:service>

或

<dubbo:reference interface="com.foo.BarService">
 <dubbo:method name="sayHello" actives="10" />
</dubbo:service>

如果 <dubbo:service> 和 <dubbo:reference> 都配了actives，<dubbo:reference> 优先，参见：配置的覆盖策略。

连接控制

Mon, 01 Jan 0001 00:00:00 +0000

功能说明

连接控制功能可以使用户能够控制和管理进出服务器连接数，限制连接数并设置超时，以确保 Dubbo 系统的稳定性和性能，还允许用户根据 IP 地址、端口和协议配置不同级别的访问控制，保护系统免受恶意流量的影响，并降低服务中断的风险，此外提供了一种监视当前流量和连接状态的方法。

使用场景

服务器过载时减少连接数：当服务器过载时，使用 Dubbo 通过设置最大连接限制来减少连接数减少服务器上的负载并防止其崩溃。
减少服务器受到攻击时的连接数：Dubbo 可以限制服务器受到攻击的连接数防止恶意连接充斥服务器并导致服务器崩溃。
限制特定服务的连接数：Dubbo 可以限制特定服务连接数防止服务过载过多的请求并确保及时响应所有请求。
限制来自单个IP地址的连接数：Dubbo 可以限制来自单个地址的连接数降低来自单个IP地址的恶意活动的风险。

使用方式

服务端连接控制

限制服务器端接受的连接不能超过 10 个 ¹：

<dubbo:provider protocol="dubbo" accepts="10" />

或

<dubbo:protocol name="dubbo" accepts="10" />

客户端连接控制

限制客户端服务使用连接不能超过 10 个 ²：

<dubbo:reference interface="com.foo.BarService" connections="10" />

或

<dubbo:service interface="com.foo.BarService" connections="10" />

如果 <dubbo:service> 和 <dubbo:reference> 都配了 connections，<dubbo:reference> 优先，参见：配置的覆盖策略

功能说明

允许消费者在提供者接收请求之前向提供者发送请求，消费者等待提供者准备就绪，然后将发送消费者者的请求，当消费者需要连接到提供者，提供者尚未准备好接受请求时，确保在正确的时间发送请求，防止消费者被速度慢或不可用的提供程序阻止。

使用场景

粘滞连接用于有状态服务，尽可能让客户端总是向同一提供者发起调用，除非该提供者挂了，再连另一台。

粘滞连接将自动开启延迟连接，以减少长连接数。

使用方式

<dubbo:reference id="xxxService" interface="com.xxx.XxxService" sticky="true" />

Dubbo 支持方法级别的粘滞连接，如果你想进行更细粒度的控制，还可以这样配置。

<dubbo:reference id="xxxService" interface="com.xxx.XxxService">
 <dubbo:method name="sayHello" sticky="true" />
</dubbo:reference>

功能说明

当消费者请求服务时，实际使用服务时才建立真正的连接，避免不必要的连接来减少延迟并提高系统稳定性。

使用场景

延迟连接用于减少长连接数。当有调用发起时，再创建长连接。

使用方式

<dubbo:protocol name="dubbo" lazy="true" />

该配置只对使用长连接的 dubbo 协议生效。

主机配置

Mon, 01 Jan 0001 00:00:00 +0000

背景

在 Dubbo 中， Provider 启动时主要做两个事情，一是启动 server，二是向注册中心注册服务。启动 server 时需要绑定 socket，向注册中心注册服务时也需要发送 socket 唯一标识服务地址。

dubbo中不设置host时默认host是什么?
那在dubbo中如何指定服务的host,我们是否可以用hostname或domain代替IP地址作为host?
在使用docker时,有时需要设置端口映射,此时,启动server时绑定的socket和向注册中心注册的socket使用不同的端口号,此时又该如何设置?

示例

dubbo 中不设置 host 时默认 host 是什么

一般的 dubbo 协议配置如下:

 ...
 <dubbo:protocol name="dubbo" port="20890" />
 ...

可以看到,只配置了端口号,没有配置 host，此时设置的 host 又是什么呢?

查看代码发现,在 org.apache.dubbo.config.ServiceConfig#findConfigedHosts() 中,通过 InetAddress.getLocalHost().getHostAddress() 获取默认 host。其返回值如下：

未联网时，返回 127.0.0.1
在阿里云服务器中，返回私有地址,如: 172.18.46.234
在本机测试时，返回公有地址，如: 30.5.10.11

那在 dubbo 中如何指定服务的 socket?

除此之外,可以通过 dubbo.protocol 或 dubbo.provider 的 host 属性对 host 进行配置,支持IP地址和域名,如下:

 ...
 <dubbo:protocol name="dubbo" port="20890" host="www.example.com"/>
 ...

在使用 docker 时，有时需要设置端口映射，此时，启动 server 时绑定的 socket 和向注册中心注册的 socket 使用不同的端口号，此时又该如何设置？

见 dubbo 通过环境变量设置 host

调用结果缓存

Mon, 01 Jan 0001 00:00:00 +0000

功能说明

Dubbo支持了服务端结果缓存和客户端结果缓存。

缓存类型

目前Dubbo3.0版本及高于其的版本都支持以下几种内置的缓存策略：

lru 基于最近最少使用原则删除多余缓存，保持最热的数据被缓存。
lfu基于淘汰使用频次最低的原则来实现缓存策略。
expiring基于过期时间原则来实现缓存策略。
threadlocal 当前线程缓存，比如一个页面渲染，用到很多 portal，每个 portal 都要去查用户信息，通过线程缓存，可以减少这种多余访问。
jcache 与 JSR107 集成，可以桥接各种缓存实现。

缓存类型可扩展缓存扩展

关于示例代码

使用场景

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

使用方式

客户端缓存

Dubbo中对RPC调用结果缓存支持接口粒度和方法粒度的配置控制。

接口粒度

xml配置方式：

<dubbo:reference interface="com.foo.DemoService" cache="lru" />

注解配置方式：

@DubboReference(cache = "lru")
private DemoService demoService;

方法粒度

<dubbo:reference interface="com.foo.DemoService">
 <dubbo:method name="sayHello" cache="lru" />
</dubbo:reference>

注解配置方式：

@DubboReference(methods = {@Method(name="sayHello",cache = "lru")})
private DemoService demoService;

服务端缓存

接口粒度

xml配置方式：

<bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl"/>
<dubbo:service interface="com.foo.DemoService" ref="demoService" cache="lru" />

注解配置方式：

@DubboService(cache = "lru")
public class DemoServiceImpl implements DemoService {

 private static final Logger logger = LoggerFactory.getLogger(DemoServiceImpl.class);
 @Override
 public String sayHello(String name) {
 logger.info("Hello " + name + ", request from consumer: " + RpcContext.getContext().getRemoteAddress());
 return "Hello " + name;

 }

}

方法粒度

服务引用配置对象缓存

Mon, 01 Jan 0001 00:00:00 +0000

功能说明

ReferenceConfig 实例很重，封装了与注册中心的连接以及与提供者的连接，需要缓存。否则重复生成 ReferenceConfig 可能造成性能问题并且会有内存和连接泄漏。在 API 方式编程时，容易忽略此问题。

因此，自 2.4.0 版本开始， dubbo 提供了简单的工具类 ReferenceConfigCache用于缓存 ReferenceConfig 实例。

使用场景

网关等存在动态创建订阅的场景，由于 ReferenceConfig 本身很重，会创建特别多的中间对象，而 proxy 本身是可以复用的，所以通过 ReferenceConfigCache 可以缓存这部分的属性。

使用方式

消除并销毁

消除 Cache 中的 ReferenceConfig，将销毁 ReferenceConfig 并释放对应的资源。

ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>(); 
reference.setInterface(XxxService.class); 
reference.setVersion("1.0.0"); 
...... 
ReferenceConfigCache cache = ReferenceConfigCache.getCache(); 
// cache.get方法中会缓存 Reference对象，并且调用ReferenceConfig.get方法启动ReferenceConfig 
XxxService xxxService = cache.get(reference); 
// 注意！ Cache会持有ReferenceConfig，不要在外部再调用ReferenceConfig的destroy方法，导致Cache内的ReferenceConfig失效！ 
// 使用xxxService对象 
xxxService.sayHello();

ReferenceConfigCache cache = ReferenceConfigCache.getCache(); 
cache.destroy(reference);

缺省 ReferenceConfigCache 把相同服务 Group、接口、版本的 ReferenceConfig 认为是相同，缓存一份。即以服务 Group、接口、版本为缓存的 Key。

修改策略

可以修改这个策略，在 ReferenceConfigCache.getCache 时，传一个 KeyGenerator。详见 ReferenceConfigCache 类的方法。

路由状态采集

Mon, 01 Jan 0001 00:00:00 +0000

功能说明

路由状态收集功能可用于识别可能影响服务性能的任何潜在问题，识别可能阻碍服务尽可能高效使用的任何潜在瓶颈或问题，确保服务平稳运行，用户在尝试访问服务时不会遇到任何问题，允许用户检查路由的状态是启用还是禁用，确保仅使用授权的服务，并且访问仅限于具有适当授权的人员。

使用场景

Dubbo 的很多流量治理能力是基于 Router 进行实现的，在生产环境中，如果出现流量结果不符合预期的情况，可以通过路由状态命令来查看路由的状态，以此来定位可能存在的问题。

使用方式

查看路由缓存状态

Dubbo 在收到地址变更的时候，会将地址信息推送给所有的 Router，这些 Router 可以在此阶段提前计算路由的分组，缓存起来，以避免在调用时需要遍历所有的提供者计算分组参数。在 Dubbo 3 中引入的 StateRouter 提供了通过 qos 命令工具实时获取每个路由的状态的能力。

运维人员可以通过 getRouterSnapshot 命令获取路由的状态。具体命令使用方式可以参考 getRouterSnapshot 命令文档。

注：此功能仅支持 StateRoute，且 StateRouter 需要基于 AbstractStateRouter 实现 doBuildSnapshot 接口。

查看实际请求的路由计算结果

Dubbo 3 中默认在路由筛选后为空的时候打印路由计算的节点状态。运维人员可以通过日志判断每个路由的计算结果是否符合预期。

日志格式

No provider available after route for the service 服务 from registry 注册中心地址 on the consumer 消费端IP using the dubbo version 3.0.7. Router snapshot is below: 
[ Parent (Input: 当前节点输入地址数) (Current Node Output: 当前节点计算结果数) (Chain Node Output: 当前节点和后级节点交集结果数) ] Input: 输入的地址示例（显示最多 5 个） -> Chain Node Output: 当前节点输出的地址示例（显示最多 5 个）
 [ 路由名称 (Input: 当前节点输入地址数) (Current Node Output: 当前节点计算结果数) (Chain Node Output: 当前节点和后级节点交集结果数) Router message: 路由日志 ] Current Node Output: 当前节点输出的地址示例（显示最多 5 个）
 [ 路由名称 (Input: 当前节点输入地址数) (Current Node Output: 当前节点计算结果数) (Chain Node Output: 当前节点和后级节点交集结果数) Router message: 路由日志 ] Current Node Output: 当前输入的地址示例（显示最多 5 个）

注意：

路由日志需要依赖路由实现判断 needToPrintMessage 参数，并在需要时写入 messageHolder 路由日志
由于多级路由结果是结果取交集的，所以当前节点计算结果数可能和后级取交后为空

日志示例

[19/07/22 07:42:46:046 CST] main WARN cluster.RouterChain: [DUBBO] No provider available after route for the service org.apache.dubbo.samples.governance.api.DemoService from registry 30.227.64.173 on the consumer 30.227.64.173 using the dubbo version 3.0.7. Router snapshot is below: 
[ Parent (Input: 2) (Current Node Output: 2) (Chain Node Output: 0) ] Input: 30.227.64.173:20881,30.227.64.173:20880 -> Chain Node Output: Empty
 [ MockInvokersSelector (Input: 2) (Current Node Output: 2) (Chain Node Output: 0) Router message: invocation.need.mock not set. Return normal Invokers. ] Current Node Output: 30.227.64.173:20881,30.227.64.173:20880
 [ StandardMeshRuleRouter (Input: 2) (Current Node Output: 2) (Chain Node Output: 0) Router message: MeshRuleCache has not been built. Skip route. ] Current Node Output: 30.227.64.173:20881,30.227.64.173:20880
 [ TagStateRouter (Input: 2) (Current Node Output: 0) (Chain Node Output: 0) Router message: FAILOVER: return all Providers without any tags ] Current Node Output: Empty, dubbo version: 3.0.7, current host: 30.227.64.173

开启路由全采样

在一些特殊情况下，请求可能调用到错误的服务端，但是因为选址非空，所以无法看到路由的过程信息，此时可以通过 qos 开启路由全采样。通过 qos 的 getRecentRouterSnapshot 命令可以远程获取最近的路由快照。

参数校验

Mon, 01 Jan 0001 00:00:00 +0000

特性说明

参数验证功能是基于 JSR303 实现的，用户只需标识 JSR303 标准的验证 annotation，并通过声明 filter 来实现验证。

Maven 依赖

<dependency>
 <groupId>javax.validation</groupId>
 <artifactId>validation-api</artifactId>
 <version>1.0.0.GA</version>
</dependency>
<dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-validator</artifactId>
 <version>4.2.0.Final</version>
</dependency>

使用场景

服务端在向外提供接口服务时，解决各种接口参数校验问题。

参考用例 https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-validation

使用方式

参数标注示例

import java.io.Serializable;
import java.util.Date;
 
import javax.validation.constraints.Future;
import javax.validation.constraints.Max;
import javax.validation.constraints.Min;
import javax.validation.constraints.NotNull;
import javax.validation.constraints.Past;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;
 
public class ValidationParameter implements Serializable {
 private static final long serialVersionUID = 7158911668568000392L;
 
 @NotNull // 不允许为空
 @Size(min = 1, max = 20) // 长度或大小范围
 private String name;
 
 @NotNull(groups = ValidationService.Save.class) // 保存时不允许为空，更新时允许为空 ，表示不更新该字段
 @Pattern(regexp = "^\\s*\\w+(?:\\.{0,1}[\\w-]+)*@[a-zA-Z0-9]+(?:[-.][a-zA-Z0-9]+)*\\.[a-zA-Z]+\\s*$")
 private String email;
 
 @Min(18) // 最小值
 @Max(100) // 最大值
 private int age;
 
 @Past // 必须为一个过去的时间
 private Date loginDate;
 
 @Future // 必须为一个未来的时间
 private Date expiryDate;
 
 public String getName() {
 return name;
 }
 
 public void setName(String name) {
 this.name = name;
 }
 
 public String getEmail() {
 return email;
 }
 
 public void setEmail(String email) {
 this.email = email;
 }
 
 public int getAge() {
 return age;
 }
 
 public void setAge(int age) {
 this.age = age;
 }
 
 public Date getLoginDate() {
 return loginDate;
 }
 
 public void setLoginDate(Date loginDate) {
 this.loginDate = loginDate;
 }
 
 public Date getExpiryDate() {
 return expiryDate;
 }
 
 public void setExpiryDate(Date expiryDate) {
 this.expiryDate = expiryDate;
 }
}

分组验证示例

public interface ValidationService { // 缺省可按服务接口区分验证场景，如：@NotNull(groups = ValidationService.class) 
 @interface Save{} // 与方法同名接口，首字母大写，用于区分验证场景，如：@NotNull(groups = ValidationService.Save.class)，可选
 void save(ValidationParameter parameter);
 void update(ValidationParameter parameter);
}

关联验证示例

import javax.validation.GroupSequence;
 
public interface ValidationService { 
 @GroupSequence(Update.class) // 同时验证Update组规则
 @interface Save{}
 void save(ValidationParameter parameter);
 
 @interface Update{} 
 void update(ValidationParameter parameter);
}

参数验证示例

import javax.validation.constraints.Min;
import javax.validation.constraints.NotNull;
 
public interface ValidationService {
 void save(@NotNull ValidationParameter parameter); // 验证参数不为空
 void delete(@Min(1) int id); // 直接对基本类型参数验证
}

在客户端验证参数

<dubbo:reference id="validationService" interface="org.apache.dubbo.examples.validation.api.ValidationService" validation="true" />

在服务器端验证参数

<dubbo:service interface="org.apache.dubbo.examples.validation.api.ValidationService" ref="validationService" validation="true" />

Dubbo 默认支持 hibernate-validator 版本 <=6.x，若使用 hibernate-validator 7.x 版本，请将 validation 参数声明为 jvalidationNew

响应式编程

Mon, 01 Jan 0001 00:00:00 +0000

过时风险提醒

请注意，本文档描述的 Reactive 响应式使用方法可能存在过时的情况，请随时参考 apache/dubbo-samples 中的最新 reactive 示例了解用法。

特性说明

此特性基于 Triple 协议和 Project Reactor 实现，3.1.0 版本以上支持。用户仅需编写 IDL 文件，并指定 protobuf 插件的相应 Generator，即可生成并使用支持响应式API的 Stub 代码。

有四种调用模式，分别是 OneToOne、OneToMany、ManyToOne、ManyToMany，分别对应 Unary调用、服务端流、客户端流、双向流。在 Reactor 的实现中，One 对应 Mono，Many 对应 Flux。

Reactive Stream 提供了一套标准的异步流处理 API，在能够让应用写出事件驱动的程序的同时，也通过 BackPressure 的方式保证了节点的稳定。Triple 协议在通信协议层面为 Dubbo 框架增加了流式场景的支持，在此基础上能够实现上层包括大文件传输和推送机制的业务需求。

Dubbo + Reactive Stream Stub 的组合模式可以给用户带来最方便的流式使用方式以及全链路异步性能提升。

参考用例 https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-triple-reactor

使用场景

系统需要处理大量并发请求而不会使任何服务器过载。大量用户提供实时数据的系统，希望确保系统能够处理负载而不会崩溃或变慢。

使用方式

Triple 使用及配置可参考 IDL 方式使用 Triple，并确保 Dubbo 版本 >= 3.1.0。

添加必要的依赖

若要使用 Reactor Triple，需要额外添加如下依赖。

<dependency>
 <groupId>org.reactivestreams</groupId>
 <artifactId>reactive-streams</artifactId>
</dependency>
<dependency>
 <groupId>io.projectreactor</groupId>
 <artifactId>reactor-core</artifactId>
</dependency>

设置 protobuf Maven 插件

仅需将 mainClass 修改为 org.apache.dubbo.gen.tri.reactive.ReactorDubbo3TripleGenerator，并确保 ${compiler.version} >= 3.1.0

Dubbo 作为轻量 RPC 框架解决组件通信问题 on Apache Dubbo

泛化实现

注意

使用场景

使用方式

通过 Spring 暴露泛化实现

通过 API 方式暴露泛化实现

回声测试

特性说明

使用场景

使用方式

代码示例

动态指定 IP 调用

特性说明

使用方式

插件依赖

调用示例

参数说明

直连提供者

注解配置方式

xml配置方式

更多配置方式

注意

通过 -D 参数指定

提示

通过文件映射

提示

注意

调用触发事件通知

特性说明

使用场景

使用方式

服务提供者与消费者共享服务接口

服务提供者实现

服务提供者配置

服务消费者 Callback 接口

服务消费者 Callback 实现

服务消费者 Callback 配置

服务端对客户端进行回调

特性说明

使用场景

使用方式

服务接口示例

服务提供者接口实现示例

服务提供者配置示例

服务消费者配置示例

服务消费者调用示例

服务降级（本地伪装）

特性说明

使用场景

使用方式

开启 Mock 配置

使用 return 关键字 Mock 返回值

本地存根

特性说明：

使用场景

使用方式

spring 配置文件配置

提供 Stub 的实现 2

本地调用

特性说明

使用场景

使用方式

定义 injvm 协议

设置默认协议

设置服务协议

优先使用 injvm

注意

自动暴露

动态配置调用行为

并发控制

功能说明

使用场景

使用方式

样例一

样例二

样例三

样例四

连接控制

功能说明

提供 Stub 的实现 ²