Dubbo 3.x源码(21)—Dubbo服务引用源码(4)

标签：Dubbo 服务 21 url 源码 registry 方法 invoker

基于Dubbo 3.1，详细介绍了Dubbo服务的发布与引用的源码。

此前我们学习了createInvokerForRemote方法中的Wrapper有哪些以及作用，接下来我们将会的学习真正的本地、应用级别、接口级别的Protocol的引入逻辑，以及创建Proxy服务接口代理对象的逻辑。

Dubbo 3.x服务引用源码：

Dubbo 3.x服务发布源码：

1 InjvmProtocol本地引入协议

这是本地引入的协议实现，其代码很简单，就是构建一个InjvmInvoker对象实例，同时内部保存着本地导出的服务缓存exporterMap。

本地引入并没有涉及到注册中心以及网络服务器客户端。

/**
 * AbstractProtocol的方法
 */
@Override
public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
    //该方法由子类实现
    return protocolBindingRefer(type, url);
}
/**
 * InjvmProtocol的方法
 */
@Override
public <T> Invoker<T> protocolBindingRefer(Class<T> serviceType, URL url) throws RpcException {
    //返回一个InjvmInvoker实例，同时内部保存着本地导出的服务缓存exporterMap
    return new InjvmInvoker<T>(serviceType, url, url.getServiceKey(), exporterMap);
}

2 RegistryProtocol应用级远程服务引入协议

应用级服务远程协议以service-discovery-registry开头，其对应的Protocol实现就是RegistryProtocol。RegistryProtocol的refer方法大概步骤为：

调用getRegistryUrl方法获取注册中心协议url，如果是RegistryProtocol的实现则将url更换为应用级服务发现协议url，如果是InterfaceCompatibleRegistryProtocol的实现则尝试url更换为真实注册中心协议url。
调用getRegistry方法获取注册中心操作类Registry。基于Dubbo SPI机制根据url的协议加载具体的注册中心操作类，service-discovery-registry对应着ServiceDiscoveryRegistry，zookeeper对应着ZookeeperRegistry。
如果服务类型为RegistryService，那么通过proxyFactory基于registry实例获取Invoker。
获取group属性，即想要引用的服务分组。如果配置了分组，调用doRefer方法基于MergeableCluster继续引用服务，否则调用doRefer方法基于基于服务参数指定的cluster继续引用服务。

/**
 * RegistryProtocol的方法
 *
 * @param type 服务类型
 * @param url  远程注册中心服务协议地址，以service-discovery-registry或者registry作为协议
 */
@Override
@SuppressWarnings("unchecked")
public <T> Invoker<T> refer(Class<T> type, URL url) throws RpcException {
    /*
     * 1 获取注册中心协议url。
     */
    url = getRegistryUrl(url);
    /*
     * 2 获取注册中心操作类Registry
     * 基于Dubbo SPI机制根据url的协议加载具体的注册中心操作类，service-discovery-registry对应着ServiceDiscoveryRegistry
     * zookeeper对应着ZookeeperRegistry
     */
    Registry registry = getRegistry(url);
    //如果服务类型为RegistryService
    if (RegistryService.class.equals(type)) {
        //基于registry实例获取Invoker
        return proxyFactory.getInvoker((T) registry, type, url);
    }

    // group="a,b" or group="*"
    //获取服务引用属性map
    Map<String, String> qs = (Map<String, String>) url.getAttribute(REFER_KEY);
    //获取group，即想要引用的服务分组
    String group = qs.get(GROUP_KEY);
    //如果配置了分组
    if (StringUtils.isNotEmpty(group)) {
        if ((COMMA_SPLIT_PATTERN.split(group)).length > 1 || "*".equals(group)) {
            //调用doRefer方法基于MergeableCluster继续引用服务
            return doRefer(Cluster.getCluster(url.getScopeModel(), MergeableCluster.NAME), registry, type, url, qs);
        }
    }
    //基于Dubbo SPI获取Cluster实现，Cluster用于支持集群容错策略
    Cluster cluster = Cluster.getCluster(url.getScopeModel(), qs.get(CLUSTER_KEY));
    //调用doRefer方法基于基于服务参数指定的cluster继续引用服务
    return doRefer(cluster, registry, type, url, qs);
}

2.1 getRegistryUrl获取注册中心url

该方法会判断当前协议如果已经是应用级服务发现协议，即service-discovery-registry，那么直接返回原协议。否则，url添加registry={protocol}参数，并且协议设置为service-discovery-registry协议，即应用级服务发现协议。

即RegistryProtocol#getRegistryUrl方法主要是将注册中心协议url更换为应用级服务发现协议url。

/**
 * RegistryProtocol的方法
 *
 * @param url 远程服务发现协议url
 * @return 注册中心协议url
 */
protected URL getRegistryUrl(URL url) {
    //如果是应用级服务发现协议，即service-discovery-registry，那么直接返回原协议
    if (SERVICE_REGISTRY_PROTOCOL.equals(url.getProtocol())) {
        return url;
    }
    //否则，url添加registry={protocol}参数，并且协议设置为service-discovery-registry协议
    return url.addParameter(REGISTRY_KEY, url.getProtocol()).setProtocol(SERVICE_REGISTRY_PROTOCOL);
}

2.2 getCluster获取集群对象

//基于Dubbo SPI获取Cluster实现，Cluster用于支持集群容错策略
Cluster cluster = Cluster.getCluster(url.getScopeModel(), qs.get(CLUSTER_KEY));

集群对象Cluster，实际上Cluster不仅仅有容错功能，因为其还代表着Dubbo十层架构中的集群层，因此，集群路由、负载均衡、发起RPC调用、失败重试、服务降级都是在该层实现的。但是这些功能不都是由Cluster接口实现的，而是由集群层的其他核心接口实现，例如Directory 、 Router 、 LoadBalance。

Cluster通过基于Dubbo SPI机制获取，同时还会被wrapper包装，可以通过属性cluster设置集群方式，可选：failover/failfast/failsafe/failback/forking，如不设置默认failover，即FailoverCluster。


static Cluster getCluster(ScopeModel scopeModel, String name) {
    //允许wrapper
    return getCluster(scopeModel, name, true);
}

static Cluster getCluster(ScopeModel scopeModel, String name, boolean wrap) {
    //如果name为空，那么默认failover
    if (StringUtils.isEmpty(name)) {
        name = Cluster.DEFAULT;
    }
    //基于Dubbo SPI获取，可能会经过wrapper
    return ScopeModelUtil.getApplicationModel(scopeModel).getExtensionLoader(Cluster.class).getExtension(name, wrap);
}

由于允许wrapper包装，那么实际返回的Cluster并不是FailoverCluster，而是MockClusterWrapper。

2.3 doRefer执行远程引用服务

该方法执行远程引用服务，RegistryProtocol和InterfaceCompatibleRegistryProtocol对于该方法的大概方法骨架是一样的，只是某些方法实现不同。

大概步骤为：

根据消费方的服务引用配置构建服务消费invoker，协议为服务消费配置的protocol属性，表示只调用指定协议的服务提供方，其它协议忽略，默认值consumer。随后将当前consumerUrl存入注册中心协议url的属性缓存中，key为CONSUMER_URL。
调用getMigrationInvoker方法获取可迁移Invoker。应用级服务引用RegistryProtocol的getMigrationInvoker方法将会返回ServiceDiscoveryMigrationInvoker。而对于接口级注服务引用InterfaceCompatibleRegistryProtocol来说，将会返回MigrationInvoker。
调用interceptInvoker方法拦截invoker。实际上就是获取所有RegistryProtocolListener然后执行他们的onRefer，可用于在服务引用时更改invoker的行为和配置。

/**
 * RegistryProtocol的方法
 * 引用服务
 *
 * @param cluster    支持不同容错策略的Cluster，默认FailoverCluster
 * @param registry   注册中心操作类。例如ServiceDiscoveryRegistry、ZookeeperRegistry
 * @param type       服务接口
 * @param url        注册中心协议url
 * @param parameters 服务引用参数
 * @return Invoker
 */
protected <T> Invoker<T> doRefer(Cluster cluster, Registry registry, Class<T> type, URL url, Map<String, String> parameters) {
    //获取消费者属性，即attributes属性，内部包括：serviceModel、refer（服务引用参数）、scopeModel
    Map<String, Object> consumerAttribute = new HashMap<>(url.getAttributes());
    consumerAttribute.remove(REFER_KEY); //移除refer，因为方法参数已经传递了
    //获取protocol属性，只调用指定协议的服务提供方，其它协议忽略，默认值consumer
    String p = isEmpty(parameters.get(PROTOCOL_KEY)) ? CONSUMER : parameters.get(PROTOCOL_KEY);
    //构建服务配置url
    URL consumerUrl = new ServiceConfigURL(
        //协议，如不指定默认consumer
        p,
        //用户名
        null,
        //密码
        null,
        //ip
        parameters.get(REGISTER_IP_KEY),
        //端口0，path服务接口全路径
        0, getPath(parameters, type),
        parameters,
        consumerAttribute
    );
    //将当前consumerUrl存入注册中心协议url的属性缓存中，key为CONSUMER_URL
    url = url.putAttribute(CONSUMER_URL_KEY, consumerUrl);
    /*
     * 获取可迁移Invoker
     */
    ClusterInvoker<T> migrationInvoker = getMigrationInvoker(this, cluster, registry, type, url, consumerUrl);
    //拦截invoker
    return interceptInvoker(migrationInvoker, url, consumerUrl);
}

2.3.1 getMigrationInvoker获取可迁移Invoker

对于使用了应用级注册中心协议的RegistryProtocol来说，getMigrationInvoker方法将会返回一个ServiceDiscoveryMigrationInvoker。而对于接口级注册中心协议的InterfaceCompatibleRegistryProtocol来说，将会返回MigrationInvoker，他们都是可迁移Invoker。其中ServiceDiscoveryMigrationInvoker继承了MigrationInvoker。

RegistryProtocol：

/**
 * RegistryProtocol的方法
 * 获取可迁移Invoker
 *
 * @param registryProtocol 注册表协议
 * @param cluster          集群
 * @param registry         注册中心
 * @param type             接口类型
 * @param url              注册中心协议url
 * @param consumerUrl      消费者url
 * @return 可迁移Invoker
 */
protected <T> ClusterInvoker<T> getMigrationInvoker(RegistryProtocol registryProtocol, Cluster cluster, Registry registry, Class<T> type, URL url, URL consumerUrl) {
    return new ServiceDiscoveryMigrationInvoker<T>(registryProtocol, cluster, registry, type, url, consumerUrl);
}

InterfaceCompatibleRegistryProtocol：

/**
 * InterfaceCompatibleRegistryProtocol的方法
 * 获取可迁移Invoker
 *
 * @param registryProtocol 注册表协议
 * @param cluster          集群
 * @param registry         注册中心
 * @param type             接口类型
 * @param url              注册中心协议url
 * @param consumerUrl      消费者url
 * @return 可迁移Invoker
 */
@Override
protected <T> ClusterInvoker<T> getMigrationInvoker(RegistryProtocol registryProtocol, Cluster cluster, Registry registry, Class<T> type, URL url, URL consumerUrl) {
    //ClusterInvoker<T> invoker = getInvoker(cluster, registry, type, url);
    //获取MigrationInvoker
    return new MigrationInvoker<T>(registryProtocol, cluster, registry, type, url, consumerUrl);
}

所谓迁移，实际上是Dubbo 3的概念，因为Dubbo 3引入应用级服务发现，因此2.x 版本升级到3.x版本的时候，将会涉及到从接口级服务发现迁移至应用级服务发现。

Dubbo3的消费者和提供者一样，具备同时发现 2.x 与 3.x 提供者地址列表的能力，即服务双订阅，而这个可迁移Invoker，实际上表示消费者能够自动选择2.x 或者 3.x中的一种来消费。

在 Dubbo 3 之前地址注册模型是以接口级粒度注册到注册中心的，而 Dubbo 3 全新的应用级注册模型注册到注册中心的粒度是应用级的。从注册中心的实现上来说是几乎不一样的，这导致了对于从接口级注册模型获取到的 invokers 是无法与从应用级注册模型获取到的 invokers 进行合并的。为了帮助用户从接口级往应用级迁移，Dubbo 3 设计了 Migration 机制，基于三个状态的切换实现实际调用中地址模型的切换。这就是迁移的含义，而可迁移，就是可以在这三个状态之间动态转换。

三种迁移状态：FORCE_INTERFACE（强制接口级），APPLICATION_FIRST（应用级优先）、FORCE_APPLICATION（强制应用级）。

FORCE_INTERFACE：只启用兼容模式下接口级服务发现的注册中心逻辑，调用流量 100% 走原有流程。
APPLICATION_FIRST：开启接口级、应用级双订阅，运行时根据阈值和灰度流量比例动态决定调用流量走向。
FORCE_APPLICATION：只启用新模式下应用级服务发现的注册中心逻辑，调用流量 100% 走应用级订阅的地址。

2.3.2 interceptInvoker拦截invoker

该方法尝试加载所有的RegistryProtocolListener定义，这些定义用于通过与已定义的交互来控制调用程序的行为，然后使用这些侦听器来更改MigrationInvoker的状态和行为，最后返回MigrationInvoker。

说白了，引入RegistryProtocol监听器是为了让用户有机会定制或更改RegistryProtocol的导出和引用行为。

该方法的大概逻辑为：

根据url参数registry.protocol.listener作为扩展名获取RegistryProtocolListener的Dubbo SPI实现，如果没有该参数则获取全部实现列表。
遍历所有RegistryProtocolListener，依次调用他们的onRefer方法，用于更改invoker。

当前版本可用的监听器仅一个MigrationRuleListener，它用于通过动态更改规则来控制迁移行为，同时它的onRefer方法才是真正的服务引入的方法，关于它的源码我们下文分析。

/**
 * RegistryProtocol的方法
 * <p>
 * 拦截Invoker
 * <p>
 * 该方法尝试加载所有的RegistryProtocolListener定义，这些定义用于通过与已定义的交互来控制调用程序的行为，然后使用这些侦听器来更改MigrationInvoker的状态和行为。
 * 当前版本可用的监听器是MigrationRuleListener，它用于通过动态更改规则来控制迁移行为。
 *
 * @param invoker     MigrationInvoker，它确定要使用哪种类型的调用程序列表
 * @param url         原始url，例如service-discovery-registry://47.94.229.245:2181/org.apache.dubbo.registry.RegistryService?REGISTRY_CLUSTER=demo1&application=demo-consumer&dubbo=2.0.2&pid=8228&registry=zookeeper&registry-type=service&registry.type=service&timeout=20000&timestamp=1666884631226
 * @param consumerUrl 表示当前接口及其配置的使用者url
 * @param <T>         服务定义
 * @return 传入的MigrationInvoker
 */
protected <T> Invoker<T> interceptInvoker(ClusterInvoker<T> invoker, URL url, URL consumerUrl) {
    //根据url参数registry.protocol.listener作为扩展名获取RegistryProtocolListener的Dubbo SPI实现，如果没有该参数则获取全部实现列表
    //当前版本可用的监听器仅一个MigrationRuleListener，它用于通过动态更改规则来控制迁移行为。
    List<RegistryProtocolListener> listeners = findRegistryProtocolListeners(url);
    //没有监听器直接返回
    if (CollectionUtils.isEmpty(listeners)) {
        return invoker;
    }
    //遍历所有监听器，执行监听器的onRefer方法
    for (RegistryProtocolListener listener : listeners) {
        listener.onRefer(this, invoker, consumerUrl, url);
    }
    return invoker;
}

3 InterfaceCompatibleRegistryProtocol接口级远程服务引入协议

接口级服务远程导出协议以registry开头，其对应的Protocol实现就是InterfaceCompatibleRegistryProtocol。

实际上InterfaceCompatibleRegistryProtocol继承了RegistryProtocol，大部分代码都是一样的，例如refer引入服务的方法，仅仅是一些细微的代码不一致。我们来看看它在refer过程中的特有的方法。

3.1 getRegistryUrl获取注册中心url

该方法根据远程服务协议url获取注册中心url，会对远程服务发现协议url进行处理、还原。获取url中的registry属性，也就是真实的注册中心协议，例如zookeeper，默认dubbo，然后替换掉registry协议并删除registry属性返回。

即InterfaceCompatibleRegistryProtocol#getRegistryUrl方法主要是将远程服务发现协议url更换为真实注册中心协议url。

/**
 * InterfaceCompatibleRegistryProtocol的方法
 * 
 * @param url 远程服务发现协议url
 * @return
 */
@Override
protected URL getRegistryUrl(URL url) {
    return URLBuilder.from(url)
        //获取url中的registry属性，也就是真实的注册中心协议，例如zookeeper，默认dubbo，然后替换掉registry协议
            .setProtocol(url.getParameter(REGISTRY_KEY, DEFAULT_REGISTRY))
        //删除registry属性
            .removeParameter(REGISTRY_KEY)
            .build();
}

4 getProxy创建服务接口代理对象

在进行了服务引入并创建了服务引入Invoker之后，在最后会调用proxyFactory#getProxy方法根据invoker创建一个服务接口代理对象返回。

这里的proxyFactory是ProxyFactory的自适应扩展实现，即ProxyFactory$Adaptive，也就是说会根据传入的url中的参数proxy的值选择对应的代理工厂实现类，而默认实现就是JavassistProxyFactory，因为它速度更快。最后通过真正的代理工厂实现类的getProxy方法创建服务代理对象。

在此前学习Dubbo服务发布的时候，同样是调用proxyFactory#getInvoker方法创建的一个代理Invoker实例对象的。

/**
 * ProxyFactory$Adaptive的方法
 * 创建服务代理对象
 * @param arg0 服务引入invoker
 * @param arg1 是否是泛型接口
 * @return 服务代理对象
 * @throws org.apache.dubbo.rpc.RpcException
 */
public java.lang.Object getProxy(org.apache.dubbo.rpc.Invoker arg0, boolean arg1) throws org.apache.dubbo.rpc.RpcException {
    if (arg0 == null) throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument == null");
    if (arg0.getUrl() == null)
        throw new IllegalArgumentException("org.apache.dubbo.rpc.Invoker argument getUrl() == null");
    //注册中心协议url
    org.apache.dubbo.common.URL url = arg0.getUrl();
    //获取url中的proxy参数，默认javassist
    String extName = url.getParameter("proxy", "javassist");
    if (extName == null)
        throw new IllegalStateException("Failed to get extension (org.apache.dubbo.rpc.ProxyFactory) name from url (" + url.toString() + ") use keys([proxy])");
    ScopeModel scopeModel = ScopeModelUtil.getOrDefault(url.getScopeModel(), org.apache.dubbo.rpc.ProxyFactory.class);
    //基于Dubbo SPi机制查找指定名字的实现，默认JavassistProxyFactory
    org.apache.dubbo.rpc.ProxyFactory extension = (org.apache.dubbo.rpc.ProxyFactory) scopeModel.getExtensionLoader(org.apache.dubbo.rpc.ProxyFactory.class).getExtension(extName);
    //通过ProxyFactory的getProxy方法获取服务代理对象
    return extension.getProxy(arg0, arg1);
}

4.1 JavassistRpcProxyFactory#getProxy

基于Javassist创建给定接口的代理对象，调用处理器为InvokerInvocationHandler，内部封装了invoker的调用。javassist创建失败之后，回退到基于jdk动态代理的方式创建代理对象。

/**
 * JavassistRpcProxyFactory的方法
 *
 * 将invoker包装成一个服务接口的代理对象实例
 *
 * @param invoker 服务引入invoker
 * @param interfaces 服务接口
 * @return 服务接口的代理对象实例
 * @param <T>
 */
@Override
@SuppressWarnings("unchecked")
public <T> T getProxy(Invoker<T> invoker, Class<?>[] interfaces) {
    try {
        //基于Javassist创建给定接口的代理对象，调用处理器为InvokerInvocationHandler，内部封装了invoker的调用
        return (T) Proxy.getProxy(interfaces).newInstance(new InvokerInvocationHandler(invoker));
    } catch (Throwable fromJavassist) {
        // try fall back to JDK proxy factory
        try {
            //javassist创建失败之后，回退到基于jdk动态代理的方式创建代理对象
            T proxy = jdkProxyFactory.getProxy(invoker, interfaces);
            logger.error("Failed to generate proxy by Javassist failed. Fallback to use JDK proxy success. " +
                "Interfaces: " + Arrays.toString(interfaces), fromJavassist);
            return proxy;
        } catch (Throwable fromJdk) {
            logger.error("Failed to generate proxy by Javassist failed. Fallback to use JDK proxy is also failed. " +
                "Interfaces: " + Arrays.toString(interfaces) + " Javassist Error.", fromJavassist);
            logger.error("Failed to generate proxy by Javassist failed. Fallback to use JDK proxy is also failed. " +
                "Interfaces: " + Arrays.toString(interfaces) + " JDK Error.", fromJdk);
            throw fromJavassist;
        }
    }
}

4.2 InvokerInvocationHandler调用处理器

InvokerInvocationHandler实现了InvocationHandler接口，所有对于代理对象的方法调用最终都会被转发到InvokerInvocationHandler的invoke方法上来，在该方法中能够获取到调用的接口方法和参数等信息，这样就是依靠内部的invoker对于真实的服务提供者实现发起本地或者远程调用了。

具体的发起调用的源码，我们在后面讲consumer服务调用的时候再详细分析。

public class InvokerInvocationHandler implements InvocationHandler {
    private static final Logger logger = LoggerFactory.getLogger(InvokerInvocationHandler.class);

    private final Invoker<?> invoker;

    private final ServiceModel serviceModel;

    private final String protocolServiceKey;

    public InvokerInvocationHandler(Invoker<?> handler) {
        this.invoker = handler;
        //consumerUrl
        URL url = invoker.getUrl();
        //协议服务key，格式为 {group}/{serviceName}:{version}，例如greeting/org.apache.dubbo.demo.GreetingService:1.0.0
        this.protocolServiceKey = url.getProtocolServiceKey();
        this.serviceModel = url.getServiceModel();
    }

    /**
     * InvokerInvocationHandler的方法
     *
     * 执行代理对象的方法的转发
     *
     * @param proxy 在其上调用方法的代理实例
     *
     * @param method 在代理实例上调用的接口方法
     *
     * @param args 一个对象数组，包含在代理实例的方法调用中传递的参数值，如果接口方法不接受参数，则为null
     *
     * @return 调用代理对象方法执行结果
     */
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        //对于object类的方法，直接反射调用
        if (method.getDeclaringClass() == Object.class) {
            return method.invoke(invoker, args);
        }
        //获取方法名和方法参数类型数组
        String methodName = method.getName();
        Class<?>[] parameterTypes = method.getParameterTypes();
        //特殊方法的调用，直接调用invoker对象的同名方法
        if (parameterTypes.length == 0) {
            if ("toString".equals(methodName)) {
                return invoker.toString();
            } else if ("$destroy".equals(methodName)) {
                invoker.destroy();
                return null;
            } else if ("hashCode".equals(methodName)) {
                return invoker.hashCode();
            }
        } else if (parameterTypes.length == 1 && "equals".equals(methodName)) {
            return invoker.equals(args[0]);
        }
        //构建一个RpcInvocation作为接口方法调用抽象，包含方法名字，接口名，方法参数等信息
        RpcInvocation rpcInvocation = new RpcInvocation(serviceModel, method.getName(), invoker.getInterface().getName(), protocolServiceKey, method.getParameterTypes(), args);

        if (serviceModel instanceof ConsumerModel) {
            rpcInvocation.put(Constants.CONSUMER_MODEL, serviceModel);
            rpcInvocation.put(Constants.METHOD_MODEL, ((ConsumerModel) serviceModel).getMethodModel(method));
        }
        //通过InvocationUtil.invoke方法来发起真正的远程or本地调用
        return InvocationUtil.invoke(invoker, rpcInvocation);
    }
}

5 总结

本次我们学习了Dubbo3.1版本的服务引入的总体流程，现在简单总结下：

首先是Dubbo服务引入的入口，在Dubbo 3.1中，它位于监听器DubboDeployApplicationListener#onApplicationEvent方法中，在spring容器启动的最后一个步也就是refresh方法内部最后的finishRefresh方法中，将会向所有监听器发布一个ContextRefreshedEvent事件，表示容器刷新完毕，此时就会触发这个方法的调用。在Dubbo3.1中，默认启动项目就会进行服务引入，即饿汉式。
onApplicationEvent方法内部通过DefaultModuleDeployer#start方法开启服务的导出、引用等操作，最终在startSync方法内部的referServices方法中，将会获取全部的dubbo服务引入bean实例ReferenceConfig，然后依次进行服务引入。
服务引入的全流程在ReferenceConfig#createProxy方法中，该方法首先尝试创建invoker，也就是进行服务引入的逻辑。
1. 服务引入分为本地引入和远程引入，本地引入的invoker内部不需要创建netty客户端，因为不会发送网络请求，而是直接调用本服务的接口，远程引入则会创建netty客户端，用以发送rpc请求。
2. 对于远程引入，获取的是MigrationInvoker可迁移Invoker，用于dubbo2.x和dubbo3.x之间的接口级别和应用级别的服务发现迁移。
3. 创建MigrationInvoker并没有真正涉及到服务的引入**，在interceptInvoker方法中，该方法将会对invoker应用MigrationRuleListener#onRefer方法，该方法才是真正的服务引入入口，MigrationRuleListener以及真正的服务引入的逻辑，我们后面学习。**
然后调用sproxyFactory#getProxy方法根据invoker创建一个服务接口代理对象返回，默认基于Javassist的代理。这样就完成了服务的引入。

后面我们将会继续学习MigrationRuleListener#onRefer方法，该方法才是真正的服务引入入口，MigrationRuleListener以及真正的服务引入的逻辑，以及服务迁移到底是个什么东西？我们后面学习。

标签：Dubbo,服务,21,url,源码,registry,方法,invoker
From： https://blog.csdn.net/weixin_43767015/article/details/139562324