dubbo源码分析-回调的实现

这里dubbo的官方文档有一个回调的例子，看看dubbo在内部是如何支持回调的。

CallbackServiceCodec类是用来编码和解码调用方法的参数的，dubbo正是通过判断参数的类型来处理回调的：

private static byte isCallBack(URL url, String methodName ,int argIndex){
        //参数callback的规则是 方法名称.参数index(0开始).callback
        byte isCallback = CALLBACK_NONE;
        if (url != null ) {
            String callback = url.getParameter(methodName+"."+argIndex+".callback");
            if(callback !=  null) {
                if (callback.equalsIgnoreCase("true")) { 
                    isCallback = CALLBACK_CREATE;
                }else if(callback.equalsIgnoreCase("false")){
                    isCallback = CALLBACK_DESTROY;
                }
            }
        }
        return isCallback;
    }

isCallback用来判断参数的类型是否是回调。

public static Object encodeInvocationArgument(Channel channel, RpcInvocation inv, int paraIndex) throws IOException{
        //encode时可直接获取url
        URL url = inv.getInvoker() == null ? null : inv.getInvoker().getUrl();
        byte callbackstatus = isCallBack(url, inv.getMethodName(), paraIndex);
        Object[] args = inv.getArguments();
        Class<?>[] pts = inv.getParameterTypes();
        switch (callbackstatus) {
            case CallbackServiceCodec.CALLBACK_NONE:
                return args[paraIndex];
            case CallbackServiceCodec.CALLBACK_CREATE:
                inv.setAttachment(INV_ATT_CALLBACK_KEY + paraIndex , exportOrunexportCallbackService(channel, url, pts[paraIndex], args[paraIndex], true));
                return null;
            case CallbackServiceCodec.CALLBACK_DESTROY:
                inv.setAttachment(INV_ATT_CALLBACK_KEY + paraIndex, exportOrunexportCallbackService(channel, url, pts[paraIndex], args[paraIndex], false));
                return null;
            default:
                return args[paraIndex];
        }
    }

可以看到encodeInvocationArgument里面判断参数的类型如果是回调（CALLBACK_CREATE，值为1）的话，会执行exportOrunexportCallbackService，里面会为回调参数对象暴露一个接口：

Invoker<?> invoker = proxyFactory.getInvoker(inst, clazz, exporturl);
Exporter<?> exporter = protocol.export(invoker);

ok，客户端把回调接口暴漏出来了。

再来看服务器端：
同样在CallbackServiceCodec类里面：

public static Object decodeInvocationArgument(Channel channel, RpcInvocation inv, Class<?>[] pts, int paraIndex, Object inObject) throws IOException{
        // ...
        byte callbackstatus = isCallBack(url, inv.getMethodName(), paraIndex);
        switch (callbackstatus) {
            case CallbackServiceCodec.CALLBACK_NONE:
                return inObject;
            case CallbackServiceCodec.CALLBACK_CREATE:
               return referOrdestroyCallbackService(channel, url, pts[paraIndex], inv, Integer.parseInt(inv.getAttachment(INV_ATT_CALLBACK_KEY + paraIndex)), true);
                // ....
        }
    }

在解析参数时，判断如果是回调参数，那么生成一个代理：

Invoker<?> invoker = new ChannelWrappedInvoker(clazz, channel, referurl, String.valueOf(instid));
proxy = proxyFactory.getProxy(invoker);

可以看到根据url生成了一个代理，那么我们实际在调用回调方法的时候，会被传递到客户端去执行客户端的代码。
另外只需要在provider中配置回调参数，这些配置信息会通过registry传递到consumer中。