dubborpc（dubborpc返回值是null,但是另一个服务里有值）

本篇文章给大家谈谈dubborpc，以及dubborpc返回值是null,但是另一个服务里有值对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、dubbo怎么实现rpc远程调用
• 2、dubbo泛化调用使用及原理解析
• 3、Dubbo的底层实现原理和机制

dubbo怎么实现rpc远程调用

在消费者初始化的时候，会生成一个消费者代理注册到容器中，该代理回调中持有一个MockClusterInvoker实例，消费调用服务接口时它的invoke会被调用，此时会构建一个RpcInvocation对象，把服务接口的method对象和参数放到RpcInvocation对象中，作为MockClusterInvoker.invoke方法的参数，在这个invoke方法中，判断请求是否需要mock，是否配置了mock属性，是强制mock还是失败后mock，关于mock这里先不详细展开，这里只看下核心流程。 

MockClusterInvoker.invoke会调用FailfastClusterInvoker.invoke，大系统中为了服务高可用同一个服务一般会有多个应用服务器提供，要先挑选一个提供者提供服务。在服务接口消费者初始化时，接口方法和提供者Invoker对应关系保存在RegistryDirectory的methodInvokerMap中，通过调用的方法名称（或方法名称+第一个参数）改方法对应的提供者invoker列表，如注册中心设置了路由规则，对这些invoker根据路由规则进行过滤。 

com.alibaba.dubbo.registry.integration.RegistryDirectory.doList(Invocation) 

 

com.alibaba.dubbo.rpc.cluster.directory.AbstractDirectory.list(Invocation) 

 

读取到所有符合条件的服务提供者invoker之后，由LoadBalance组件执行负载均衡，从中挑选一个invoker进行调用，框架内置支持的负载均衡算法包括random（随机）、roundrobin（R-R循环）、leastactive（最不活跃）、consistenthash（一致性hash），应用可配置，默认random。 

methodInvokerMap保存的是持有DubboInvoker（dubbo协议）实例的InvokerDelegete对象，是Invoker-Filter链的头部，先激活Filter连然后最终调到DubboInvoker.invoke(RpcInvocation)，此时远程调用分三种类型： 

1. 单向调用，无需获取关注调用结果的，无需等待接口返回结果，注意调用结果不要单纯跟返回值混淆了，异常也是调用结果。 

2. 异步调用，需要关注返回结果，但是不会同步等待接口调用结束，会异步的获取返回返回结果，这种情况给调用者返回一个Future，但是不同步等待Future.get返回调用结果 

3. 同步调用，需要同步等待服务调用结束获取调用结果，给调用者返回一个Future并且Future.get等待结果，此时接口调用线程会挂起等待响应。 

 

我们大部分使用场景都是同步调用，所以主要看一下同步调用。如果使用者配置了多个connections按顺序选择一个ExchangeClient和服务器通信，同步调用时调用HeaderExchangeClient.request-HeaderExchangeChannel.request。

com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeChannel.request(Object, int) 

 

这里的request参数是RpcInvocation对象，包含调用的方法、参数等信息，timeout参数是接口超时时间，把这些信息封装在Request对象中，调用channel.send，这个channel对象就是和服务端打交道的NettyClient实例，NettyClient.send调用NettyChannel.send。

com.alibaba.dubbo.remoting.transport.netty.NettyChannel.send(Object, boolean) 

 

这里的sent参数决定是否等待请求消息发出，sent=true 等待消息发出，消息发送失败将抛出异常，sent=false 不等待消息发出，将消息放入IO队列，即刻返回。默认情况下都是false。NettyChannel中有channel属性，这个channel是Netty框架中的组件，负责客户端和服务端链路上的消息传递，channel.write把请求消息写入，这里的message是上面封装的Request对象。这里的IO模型是非阻塞的，线程不用同步等待所有消息写完，而是直接返回。调用Netty框架的IO事件之后会触发Netty框架的IO事件处理链。

dubbo泛化调用使用及原理解析

通常我们想调用别人的dubbo服务时，我们需要在项目中引入对应的jar包。而泛化调用的作用是，我们无需依赖相关jar包，也能调用到该服务。

这个特性一般使用在网关类项目中，在业务开发中基本不会使用。

假设我现在要调用下面的接口服务

在xml文件做以下配置

然后注入使用

在两种调用方式中，我们都需要使用被调用接口的字符串参数生成GenericService，通过GenericService的$invoke间接调用目标接口的接口。

$invoke的三个参数分别为，方法名，方法参数类型数组，方法参数数组。

可以看到泛化调厅并用的一个复杂性弊伏唤在于$invoke的第三个参数的组装，下面介绍几种复杂入参的调用方式

首先丰富提供者接口

与入参相似，虽然$invoke的返回定义为Object，实际上针对不同类型有不同的返回。

泛化调用和直接调用在消费者者端，在 使用上的区别 是，我们调用服务时使用的接口为GenericService，方法为$invoker。在 底层的区别 是，消费者端发出的rpc报文发生了变化。

在使用上，不管哪种配置方式，我们都需要配置generic=true

设置generic=true后，RefereceConfig的interfaceClass会被强制设置为GenericService

这也使得我们的RefereanceBean返回的是GenericService类型的代理。

生成的代理是GenericService的代理只是我们使用方式上的变化，更为核心的是，底层发送的rpc报文发生了什么变化。

Dubbo的rpc报文分为header和body两部分。我们这边只需要关注body部分。构造逻辑如下

那么我们通过直接调用与泛化调用ByeService的bye方法在报文上有啥区别呢？

我一开始以为报文中的path是GenericeService，其实并没有，path就是我们调用的目标方法。

path来源？？？todo

而报文中的方法名，方法参数类型以及具体参数，还是按照GenericeService的$invoke方法入参传递的。

这么个二合一的报文，发送到提供者那边，它估计也会很懵逼，我应该怎么执行？

所以针对泛化调用报文还会把generic=true放在attchment中传递过去

具体逻辑在GenericImplFilter中。

GenericImplFilter中有很多其他逻辑，比如泛化调用使用的序列化协议，正常接口走泛化调用的模式，我们只需要设置attachment的那部分。

知道消费者端报文发生了什么变化，那么接下来就去看提供者端如何处理这个改造后的报文。

总结一下ReferenceConfig中interfaceClass和interfaceName的区别？(这道面试题好像不错)

interfaceClass用于指定生成代理的接口

interfaceName用于指定发送rpc报文中的path(告诉服务端我要调用那个服务)

消费者泛化调用的rpc报文传递到提供者还不能直接使用，虽然path是对的，但是实际的方法名，参数类型，参数要从rpc报文的参数中提取出来。

GenericFilter就是用来做这件事情。

在提供者这边，针对泛化调用的逻辑全部封装到了GenericFilter，解耦的非常好。

注意第4个条件，一开始很疑惑，后来发现rpc报文中的path是目标接口的，这边invoker.getInterface()返回的肯定就是实际接口了

这边有个疑问，为什么这边还要再次反序列化一次，netty不是有decoder么？？

嗯，你别忘了，针对一个POJO你传过来是一个Map，从Map转换为POJO需要这边进一步处理。

这边需要注意一下！！针对接口的泛化调用，抛出的异常都会经过GenericException包装一下。

从功能上来看，泛化调用提供了在没有接口依赖情况下进行的解决方案，丰富框架的使用场景。

从设计上来看，泛化调用的功能还是通租凯过扩展的方式实现的，侵入性不强，值得学习借鉴。

Dubbo的底层实现原理和机制

Dubbo :是一个rpc框架，soa框架

作为RPC:支持各种传输协议，如dubbo,hession,json,fastjson，底层采用mina,netty长连接进行传输！典型的provider和cusomer模式!

作为SOA:具有服务治理功能，提供服务的注册和发现！用zookeeper实现注册中心！启动时候服务端会把所有接口注册到注册中心，并森芦且订阅configurators,服务消费端订阅provide，configurators,routers,订阅逗大变更时，zk会推送providers,configuators，routers,启动时注册长连接，进行通讯！proveider和provider启动后，后台启动定时器，发送统计数据到monitor！提供各种容错机制和负载均衡策略！！

描述一个服务从发布到被消费的详细过程：

一个服务的发布暴露过程：

首先设置一个项目的别名，然后是定义注册中心和设定传输协议，之后定义服务名！服务接口以jar形式导入到provider！

一个服务发布暴露首先由spring的spacehander 把相关的xml或者注解全部转化为springBean,之后通过ServiceConfig.exerp()方法把bean传化为传输所需的url和参数注册到注册中心，发布后provder端的ref(helloImpl)通过protocl(传输协议，如dubboprotocl,hessionprotocl)转化为Invoker对象，即调用信息，包括类，方法，参数等等，再通过proxy操作（代理）如jdkproxy代理转为为Exporter对象，这就是整个的服务暴露过程！

消费过程：

一个Renfence类，通过RenfenceConfig的init 调用proxy的refer方法生产一个invoker,invoker再通过proctol转化成具体的ref(hello),进行消费

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

具体参见

Exporter接口提供Invoker的调用和destroy()

public interface ExporterT {

}

＃Dubbo的实现

Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法，它主要是打开socket侦听服务，并接收客户端发来的各种请求，通讯细节由Dubbo自己实现。

[img]

关于dubborpc和dubborpc返回值是null,但是另一个服务里有值的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。