Dubbo 在服务消费者和服务提供者之间如何建立通信

分手后的思念是犯贱 2023-10-10 17:13 58阅读 0赞

### Dubbo 在服务消费者和服务提供者之间如何建立通信 ###

当服务消费者（Consumer）调用服务提供者（Provider）的服务时，Dubbo 底层主要通过以下几个步骤来找到并调用相应的类和方法：

1.  服务引用（Reference）：在消费者端，我们使用 `@DubboReference` 注解引用远程服务。Dubbo 通过解析该注解，创建一个代理对象，用于将对服务接口的调用转发到远程服务提供者。这个代理对象是通过 `org.apache.dubbo.rpc.proxy.ProxyFactory` 接口的实现类（默认为 `org.apache.dubbo.rpc.proxy.javassist.JavassistProxyFactory`）创建的。
2.  服务调用（Invocation）：当消费者调用服务接口的方法时，代理对象会将方法名、参数类型和参数值封装成一个 `org.apache.dubbo.rpc.Invocation` 对象。这个对象包含了调用的所有信息，包括服务接口、方法名、参数类型和参数值等。
3.  服务导出（Export）：在服务提供者端，我们使用 `@DubboService` 注解暴露服务。Dubbo 会扫描这个注解，并通过 `org.apache.dubbo.config.ServiceConfig` 类将服务导出。在这个过程中，会创建一个 `org.apache.dubbo.rpc.Invoker` 对象，它负责将 `Invocation` 对象转发到具体的服务实现类。
4.  序列化和反序列化：服务调用信息（即 `Invocation` 对象）需要通过网络传输，因此需要进行序列化。Dubbo 支持多种序列化协议，默认使用 Hessian2 序列化。序列化和反序列化过程由 `org.apache.dubbo.remoting.Codec` 接口的实现类（如 `org.apache.dubbo.remoting.transport.codec.TransportCodec`）完成。
5.  服务调用过程：当服务提供者接收到来自消费者的请求后，Dubbo 会先反序列化请求数据，然后通过 `org.apache.dubbo.rpc.Invoker` 找到具体的服务实现类和方法。这个过程是通过 `org.apache.dubbo.rpc.filter.ClassLoaderFilter` 和 `org.apache.dubbo.rpc.filter.EchoFilter` 完成的。最后，Dubbo 使用 Java 反射机制调用相应的方法，并将结果序列化后返回给消费者。
6.  异常处理：如果在服务调用过程中发生异常，Dubbo 会将异常信息封装成一个 `org.apache.dubbo.rpc.Result` 对象，并通过序列化返回给消费者。消费者在接收到异常信息后，会将其转换为对应的 Java 异常对象，并抛出。

通过以上步骤，Dubbo 能够在服务消费者和服务提供者之间建立通信，实现远程方法调用。当然，这里只是对整个过程的简要概述。  
如果您想更深入地了解源码，可以从 `org.apache.dubbo.config.ReferenceConfig`  
和 `org.apache.dubbo.config.ServiceConfig` 类开始阅读，它们分别负责消费者和提供者的配置。

以下是一些建议您阅读的核心类和组件，以便更好地了解 Dubbo 的工作原理：

1.  `org.apache.dubbo.config.ReferenceConfig`：这个类负责解析消费者端的配置，包括服务引用、代理工厂、集群策略等。同时，它也创建了一个 `org.apache.dubbo.rpc.cluster.ClusterInvoker` 实例，用于实现负载均衡和容错。
2.  `org.apache.dubbo.rpc.cluster.Cluster`：它是一个接口，用于将多个服务提供者实例组织成一个“集群”，并提供负载均衡和容错功能。Dubbo 提供了多种实现，如 `org.apache.dubbo.rpc.cluster.support.FailoverCluster`（失败自动切换）和 `org.apache.dubbo.rpc.cluster.support.FailfastCluster`（快速失败）。
3.  `org.apache.dubbo.rpc.cluster.Directory`：这个接口负责列出集群中所有可用的服务提供者实例。它的实现类，如 `org.apache.dubbo.registry.integration.RegistryDirectory`，通常与注册中心交互，以获取实时的服务提供者列表。
4.  `org.apache.dubbo.remoting.Transporter`：这个接口负责底层的网络通信，包括连接建立、数据发送和接收等。Dubbo 提供了基于 Netty、Mina 和 Grizzly 的实现。
5.  `org.apache.dubbo.rpc.Filter`：过滤器是 Dubbo 中的一个重要概念，用于实现 AOP（面向切面编程）功能。过滤器可以在服务调用的前后添加自定义逻辑，如日志记录、性能监控、权限控制等。Dubbo 提供了一些内置过滤器，如 `org.apache.dubbo.rpc.filter.ConsumerContextFilter`、`org.apache.dubbo.rpc.filter.ProviderContextFilter` 等，同时也支持自定义过滤器。
6.  `org.apache.dubbo.rpc.Protocol`：这个接口定义了 Dubbo 支持的协议。Dubbo 支持多种协议，如 Dubbo 协议、RMI 协议、HTTP 协议等。您可以根据需要选择合适的协议。

这些类和组件是 Dubbo 框架的核心部分，通过阅读它们的源码，您可以更深入地了解 Dubbo 的工作原理。当然，Dubbo 的功能远不止这些，还包括服务降级、服务分组、动态配置等。您可以参考官方文档以及源码，逐步了解更多的功能和细节。

> Dubbo 的服务调用是同步阻塞的, 如何实现的呢?

默认情况下，Dubbo 的服务调用是同步阻塞的。当服务消费者（Consumer）调用服务提供者（Provider）的服务时，消费者会等待提供者的响应。在收到响应之前，消费者会阻塞，无法进行其他操作。

以下是同步阻塞调用的实现原理：

1.  当消费者调用服务接口时，代理对象（通过 `org.apache.dubbo.rpc.proxy.ProxyFactory` 创建）会将方法调用信息封装成一个 `org.apache.dubbo.rpc.Invocation` 对象，并传递给 `org.apache.dubbo.rpc.Invoker` 对象。
2.  `org.apache.dubbo.rpc.Invoker` 会将 `Invocation` 对象传递给 `org.apache.dubbo.remoting.exchange.ExchangeClient` 实例。`ExchangeClient` 负责将请求发送到服务提供者，并等待响应。
3.  `org.apache.dubbo.remoting.exchange.support.DefaultFuture` 类在 `ExchangeClient` 中起到关键作用。它使用 Java 的 `java.util.concurrent.CompletableFuture` 实现了一个异步操作，但是通过 `DefaultFuture` 的 `get()` 方法可以将异步操作转换为同步阻塞操作。`get()` 方法会阻塞当前线程，直到接收到服务提供者的响应或超时。
4.  当服务提供者处理完请求并将响应发送回消费者时，`ExchangeClient` 会通过 `DefaultFuture` 的 `received()` 方法通知对应的线程。接着，阻塞的 `get()` 方法会返回结果，消费者可以继续执行后续操作。

整个同步阻塞调用过程主要涉及以下几个类：

*  `org.apache.dubbo.rpc.proxy.ProxyFactory`
 *  `org.apache.dubbo.rpc.Invoker`
 *  `org.apache.dubbo.remoting.exchange.ExchangeClient`
 *  `org.apache.dubbo.remoting.exchange.support.DefaultFuture`

通过阅读这些类的源码，您可以更清晰地了解 Dubbo 是如何实现同步阻塞调用的。同时，Dubbo 也支持异步调用和回调。您可以在官方文档中找到相关的使用说明和示例。

#### 找到具体的服务实现类 ####

> 服务调用过程：当服务提供者接收到来自消费者的请求后，Dubbo 会先反序列化请求数据，然后通过 org.apache.dubbo.rpc.Invoker 找到具体的服务实现类和方法。这个过程是通过 org.apache.dubbo.rpc.filter.ClassLoaderFilter 和 org.apache.dubbo.rpc.filter.EchoFilter 完成的。最后，Dubbo 使用 Java 反射机制调用相应的方法，并将结果序列化后返回给消费者。  
> 具体说一下这步, 在spring中也是通过先找到对应的bean, 然后通过反射调用对应的方法吗?

Dubbo 在服务提供者端接收到来自消费者的请求后，会通过 `org.apache.dubbo.rpc.Invoker` 找到具体的服务实现类。这个过程与 Spring 中的 Bean 查找类似。在 Dubbo 中，每个服务都有一个对应的 `org.apache.dubbo.rpc.Invoker` 实例，它包含了服务的实现类（即 Spring 管理的 Bean）及服务接口信息。

当 `org.apache.dubbo.rpc.Invoker` 接收到请求时，它会通过 `org.apache.dubbo.rpc.filter.ClassLoaderFilter` 和 `org.apache.dubbo.rpc.filter.EchoFilter` 查找服务实现类的具体方法。这两个过滤器主要完成以下工作：

1.  `org.apache.dubbo.rpc.filter.ClassLoaderFilter`：这个过滤器负责设置当前线程的 `ClassLoader`，以便后续的反射调用能够找到正确的类。由于 Dubbo 支持多个应用间的调用，不同的应用可能使用不同的类加载器，所以需要设置正确的类加载器来确保服务调用正常。
2.  `org.apache.dubbo.rpc.filter.EchoFilter`：这个过滤器处理 Dubbo 的“回声”测试请求。回声测试是 Dubbo 提供的一种测试机制，用于检查服务提供者是否可用。当收到回声测试请求时，`EchoFilter` 会直接返回结果，而不会进入后续的调用链。

在完成上述过滤器处理后，`org.apache.dubbo.rpc.Invoker` 会使用 Java 反射机制调用相应的方法。具体来说，它会根据请求中的方法名和参数类型，找到服务实现类的对应方法，并通过反射调用该方法。

这个过程与 Spring 中的 Bean 查找和方法调用类似。在 Spring 中，当接收到 HTTP 请求时，它会根据请求的 URL 和 HTTP 方法找到对应的 Controller Bean 及处理方法，然后使用反射调用该方法。同样，Dubbo 也是根据服务调用请求的信息查找服务实现类及方法，并通过反射进行调用。

#### feign是通过 http进行调用, 而dubbo是通过 netty 进行tcp交互后进行反射调用, 为什么dubbo比feign快呢? ####

Dubbo 通常比 Feign 更快，主要原因在于它们使用的底层通信机制和协议不同。以下是一些导致 Dubbo 比 Feign 更快的关键因素：

1.  通信协议：Feign 是基于 HTTP 协议进行调用的，而 Dubbo 默认使用的是基于 TCP 的二进制 Dubbo 协议。HTTP 是一种文本协议，相比二进制协议，它的解析和序列化/反序列化过程相对较慢。另外，HTTP 协议本身包含许多额外的信息（如请求头、响应头等），这会增加传输的开销。
2.  序列化方式：Dubbo 默认使用 Hessian2 进行序列化，它是一种二进制序列化协议，具有较高的性能。而 Feign 默认使用 JSON 进行序列化，相比 Hessian2，JSON 序列化和反序列化的性能较低。当然，Feign 也可以使用其他序列化方式，如 Protocol Buffers 等，但这需要额外的配置。
3.  传输层：Dubbo 默认使用 Netty 作为底层通信框架，Netty 是一种高性能、异步的网络通信框架，它使用了高效的 I/O 模型和缓冲池技术，以减少资源消耗和网络延迟。而 Feign 底层通常使用的是 JDK 自带的 HttpURLConnection 或者 OkHttp，相比 Netty，它们的性能较低。
4.  连接管理：Dubbo 使用长连接进行通信，这意味着服务消费者和提供者之间建立的连接可以在多次请求之间复用，从而减少了连接建立和释放的开销。而 HTTP 协议在每次请求后需要关闭连接（HTTP/1.1 引入了 Keep-Alive 机制，但仍有一定的开销），这会增加额外的性能损耗。
5.  负载均衡和容错：Dubbo 提供了多种负载均衡策略（如随机、轮询等）和容错机制（如失败自动切换、快速失败等），这有助于提高服务调用的性能和稳定性。而 Feign 虽然也可以通过与其他组件（如 Ribbon、Hystrix 等）集成来实现类似功能，但这需要额外的配置和开发工作。

总之，Dubbo 相较于 Feign 具有更高效的通信协议、序列化方式、传输层框架、连接管理以及负载均衡和容错机制，这些因素都使得 Dubbo 在性能上具有优势。但需要注意的是，这并不意味着 Dubbo 总是比 Feign 更好。实际上，根据不同的应用场景和需求，您可能会选择使用 Feign 或其他 RPC 框架。例如，如果您的应用需要与其他基于 HTTP/REST 的服务进行交互，那么使用 Feign 可能更加适合。