源码分析Dubbo服务调用-服务提供者如何处理请求命令与再谈Invoker

最新推荐文章于 2024-05-18 11:09:56 发布

Y是设么一手

最新推荐文章于 2024-05-18 11:09:56 发布

阅读量658

点赞数 23

分类专栏：程序员文章标签： dubbo safari 前端

本文链接：https://blog.csdn.net/m0_72758098/article/details/138062665

版权

程序员专栏收录该内容

467 篇文章 0 订阅

订阅专栏

final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);

channels = nettyHandler.getChannels();

// https://issues.jboss.org/browse/NETTY-365

// https://issues.jboss.org/browse/NETTY-379

// final Timer timer = new HashedWheelTimer(new NamedThreadFactory(“NettyIdleTimer”, true));

bootstrap.setPipelineFactory(new ChannelPipelineFactory() {

@Override

public ChannelPipeline getPipeline() {

NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this);

ChannelPipeline pipeline = Channels.pipeline();

pipeline.addLast(“decoder”, adapter.getDecoder()); // @start

pipeline.addLast(“encoder”, adapter.getEncoder());

pipeline.addLast(“handler”, nettyHandler); // @end

return pipeline;

}

});

可以看出，传入Netty框架的事件处理Handler主要是3个：1、解码器；2、编码器；3、业务类NettyHandler。也就是说当服务端(Server)的读事件就绪后，进行网络读写后，会将二进制流传入解码器(Decoder)，解码出一个一个的RPC请求，然后针对每一个RPC请求，交给NettyHandler相关事件处理方法去处理，在这里传入NettyHandler的ChannelHandler为NettyServer,以网络读命令为例，最终将调用NettyServer的父类AbstractPeer的received方法：

@Override

public void received(Channel ch, Object msg) throws RemotingException {

if (closed) {

return;

}

handler.received(ch, msg);

}

那AbstractPeer中的ChannelHandler又是“何许人也”，是通过调用NettyServer(URL url, ChannelHandler handler)中传入的，结合上图中NettyServer的构建流程，可以追溯其流程如下：

DubboProtocol#createServer

server = Exchangers.bind(url, requestHandler); // @1, requestHandler，为最原始的ChannelHandler，接下来整个过程都是对该handler的包装。

HeaderExchanger#bind

return new HeaderExchangeServer(Transporters.bind(url, new

DecodeHandler(new HeaderExchangeHandler(handler))));其包装顺序为 DecodeHandler 》HeaderExchangeHandler 》(DubboProtocol#requestHandler)

NettyTransporter#bind
NettyServer构造函数

super(url, ChannelHandlers.wrap(handler, ExecutorUtil.setThreadName(url, SERVER_THREAD_POOL_NAME)));这里主要包装的是事件的派发Handler，例如AllChannelHandler、ExecutionChannelHandler【Dispatch】业务Handler最终的包装顺序为：事件派发模型handler[AllChannelHandler] 》DecodeHandler 》HeaderExchangeHandler 》 DubboProtocol#requestHandler(最终的业务Handler)。结合网络Netty的处理Handler，服务端事件Handler的处理为：DubboCodec2(解码器) 》事件派发模型handler[AllChannelHandler] 》DecodeHandler 》 HeaderExchangeHandler》 DubboProtocol#requestHandler(最终的业务Handler)。

上述Handler都在前面的章节中详细介绍了，接下来重点分析服务调用流程，自然需要从DubboProtocol$requestHandler入手。

DubboProtocol$requestHandler#recive

@Override

public void received(Channel channel, Object message) throws RemotingException {

if (message instanceof Invocation) {

reply((ExchangeChannel) channel, message);

} else {

super.received(channel, message);

}

如果是服务调用，就进入到reply方法中，否则调用父类进行请求响应。

DubboProtocol$requestHandler#reply

@Override

public Object reply(ExchangeChannel channel, Object message) throws RemotingException {

if (message instanceof Invocation) {

Invocation inv = (Invocation) message; // @1

Invoker<?> invoker = getInvoker(channel, inv); // @2

// need to consider backward-compatibility if it’s a callback

if (Boolean.TRUE.toString().equals(inv.getAttachments().get(IS_CALLBACK_SERVICE_INVOKE))) {

String methodsStr = invoker.getUrl().getParameters().get(“methods”);

boolean hasMethod = false;

if (methodsStr == null || methodsStr.indexOf(“,”) == -1) {

hasMethod = inv.getMethodName().equals(methodsStr);

} else {

String[] methods = methodsStr.split(“,”);

for (String method : methods) {

if (inv.getMethodName().equals(method)) {

hasMethod = true;

break;

}

if (!hasMethod) {

logger.warn(new IllegalStateException("The methodName " + inv.getMethodName()

" not found in callback service interface ,invoke will be ignored."
" please update the api interface. url is:"
invoker.getUrl()) + " ,invocation is :" + inv);

return null;

}

RpcContext.getContext().setRemoteAddress(channel.getRemoteAddress());

return invoker.invoke(inv); // @3

}

throw new RemotingException(channel, "Unsupported request: "

(message == null ? null : (message.getClass().getName() + ": " + message))
", channel: consumer: " + channel.getRemoteAddress() + " --> provider: " + channel.getLocalAddress());

}

代码@1：获取服务调用信息，例如调用服务类名(interface)、服务方法名、参数类型，参数值。

代码@2：获取调用者Invoker。

代码@3：调用Invoker，执行具体的方法调用。

上述过程非常简单，但其关键点在于Invoker，那这个Invoker到底是什么呢？

回顾一下我们在讲解：Dubbo服务提供者启动流程中已提到Invoker，在本篇中我们再次对该文进行补充说明。

2、再谈Dubbo服务提供者暴露服务（Invoker）

2.1 服务提供者视角看Invoker

我们应该记得，服务提供者在暴露服务时(export)会创建Invoker，其代码片段如下：

ServiceConfig#doExportUrlsFor1Protocol

if (registryURLs != null && !registryURLs.isEmpty()) {

for (URL registryURL : registryURLs) {

url = url.addParameterIfAbsent(Constants.DYNAMIC_KEY, registryURL.getParameter(Constants.DYNAMIC_KEY));

URL monitorUrl = loadMonitor(registryURL);

if (monitorUrl != null) {

url = url.addParameterAndEncoded(Constants.MONITOR_KEY, monitorUrl.toFullString());

}

if (logger.isInfoEnabled()) {

logger.info("Register dubbo service " + interfaceClass.getName() + " url " + url + " to registry " + registryURL);

}

Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString())); // @1

DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this); // @2

Exporter<?> exporter = protocol.export(wrapperInvoker); // @3

exporters.add(exporter);

}

} else {

Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);

DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);

Exporter<?> exporter = protocol.export(wrapperInvoker);

exporters.add(exporter);

}

代码@1：根据<dubbo:service ref = “interfaceImpl” interface = “” /> 首先获取ref的代理对象，真正的服务实现类proxy，然后通过proxyFactory【JavassistProxyFactory、JdkProxyFactory】创建最原始的Invoker，即AbstractProxyInvoker，使用的是匿名实现类，即提供反射方式进行方法的调用。

这里写图片描述

从abstract Object doInvoker(T proxy, String methodName, Class< ? >[] parameterTypes, Object[] arguments) 可以最终是通过对象发射方式进行方法调用。

代码@2：首先使用DelegateProviderMetaDataInvoker对AbstractProxyInvoker进行包装，主要是将ServerConfig对象与Invoker一起保存。

代码@3：根据具体协议对服务端Invoker进行导出（继续包装）。

registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.0.0&export=dubbo%3A%2F%2F192.168.56.1%3A20880%2Fcom.alibaba.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddemo-provider%26bind.ip%3D192.168.56.1%26bind.port%3D20880%26dubbo%3D2.0.0%26generic%3Dfalse%26interface%3Dcom.alibaba.dubbo.demo.DemoService%26methods%3DsayHello%26pid%3D14360%26qos.port%3D22222%26side%3Dprovider%26stub%3Dcom.alibaba.dubbo.demo.provider.DemoServiceStub%26timestamp%3D1533944510702&pid=14360&qos.port=22222&registry=zookeeper&timestamp=1533944510687

协议前缀:registry，故根据SPI机制，具体的协议为RegistryProtocol。

registry=zookeeper ：代表注册中心使用zookeeper，在连接注册中心时根据该值进行策略选择。export= dubbo://… : 根据export，在服务端按照协议启动对应的服务端程序，该协议注意指定请求包的二进制协议，例如协议头和协议体。

按照registry协议，应该会直接调用RegistryProtocol#export，但我们忽略了Dubbo的另一机制，该部分也是在服务提供者启动流程中被遗漏。Dubbo为了对服务调用进行包装，采用了过滤器Filter 链模式，在AbstractProxyInvoker调用之前，先执行一系列的过滤器Filter，Dubbo协议默认的协议层面的过滤器代理实现为：com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper,SPI定义文件见：

dubbo-rpc-api/src/main/resources/METAINF/dubbo/internal/com.alibaba.dubbo.rpc.Pr

otocol：

filter=com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper

listener=com.alibaba.dubbo.rpc.protocol.ProtocolListenerWrapper

mock=com.alibaba.dubbo.rpc.support.MockProtocol

ProtocolFilterWrapper#export

public Exporter export(Invoker invoker) throws RpcException {

if (Constants.REGISTRY_PROTOCOL.equals(invoker.getUrl().getProtocol())) { // @1

return protocol.export(invoker);

}

return protocol.export(buildInvokerChain(invoker, Constants.SERVICE_FILTER_KEY, Constants.PROVIDER)); // @2

}