dubbo-common-rpc

ApplicationModel 实例模型.

1.init 会通过 SPI 机制加载 ApplicationInitListener，调用其 init 方法.
2.initFrameworkExts 通过 SPI 机制加载 FrameworkExt 的扩展实现.
3.获取 ConsumerModel & ProviderModel.
4.Environment、ConfigManager、ServiceRepository.

我理解的 ApplicantModel 模型最重要的属性就是 Environment、ConfigManager、ServiceRepository 这三个. 分别代表环境(properties)、抽象配置(AbstractConfig)、ServiceRepository(服务仓库，包含提供者和消费者).


Lifecycle dubbo 组件的生命周期. initialize、start、destroy. 生命周期也就这三个方法了.

LifecycleAdapter 适配器. 空实现.

FrameworkExt 标记接口，框架扩展.

ServiceRepository 保存 providerModel、consumerModel 等数据.

    // 我的理解是，一个服务可以被多个提供者提供，被多个消费者消费，服务关注的是基本属性，比如接口名，包含的方法，而 provider 更多的是关注
    // 的是其自身的配置，比如超时时间等. 这么说，服务是基础，而提供者基于服务做各种限制.
    // services
    private ConcurrentMap<String, ServiceDescriptor> services = new ConcurrentHashMap<>();


    // consumers
    private ConcurrentMap<String, ConsumerModel> consumers = new ConcurrentHashMap<>();


    // providers
    private ConcurrentMap<String, ProviderModel> providers = new ConcurrentHashMap<>();


    // useful to find a provider model quickly with serviceInterfaceName:version
    private ConcurrentMap<String, ProviderModel> providersWithoutGroup = new ConcurrentHashMap<>();

所以 ServiceRepository 最核心的几个方法：

public ServiceDescriptor registerService(Class<?> interfaceClazz);


public void registerConsumer(String serviceKey,
                                 ServiceDescriptor serviceDescriptor,
                                 ReferenceConfigBase<?> rc,
                                 Object proxy,
                                 ServiceMetadata serviceMetadata);


public void registerProvider(String serviceKey,
                                 Object serviceInstance,
                                 ServiceDescriptor serviceModel,
                                 ServiceConfigBase<?> serviceConfig,
                                 ServiceMetadata serviceMetadata);

ServiceDescriptor 关注内容(serviceName、method)：

    private final String serviceName;
    private final Class<?> serviceInterfaceClass;
    // to accelerate search
    private final Map<String, List<MethodDescriptor>> methods = new HashMap<>();
    private final Map<String, Map<String, MethodDescriptor>> descToMethods = new HashMap<>();

ServiceMetadata 服务元数据，关注 defaultGroup、serviceType、target、attachments、attributeMap. 在语义上 ServiceMetadata 和 ServiceDescriptor 含义接近，都是描述服务的. 不同的是 ServiceDescriptor 更纯粹，而 ServiceMetadata 包含了一些额外的信息，例如 group、attachments 等属性.

ConsumerModel 关注内容(serviceDescriptor、referenceConfig、proxy):

    // interfaceName + group + version
    private String serviceKey;
    private final ServiceDescriptor serviceModel;
    private final ReferenceConfigBase<?> referenceConfig;
    private final Set<String> apps = new TreeSet<>();


    private Object proxyObject;


    private Map<String, AsyncMethodInfo> methodConfigs = new HashMap<>();

ProviderModel 关注内容(serviceKey、serviceInstance、serviceDescriptor、serviceConfig、urls)

ProviderModel 和 ConsumerModel 的共同点在于都会持有 serviceKey、serviceDescriptor、AbstractConfig. 持有 AbstractConfig 的原因在于从中获取提供者或消费者的配置属性.


ConfigManager 持有 AbstractConfig 的配置信息. 实现 FrameworkExt 接口，说明其以后会被 SPI 机制加载. 主要处理的都是 AbstractConfig 类型的配置，例如 consumerConfig、providerConfig 等.

Environment 环境持有者，包含 propertiesConfiguration、systemConfiguration、environmentConfiguration、externalConfiguration、appExternalConfiguration. 详情参考配置中心.

AsyncMethodInfo 异步信息，主要是包含一些扩展点，比如在执行前返回等.

// callback instance when async-call is invoked
    private Object oninvokeInstance;


    // callback method when async-call is invoked
    private Method oninvokeMethod;


    // callback instance when async-call is returned
    private Object onreturnInstance;


    // callback method when async-call is returned
    private Method onreturnMethod;


    // callback instance when async-call has exception thrown
    private Object onthrowInstance;


    // callback method when async-call has exception thrown
    private Method onthrowMethod;

有一个比较混乱的问题：serviceKey 的组成很混乱.

1.GroupServiceKeyCache.createServiceKey -> group/serviceName:serviceVersion:port
2.BaseServiceMetadata.buildServiceKey -> group/serviceName:serviceVersion

是否应该统一下？