引言
经过之前文章的铺垫，现在可以来分析服务的交互调用过程了。
服务的交互
服务降级
从名字上看我们不难理解MockClusterInvoker相当于是对普通Invoker（如DubboInvoker）的装饰增强，提供集群容错相关的功能，因此最终还是会进入到DubboInvoker，所以这里就以MockClusterInvoker.invoke方法开始分析：
public Result invoke(Invocation invocation) throws RpcException {
Result result = null;
// 获取mock配置
String value = directory.getUrl().getMethodParameter(invocation.getMethodName(), Constants.MOCK_KEY, Boolean.FALSE.toString()).trim();
if (value.length() == 0 || value.equalsIgnoreCase("false")){
// 未配置mock
result = this.invoker.invoke(invocation);
} else if (value.startsWith("force")) {
// 强制执行mock逻辑，不发起远程调用
result = doMockInvoke(invocation, null);
} else {
// 首先调用远程服务，失败后执行mock逻辑，不抛出异常
try {
result = this.invoker.invoke(invocation);
}catch (RpcException e) {
if (e.isBiz()) {
throw e;
} else {
result = doMockInvoke(invocation, e);
}
}
}
return result;
}
Mock服务就是提供一个替代的服务接口，也就是服务降级，从这里看出有三种配置方式：直接调用服务、直接调用mock服务以及远程服务调用失败后调用mock服务。服务降级这里暂不分析，咱们接着看远程服务调用this.invoker.invoke，这个invoker对象上文分析过了，是FailoverClusterInvoker对象（即调用失败后重试其它远程服务），不过该类中没有invoke方法，所以是调用父类的AbstractClusterInvoker.invoke：
public Result invoke(final Invocation invocation) throws RpcException {
checkWheatherDestoried();
LoadBalance loadbalance;
List<Invoker<T>> invokers = list(invocation);
// 获取负载均衡配置，默认使用的是随机算法
if (invokers != null && invokers.size() > 0) {
loadbalance = ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(invokers.get(0).getUrl()
.getMethodParameter(invocation.getMethodName(),Constants.LOADBALANCE_KEY, Constants.DEFAULT_LOADBALANCE));
} else {
loadbalance = ExtensionLoader.getExtensionLoader(LoadBalance.class).getExtension(Constants.DEFAULT_LOADBALANCE);
}
RpcUtils.attachInvocationIdIfAsync(getUrl(), invocation);
// 具体的容错机制有子类实现
return doInvoke(invocation, invokers, loadbalance);
}
这里首先会获取配置的负载均衡算法，默认是使用RandomLoadBalance，不过这个并不是简单的随机，而是加入了权重值，感兴趣的可以去看看其doSelect方法的实现。
集群容错
拿到负载均衡器后，会传入到集群容错的的具体实现类中进行选择。Dubbo默认使用的是FailoverClusterInvoker失败切换容错机制，所以这里以此为例，其它的容错机制读者可自行分析。
public Result doInvoke(Invocation invocation, final List<Invoker<T>> invokers, LoadBalance loadbalance) throws RpcException {
List<Invoker<T>> copyinvokers = invokers;
// 检查invoker列表是否变更
checkInvokers(copyinvokers, invocation);
// 获取需要重试的次数，即invoker个数
int len = getUrl().getMethodParameter(invocation.getMethodName(), Constants.RETRIES_KEY, Constants.DEFAULT_RETRIES) + 1;
if (len <= 0) {
len = 1;
}
// retry loop.
RpcException le = null; // last exception.
// 已经调用过的
List<Invoker<T>> invoked = new ArrayList<Invoker<T>>(copyinvokers.size());
Set<String> providers = new HashSet<String>(len);
for (int i = 0; i < len; i++) {
//重试时，进行重新选择，避免重试时invoker列表已发生变化.
//注意：如果列表发生了变化，那么invoked判断会失效，因为invoker示例已经改变
if (i > 0) {
checkWheatherDestoried();
copyinvokers = list(invocation);
//重新检查一下
checkInvokers(copyinvokers, invocation);
}
// 负载均衡筛选出的invoker
Invoker<T> invoker = select(loadbalance, invocation, copyinvokers, invoked);
invoked.add(invoker);
RpcContext.getContext().setInvokers((List)invoked);
try {
// 调用对应的invoker，执行成功返回对应的结果，否则出现异常则重试其它服务
Result result = invoker.invoke(invocation);
return result;
} catch (RpcException e) {
if (e.isBiz()) { // biz exception.
throw e;
}
le = e;
} catch (Throwable e) {
le = new RpcException(e.getMessage(), e);
} finally {
providers.add(invoker.getUrl().getAddress());
}
}
// 重试失败则抛出异常
throw new RpcException(le != null ? le.getCode() : 0, "Failed to invoke the method "
+ invocation.getMethodName() + " in the service " + getInterface().getName()
+ ". Tried " + len + " times of the providers " + providers
+ " (" + providers.size() + "/" + copyinvokers.size()
+ ") from the registry " + directory.getUrl().getAddress()
+ " on the consumer " + NetUtils.getLocalHost() + " using the dubbo version "
+ Version.getVersion() + ". Last error is: "
+ (le != null ? le.getMessage() : ""), le != null && le.getCause() != null ? le.getCause() : le);
}
该容错机制的逻辑就是根据重试次数进行循环调用，每次循环都会通过select挑选出一个代理对象进行远程调用，若成功则直接返回结果，否则直到达到重试次数抛出异常。select方法中还有一个细节需要注意，我们来看一下：
protected Invoker<T> select(LoadBalance loadbalance, Invocation invocation, List<Invoker<T>> invokers, List<Invoker<T>> selected) throws RpcException {
if (invokers == null || invokers.size() == 0)
return null;
String methodName = invocation == null ? "" : invocation.getMethodName();
// 获取sticky粘滞连接配置，该配置表示是否始终使用同一个服务，除非该服务挂掉
boolean sticky = invokers.get(0).getUrl().getMethodParameter(methodName,Constants.CLUSTER_STICKY_KEY, Constants.DEFAULT_CLUSTER_STICKY) ;
{
// invoker列表中已经没有该粘滞连接对象，表示该服务已挂掉
if ( stickyInvoker != null && !invokers.contains(stickyInvoker) ){
stickyInvoker = null;
}
// 使用粘滞连接需要保证该连接不在invoked列表中，该列表中的服务表示存活且已经调用过的服务，
// 但由于某种原因未提供正常的服务，粘滞连接也不再去调用该服务
if (sticky && stickyInvoker != null && (selected == null || !selected.contains(stickyInvoker))){
// 确保粘滞连接是可用的
if (availablecheck && stickyInvoker.isAvailable()){
return stickyInvoker;
}
}
}
// 使用负载均衡算法挑选出invoker
Invoker<T> invoker = doselect(loadbalance, invocation, invokers, selected);
if (sticky){
stickyInvoker = invoker;
}
return invoker;
}
该方法的逻辑是第一次调用先通过负载均衡算法获取服务，若配置了粘滞连接且该服务正常，则在后续调用中一直使用该服务，直到该服务不可用时再使用负载均衡算法获取服务。
以上就是服务调用前需要执行的保护机制，下面我们就来看看具体的服务调用实现。
服务调用
Result result = invoker.invoke是执行服务调用的逻辑，这里的invoker不难理解由具体的协议决定，这里就是DubboInvoker，同样的，DubboInvoker没有该方法的实现，是继承AbstractInvoker的，可以看到Dubbo中大量使用模板方法模式抽离公共的逻辑，因此具体的实现还是在DubboInvoker的doInvoke方法中：
protected Result doInvoke(final Invocation invocation) throws Throwable {
RpcInvocation inv = (RpcInvocation) invocation;
final String methodName = RpcUtils.getMethodName(invocation);
inv.setAttachment(Constants.PATH_KEY, getUrl().getPath());
inv.setAttachment(Constants.VERSION_KEY, version);
// 获取客户端连接对象
ExchangeClient currentClient;
if (clients.length == 1) {
currentClient = clients[0];
} else {
currentClient = clients[index.getAndIncrement() % clients.length];
}
try {
// 是否异步处理
boolean isAsync = RpcUtils.isAsync(getUrl(), invocation);
// 是否为单向通信，即只是客户端向服务端发送消息，不需要响应
boolean isOneway = RpcUtils.isOneway(getUrl(), invocation);
int timeout = getUrl().getMethodParameter(methodName, Constants.TIMEOUT_KEY,Constants.DEFAULT_TIMEOUT);
if (isOneway) {
// 单向通信，因为不需要等待返回结果，所以这里应该是是异步的
boolean isSent = getUrl().getMethodParameter(methodName, Constants.SENT_KEY, false);
// 发送消息
currentClient.send(inv, isSent);
RpcContext.getContext().setFuture(null);
// 返回空结果
return new RpcResult();
} else if (isAsync) {
// 异步处理，并将返回结果设置到RPC上下文中，由用户调用ResponseFuture.get获取结果
ResponseFuture future = currentClient.request(inv, timeout) ;
RpcContext.getContext().setFuture(new FutureAdapter<Object>(future));
return new RpcResult();
} else {
// 同步等待结果返回
RpcContext.getContext().setFuture(null);
return (Result) currentClient.request(inv, timeout).get();
}
}
}
该方法就是dubbo协议执行远程调用的逻辑，其中包含了异步和同步的处理逻辑，通过ResponseFuture实现，若异步则会将该类的实例设置到上下文环境中，由用户决定何时调用get方法获取结果；若同步则由框架自身调用get方法阻塞等待返回结果。ResponseFuture是一个接口，这里的默认实现是DefaultFuture，先来看看它是如何实现异步处理的：
// 响应结果
private volatile Response response;
// 接收结果，该方法由HeaderExchangeHandler调用
public static void received(Channel channel, Response response) {
try {
DefaultFuture future = FUTURES.remove(response.getId());
if (future != null) {
future.doReceived(response);
} else {
logger.warn("The timeout response finally returned at "
+ (new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(new Date()))
+ ", response " + response
+ (channel == null ? "" : ", channel: " + channel.getLocalAddress()
+ " -> " + channel.getRemoteAddress()));
}
} finally {
CHANNELS.remove(response.getId());
}
}
// 处理响应结果
private void doReceived(Response res) {
lock.lock();
try {
// 保存响应结果并唤醒阻塞线程（即get方法获取结果）
response = res;
if (done != null) {
done.signal();
}
} finally {
lock.unlock();
}
if (callback != null) {
invokeCallback(callback);
}
}
// 客户端获取响应结果
public Object get(int timeout) throws RemotingException {
if (timeout <= 0) {
timeout = Constants.DEFAULT_TIMEOUT;
}
// 还未接收到服务端的响应结果
if (! isDone()) {
long start = System.currentTimeMillis();
lock.lock();
try {
// 服务端还未响应完成时阻塞线程直到结果返回
while (! isDone()) {
done.await(timeout, TimeUnit.MILLISECONDS);
if (isDone() || System.currentTimeMillis() - start > timeout) {
break;
}
}
} catch (InterruptedException e) {
throw new RuntimeException(e);
} finally {
lock.unlock();
}
if (! isDone()) {
throw new TimeoutException(sent > 0, channel, getTimeoutMessage(false));
}
}
// 返回结果给用户
return returnFromResponse();
}
private Object returnFromResponse() throws RemotingException {
Response res = response;
if (res == null) {
throw new IllegalStateException("response cannot be null");
}
if (res.getStatus() == Response.OK) {
return res.getResult();
}
if (res.getStatus() == Response.CLIENT_TIMEOUT || res.getStatus() == Response.SERVER_TIMEOUT) {
throw new TimeoutException(res.getStatus() == Response.SERVER_TIMEOUT, channel, res.getErrorMessage());
}
throw new RemotingException(channel, res.getErrorMessage());
}
上面几个方法为处理服务端响应的主要逻辑，用户可以通过该类的get方法获取响应结果，若是还未接受到响应结果就会阻塞线程直到获取到response，所以是异步还是同步就取决于get方法的调用时机。
我们继续看客户端的请求currentClient.request，但是这个client应该是什么对象呢？
这三个类应该不陌生的，我们在上文分析过，Dubbo默认使用共享连接，因此会使用ReferenceCountExchangeClient对其它两个进行装饰，提供引用计数的功能，这里不过多分析，向下最终都会进入到HeaderExchangeClient的request方法（LazyConnectExchangeClient只是实现懒加载功能，最终也是创建HeaderExchangeClient客户端）并继续调用HeaderExchangeChannel的request方法：
private final ExchangeChannel channel
public ResponseFuture request(Object request, int timeout) throws RemotingException {
return channel.request(request, timeout);
}
public ResponseFuture request(Object request, int timeout) throws RemotingException {
if (closed) {
throw new RemotingException(this.getLocalAddress(), null, "Failed to send request " + request + ", cause: The channel " + this + " is closed!");
}
// 封装请求参数对象
Request req = new Request();
req.setVersion("2.0.0");
// 双向通信标识
req.setTwoWay(true);
// 请求数据
req.setData(request);
DefaultFuture future = new DefaultFuture(channel, req, timeout);
try{
// 使用netty发送消息
channel.send(req);
}catch (RemotingException e) {
future.cancel();
throw e;
}
return future;
}
这里逻辑很清晰，也验证了上文的ResponseFuture对象实际为DefaultFuture，往下就是通过channel发送请求消息，由于Duboo默认使用的是Netty通信，所以这里应该是NettyChannel对象，
不过由于参数列表不匹配，这里首先是调用的其父类AbstractPeer的send方法，然后才进入到NettyChannel中：
// AbstractPeer
public void send(Object message) throws RemotingException {
send(message, url.getParameter(Constants.SENT_KEY, false));
}
// NettyChannel
public void send(Object message, boolean sent) throws RemotingException {
super.send(message, sent);
boolean success = true;
int timeout = 0;
try {
ChannelFuture future = channel.write(message);
if (sent) {
timeout = getUrl().getPositiveParameter(Constants.TIMEOUT_KEY, Constants.DEFAULT_TIMEOUT);
success = future.await(timeout);
}
Throwable cause = future.getCause();
if (cause != null) {
throw cause;
}
} catch (Throwable e) {
throw new RemotingException(this, "Failed to send message " + message + " to " + getRemoteAddress() + ", cause: " + e.getMessage(), e);
}
if(! success) {
throw new RemotingException(this, "Failed to send message " + message + " to " + getRemoteAddress()
+ "in timeout(" + timeout + "ms) limit");
}
}
至此，客户端调用服务的流程就完成了，下面是整个客户端调用的时序图，为简略，省去了一些具体实现类：
由于是Netty通信，数据出站和入站时会有对应的编码和解码操作，这里就不分析了，下面直接看服务端如何接收处理请求的。
服务端接收请求
服务端是通过NettyHandler.messageReceived接收处理请求的：
private final ChannelHandler handler;
public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {
NettyChannel channel = NettyChannel.getOrAddChannel(ctx.getChannel(), url, handler);
try {
handler.received(channel, e.getMessage());
} finally {
NettyChannel.removeChannelIfDisconnected(ctx.getChannel());
}
}
主要逻辑在hander.received方法中，但这个handler有很多实现类，应该是哪一个呢？
在分析发布服务的时候在HeaderExchanger.bind方法中包装了很多个handler：
public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));
}
继续追踪Transporters.bind方法，最终会再对handler进行包装：
protected ChannelHandler wrapInternal(ChannelHandler handler, URL url) {
return new MultiMessageHandler(new HeartbeatHandler(ExtensionLoader.getExtensionLoader(Dispatcher.class)
.getAdaptiveExtension().dispatch(handler, url)));
}
这里拿到的扩展点为AllDispatcher，该类同样是包装handler：
public ChannelHandler dispatch(ChannelHandler handler, URL url) {
return new AllChannelHandler(handler, url);
}
所以，最终的调用处理链为：
MultiMessageHandler
-> HeartbeatHandler
-> AllChannelHandler
-> DecodeHandler
-> HeaderExchangeHandler
先来看看各个handler的作用：
- MultiMessageHandler ：复合消息处理
- HeartbeatHandler ：心跳消息的处理
- AllChannelHandler：线程派发处理器，将接收到的消息封装成ChannelEventRunnable交给线程池处理
- DecodeHandler：解码处理
- HeaderExchangeHandler：响应处理
前两个handler的逻辑没必要分析了，这里从AllChannelHandler开始，这个是Dubbo的线程派发模型的实现。什么是线程派发模型？简单的说就是Dubbo为提高请求处理效率，将能够简单快速处理的逻辑交由IO线程处理，而复杂耗时的操作交由线程池异步处理（哪些操作应放入线程池，可由用户配置决定）。Dubbo共提供了5种线程派发策略：
- all：所有消息都派发到线程池，包括请求，响应，连接事件，断开事件等
- direct：所有消息都不派发到线程池，全部在 IO 线程上直接执行
- message：只有请求和响应消息派发到线程池，其它消息均在 IO 线程上执行
- execution：只有请求消息派发到线程池，不含响应。其它消息均在 IO 线程上执行
- connection：在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池
默认情况下使用的是all，即AllChannelHandler：
public class AllChannelHandler extends WrappedChannelHandler {
// 连接消息
public void connected(Channel channel) throws RemotingException {
ExecutorService cexecutor = getExecutorService();
try{
cexecutor.execute(new ChannelEventRunnable(channel, handler ,ChannelState.CONNECTED));
}catch (Throwable t) {
throw new ExecutionException("connect event", channel, getClass()+" error when process connected event ." , t);
}
}
// 连接断开消息
public void disconnected(Channel channel) throws RemotingException {
ExecutorService cexecutor = getExecutorService();
try{
cexecutor.execute(new ChannelEventRunnable(channel, handler ,ChannelState.DISCONNECTED));
}catch (Throwable t) {
throw new ExecutionException("disconnect event", channel, getClass()+" error when process disconnected event ." , t);
}
}
// 接收响应消息
public void received(Channel channel, Object message) throws RemotingException {
ExecutorService cexecutor = getExecutorService();
try {
cexecutor.execute(new ChannelEventRunnable(channel, handler, ChannelState.RECEIVED, message));
} catch (Throwable t) {
throw new ExecutionException(message, channel, getClass() + " error when process received event .", t);
}
}
// 异常消息
public void caught(Channel channel, Throwable exception) throws RemotingException {
ExecutorService cexecutor = getExecutorService();
try{
cexecutor.execute(new ChannelEventRunnable(channel, handler ,ChannelState.CAUGHT, exception));
}catch (Throwable t) {
throw new ExecutionException("caught event", channel, getClass()+" error when process caught event ." , t);
}
}
}
当前流程我们主要看received方法，该方法将请求对象封装到ChannelEventRunnablec类中，而该类是实现了Runnable接口的，意为着我们直接看run方法就可以了：
public void run() {
switch (state) {
case RECEIVED:
try{
handler.received(channel, message);
}catch (Exception e) {
logger.warn("ChannelEventRunnable handle " + state + " operation error, channel is " + channel
+ ", message is "+ message,e);
}
break;
}
}
这里我只截取了关键的代码片段，可以看到是直接交给下一个handler处理的，即DecodeHandler处理，该类是执行解码操作，也不分析了，直接看HeaderExchangeHandler.received方法：
public void received(Channel channel, Object message) throws RemotingException {
channel.setAttribute(KEY_READ_TIMESTAMP, System.currentTimeMillis());
ExchangeChannel exchangeChannel = HeaderExchangeChannel.getOrAddChannel(channel);
try {
if (message instanceof Request) {
// 处理请求
Request request = (Request) message;
if (request.isEvent()) {
// 处理事件消息
handlerEvent(channel, request);
} else {
// 处理普通请求
if (request.isTwoWay()) {
// 双向通信
Response response = handleRequest(exchangeChannel, request);
channel.send(response);
} else {
// 单向通信，无需返回请求结果
handler.received(exchangeChannel, request.getData());
}
}
} else if (message instanceof Response) {
// 处理响应
handleResponse(channel, (Response) message);
} else if (message instanceof String) {
.....
} else {
handler.received(exchangeChannel, message);
}
} finally {
HeaderExchangeChannel.removeChannelIfDisconnected(channel);
}
}
Response handleRequest(ExchangeChannel channel, Request req) throws RemotingException {
Response res = new Response(req.getId(), req.getVersion());
// 请求错误，返回错误消息
if (req.isBroken()) {
Object data = req.getData();
String msg;
if (data == null) msg = null;
else if (data instanceof Throwable) msg = StringUtils.toString((Throwable) data);
else msg = data.toString();
res.setErrorMessage("Fail to decode request due to: " + msg);
res.setStatus(Response.BAD_REQUEST);
return res;
}
// 调用服务
Object msg = req.getData();
try {
// 继续调用，这里的handler又是哪一个呢？
Object result = handler.reply(channel, msg);
res.setStatus(Response.OK);
res.setResult(result);
} catch (Throwable e) {
res.setStatus(Response.SERVICE_ERROR);
res.setErrorMessage(StringUtils.toString(e));
}
return res;
}
上面交互的逻辑不复杂，执行远程调用时会继续向下调用handler.reply方法，这个handler是什么呢？还记得在DubboProtocol.createServer方法中传入的requestHandler么？
private ExchangeHandler requestHandler = new ExchangeHandlerAdapter() {
public Object reply(ExchangeChannel channel, Object message) throws RemotingException {
if (message instanceof Invocation) {
Invocation inv = (Invocation) message;
// 获取服务端Invoker对象
Invoker<?> invoker = getInvoker(channel, inv);
//如果是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;
}
}
}
}
RpcContext.getContext().setRemoteAddress(channel.getRemoteAddress());
// 调用invoke方法，最终会调用服务端实现的具体服务方法
return invoker.invoke(inv);
}
throw new RemotingException(channel, "Unsupported request: " + message == null ? null : (message.getClass().getName() + ": " + message) + ", channel: consumer: " + channel.getRemoteAddress() + " --> provider: " + channel.getLocalAddress());
}
// 忽略其它方法
};
通过getInvoker方法获取服务端的Invoker对象，然后通过该对象去调用具体的服务，但这里的Invoker对象具体是哪一个呢？在服务发布章节中，分析过Invoker，是通过JavassistProxyFactory.getInvoker创建了一个AbstractProxyInvoker的匿名内部类，并通过Wrapper去调用代理对象的方法，那这里获取到的就是这个匿名内部类么？
还没有这么简单，在RegistryProtocol.doLocalExport方法中首先使用InvokerDelegete对Invoker进行了包装，然后调用protocol.export方法，这个之前我们也分析过，会经过ProtocolListenerWrapper -> ProtocolFilterWrapper -> DubboProtocol，主要看看filter.export：
public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
if (Constants.REGISTRY_PROTOCOL.equals(invoker.getUrl().getProtocol())) {
return protocol.export(invoker);
}
return protocol.export(buildInvokerChain(invoker, Constants.SERVICE_FILTER_KEY, Constants.PROVIDER));
}
private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker, String key, String group) {
Invoker<T> last = invoker;
List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);
if (filters.size() > 0) {
for (int i = filters.size() - 1; i >= 0; i --) {
final Filter filter = filters.get(i);
final Invoker<T> next = last;
last = new Invoker<T>() {
public Class<T> getInterface() {
return invoker.getInterface();
}
public URL getUrl() {
return invoker.getUrl();
}
public boolean isAvailable() {
return invoker.isAvailable();
}
public Result invoke(Invocation invocation) throws RpcException {
return filter.invoke(next, invocation);
}
public void destroy() {
invoker.destroy();
}
@Override
public String toString() {
return invoker.toString();
}
};
}
}
return last;
}
可以看到这里获取了Filter扩展点构建了一个过滤链层层过滤，在配置文件中可以看到有如下过滤器：
echo=com.alibaba.dubbo.rpc.filter.EchoFilter
generic=com.alibaba.dubbo.rpc.filter.GenericFilter
genericimpl=com.alibaba.dubbo.rpc.filter.GenericImplFilter
token=com.alibaba.dubbo.rpc.filter.TokenFilter
accesslog=com.alibaba.dubbo.rpc.filter.AccessLogFilter
activelimit=com.alibaba.dubbo.rpc.filter.ActiveLimitFilter
classloader=com.alibaba.dubbo.rpc.filter.ClassLoaderFilter
context=com.alibaba.dubbo.rpc.filter.ContextFilter
consumercontext=com.alibaba.dubbo.rpc.filter.ConsumerContextFilter
exception=com.alibaba.dubbo.rpc.filter.ExceptionFilter
executelimit=com.alibaba.dubbo.rpc.filter.ExecuteLimitFilter
deprecated=com.alibaba.dubbo.rpc.filter.DeprecatedFilter
compatible=com.alibaba.dubbo.rpc.filter.CompatibleFilter
timeout=com.alibaba.dubbo.rpc.filter.TimeoutFilter
monitor=com.alibaba.dubbo.monitor.support.MonitorFilter
validation=com.alibaba.dubbo.validation.filter.ValidationFilter
cache=com.alibaba.dubbo.cache.filter.CacheFilter
trace=com.alibaba.dubbo.rpc.protocol.dubbo.filter.TraceFilter
future=com.alibaba.dubbo.rpc.protocol.dubbo.filter.FutureFilter
所以在requestHandler中调用invoker.invoke方法会经过上面的过滤器层层过滤后才到达最后的服务调用。
总结
Dubbo的服务发布、订阅以及交互过程是非常复杂的，总共用了三篇文章来理清整个流程，但其中还有很多的细节没有深入讲解，感兴趣的读者可自行分析，下一篇将分析Dubbo的服务目录源码，也是Dubbo系列的最后一篇。