Dubbo源码—1.服务发布的主要流程
大纲1.Dubbo 2.7和3.x版本的区别
2.Dubbo服务的基本流程和启动入口
3.Dubbo服务发布的主流程
4.服务发布时执行相关组件的初始化
5.服务发布时执行的服务实例刷新操作
6.服务发布时执行的服务实例初始化操作
7.服务发布时执行的服务实例发布操作
8.执行服务实例发布操作时的主流程
9.服务发布过程中ProxyFactory生成Invoker
10.服务发布过程中Protocol组件发布Invoker
11.服务发布过程中NettyServer的构造流程
12.服务发布过程中RegistryProtocol的服务注册
13.Dubbo服务发布的完整流程总结
1.Dubbo 2.7和3.x版本的区别
区别一：后者引入了ModuleDeployer组件专门做服务启动时的初始化工作。将原来的注册中心拆分为三大中心：注册中心、配置中心、元数据中心。
区别二：后者很多地方使用了Double Check来代替前者对方法加Synchronized锁，大量采用了Double Check + Volatile + Static来实现单例模式。
区别三：后者引入了MigrationRuleListener、MigrationRuleHandler、MigrationInvoker，引入DynamicDirectory代替RegistryDirectory。
2.Dubbo服务的基本流程和启动入口
(1)Dubbo服务的基本流程
(2)Provider启动入口
(3)Consumer启动入口
(1)Dubbo服务的基本流程
(2)Provider启动入口
public class Application {
public static void main(String[] args) throws Exception {
//Service和ServiceConfig是什么
//Service是一个服务，每个服务可能会包含多个接口
//ServiceConfig便是针对这个服务的一些配置
//下面传入的泛型DemoServiceImpl便是服务接口的实现
ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
//设置服务暴露出去的接口
service.setInterface(DemoService.class);
//设置暴露出去的接口的实现类
service.setRef(new DemoServiceImpl());
//服务名称，可以在服务框架里进行定位
service.setApplication(new ApplicationConfig("dubbo-demo-api-provider"));
//所有的RPC框架，必须要和注册中心配合使用，服务启动后必须向注册中心进行注册
//注册中心可以知道每个服务有几个实例，每个实例在哪台服务器上
//进行服务调用时，要先找注册中心咨询要调用的服务有几个实例，分别都在什么机器上
//下面便是设置ZooKeeper作为注册中心的地址
service.setRegistry(new RegistryConfig("zookeeper://127.0.0.1:2181"));
//设置元数据上报的地方
//Dubbo服务实例启动后，会有自己的元数据，需要上报到一个地方进行管理，比如zookeeper
service.setMetadataReportConfig(new MetadataReportConfig("zookeeper://127.0.0.1:2181"));
//配置完毕后，调用ServiceConfig的export()方法启动网络监听程序
//当接收到调用请求时，该网络监听程序会建立网络连接进行通信
//接收按照协议封装的请求数据，该网络监听程序会执行RPC调用
//此外，ServiceConfig的export()方法还会把自己作为一个服务实例注册到zk里
service.export();
System.out.println("dubbo service started");
new CountDownLatch(1).await();
}
}(3)Consumer启动入口
public class Application {
public static void main(String[] args) throws Exception {
//Reference和ReferenceConfig是什么
//Reference是一个引用，是对Provider端的一个服务实例的引用
//ReferenceConfig这个服务实例的引用的一些配置
//通过泛型传递了这个服务实例对外暴露的接口
ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
//设置应用名称
reference.setApplication(new ApplicationConfig("dubbo-demo-api-consumer"));
//设置注册中心的地址，默认是ZooKeeper
reference.setRegistry(new RegistryConfig("zookeeper://127.0.0.1:2181"));
//设置元数据上报地址
reference.setMetadataReportConfig(new MetadataReportConfig("zookeeper://127.0.0.1:2181"));
//设置要调用的服务的接口
reference.setInterface(DemoService.class);
//直接通过ReferenceConfig的get()方法来拿到一个DemoService接口
//它是一个动态代理接口，只要被调用，便会通过底层调用Provider服务实例的对应接口
DemoService service = reference.get();
String message = service.sayHello("dubbo");
System.out.println(message);
Thread.sleep(10000000L);
}
}
3.Dubbo服务发布的主流程
ServiceConfig的export()方法在进行服务发布时，首先会初始化相关组件，然后刷新服务实例，接着初始化服务实例，最后发布服务实例。
public class ServiceConfig<T> extends ServiceConfigBase<T> {
...
@Override
public void export() {
if (this.exported) {
return;
}
//prepare for export
//对比Dubbo 2.6.x和2.7.x源码，Dubbo 3.0的变动还是有点大的，比如这里使用了ModuleDeployer组件
//Dubbo服务实例内部会有很多的代码组件，通过ModuleDeployer便可以避免零零散散的去调用和初始化
//1.执行相关组件的初始化
//通过获取到的ModuleDeployer来对相关组件进行初始化
//比如会对MetadataReport元数据上报组件进行构建和初始化，以及启动(建立跟zk的连接)
getScopeModel().getDeployer().start();
synchronized (this) {
if (this.exported) {
return;
}
//2.执行服务实例的刷新操作
//也就是刷新ProviderConfig->MethodConfig->ArgumentConfig
if (!this.isRefreshed()) {
this.refresh();
}
if (this.shouldExport()) {
//3.执行服务实例的初始化
//也就是会把Metadata元数据给准备好，后续可以进行元数据上报
this.init();
//这是Dubbo服务实例的延迟发布的特性
//如果设置了Dubbo服务实例是延迟发布的，当调用了export()方法后，就会进入这里
//在延迟指定的时间后，再去进行服务的发布
if (shouldDelay()) {
//延迟发布
doDelayExport();
} else {
//立即发布
//4.执行服务实例的发布
//这里可以作为服务发布的直接入口
doExport();
}
}
}
}
...
}
4.服务发布时执行相关组件的初始化
public class DefaultModuleDeployer extends AbstractDeployer<ModuleModel> implements ModuleDeployer {
//已经完成发布的服务实例集合
private List<ServiceConfigBase<?>> exportedServices = new ArrayList<>();
//下面这些组件，本身都是跟model组件体系强关联的
private ModuleModel moduleModel;
//父级ApplicationDeployer组件
private ApplicationDeployer applicationDeployer;
...
@Override
public Future start() throws IllegalStateException {
//initialize，maybe deadlock applicationDeployer lock & moduleDeployer lock
//调用DefaultApplicationDeployer的initialize()方法
applicationDeployer.initialize();
return startSync();
}
@Override
public void prepare() {
//module这个层级是application层级的下层
//application层级是framework层级的下层
applicationDeployer.initialize();
this.initialize();
}
...
}
public class DefaultApplicationDeployer extends AbstractDeployer implements ApplicationDeployer {
private final DubboShutdownHook dubboShutdownHook;
...
@Override
public void initialize() {
if (initialized) {
return;
}
//ApplicationDeployer组件，可能会被多线程并发访问
//Ensure that the initialization is completed when concurrent calls
synchronized (startLock) {
if (initialized) {
return;
}
//注册退出时需要进行资源销毁的ShutdownHook
//register shutdown hook
registerShutdownHook();
//启动配置中心ConfigCenter
//动配置中心是专门存放配置信息的
startConfigCenter();
//加载应用配置
loadApplicationConfigs();
//初始化ModuleDeployer
initModuleDeployers();
//启动元数据中心MetadataCenter
//元数据中心是专门存放发布d的服务实例信息的
startMetadataCenter();
initialized = true;
if (logger.isInfoEnabled()) {
logger.info(getIdentifier() + " has been initialized!");
}
}
//老的Dubbo版本只有注册中心的概念
//后来随着版本的迭代和演进，出现了配置中心、元数据中心等这些用于解耦的概念
//虽然Dubbo的服务实例信息、配置信息、元数据信息，都可以放在zk里
//但如果把一个服务实例的各种数据和信息都存储在zk里，那么这些数据和信息会严重耦合在一起
//下面从扩展性和可用性两个层面来分析，如果把各种数据都耦合放在一个zk里可能会出现的问题
//(1)扩展性
//在一个大规模的微服务系统里，服务本身可能都有上百个，服务实例可能有几百上千个，所以服务实例数据可能就很多
//但每个服务实例关联的配置数据，可能不是太多，尤其是元数据可能也不是太多
//而这里的扩展性不是指功能上的扩展，而是指数据上的扩展
//随着服务实例数据在膨胀，配置数据和元数据虽然可能也在增加，但是增加的速度可能比不上服务实例数据
//此时就需要对注册中心进行扩容或者更换一个系统去存储
//而在这个过程之中，由于所有数据耦合在一起了，牵一发而动全身，不好扩展了
//这就是多种不同类型的数据耦合在一起时会出现的痛点，也就是数据耦合导致数据扩展性差的问题
//(2)可用性
//由于注册数据、配置数据、元数据都放在一个地方比如zk
//那么一旦zk出现了故障，这三种数据就一起没了，这就是可用性问题
//因此，Dubbo3的架构设计会对不同类型的数据进行分离，形成了三种数据：注册数据、元数据、配置数据
//于是就有了三大中心：注册中心、配置中心、元数据中心，这样就可以把三种不同类型的数据，放到不同的地方去
//在扩展性方面，当服务实例数据太多时要进行扩容或者切换存储技术，此时对另外两种数据是没有直接影响的
//在可用性方面，一旦作为注册中心的zk突然挂了，此时配置中心可能是Nacos，对它来说也没有直接影响的
}
private void registerShutdownHook() {
dubboShutdownHook.register();
}
...
}
6.服务发布时执行的服务实例初始化操作
public class DefaultApplicationDeployer extends AbstractDeployer implements ApplicationDeployer {
...
//启动元数据中心
private void startMetadataCenter() {
//先分析元数据中心是否需要用注册中心来做元数据中心
useRegistryAsMetadataCenterIfNecessary();
ApplicationConfig applicationConfig = getApplication();
//获取元数据类型metadataType
String metadataType = applicationConfig.getMetadataType();
//进行元数据的配置，里面包含了MetadataReport的配置
Collection<MetadataReportConfig> metadataReportConfigs = configManager.getMetadataConfigs();
if (CollectionUtils.isEmpty(metadataReportConfigs)) {
return;
}
//从applicationModel中获取一个BeanFactory
//再根据BeanFactory获取一个元数据上报组件的实例MetadataReportInstance
MetadataReportInstance metadataReportInstance = applicationModel.getBeanFactory().getBean(MetadataReportInstance.class);
List<MetadataReportConfig> validMetadataReportConfigs = new ArrayList<>(metadataReportConfigs.size());
for (MetadataReportConfig metadataReportConfig : metadataReportConfigs) {
ConfigValidationUtils.validateMetadataConfig(metadataReportConfig);
validMetadataReportConfigs.add(metadataReportConfig);
}
//对于唯一的一个MetadataReport，会在这里进行初始化
//把配置的metadataReport地址和config传递进init()方法进行初始化
metadataReportInstance.init(validMetadataReportConfigs);
if (!metadataReportInstance.inited()) {
throw new IllegalStateException(String.format("%s MetadataConfigs found, but none of them is valid.", metadataReportConfigs.size()));
}
//所以MetadataReport的启动
//其实就是根据配置去获取对应的BeanFactory，然后通过BeanFactory创建出对应的MetadataReport实例
//最后根据配置对元数据上报组件的实例MetadataReportInstance进行初始化
}
...
}
public class MetadataReportInstance implements Disposable {
...
public void init(List<MetadataReportConfig> metadataReportConfigs) {
if (!init.compareAndSet(false, true)) {
return;
}
this.metadataType = applicationModel.getApplicationConfigManager().getApplicationOrElseThrow().getMetadataType();
if (metadataType == null) {
this.metadataType = DEFAULT_METADATA_STORAGE_TYPE;
}
//在这里会通过SPI机制的adaptive自适应，生成一个代理类
//底层会通过自适应的机制，根据url里的参数去拿到对应的实现类，来调用它的方法
//如果使用zk作为元数据中心，那么拿到的应该是一个ZooKeeperMetadataReportFactory
MetadataReportFactory metadataReportFactory = applicationModel.getExtensionLoader(MetadataReportFactory.class).getAdaptiveExtension();
for (MetadataReportConfig metadataReportConfig : metadataReportConfigs) {
init(metadataReportConfig, metadataReportFactory);
}
}
private void init(MetadataReportConfig config, MetadataReportFactory metadataReportFactory) {
...
//这种url一般来说是针对zk的url地址
MetadataReport metadataReport = metadataReportFactory.getMetadataReport(url);
if (metadataReport != null) {
metadataReports.put(relatedRegistryId, metadataReport);
}
}
...
}
public abstract class AbstractMetadataReportFactory implements MetadataReportFactory {
...
@Override
public MetadataReport getMetadataReport(URL url) {
...
metadataReport = createMetadataReport(url);
...
}
protected abstract MetadataReport createMetadataReport(URL url);
...
}
public class ZookeeperMetadataReportFactory extends AbstractMetadataReportFactory {
...
@Override
public MetadataReport createMetadataReport(URL url) {
return new ZookeeperMetadataReport(url, zookeeperTransporter);
}
...
}
public class ZookeeperMetadataReport extends AbstractMetadataReport {
private final String root;
ZookeeperClient zkClient;
...
public ZookeeperMetadataReport(URL url, ZookeeperTransporter zookeeperTransporter) {
super(url);
...
zkClient = zookeeperTransporter.connect(url);
}
...
}
7.服务发布时执行的服务实例发布操作
首先调用ServiceConfig的doExportUrls()方法发布服务，然后再调用其exported()方法进行服务发布后的处理，比如打印日志和回调监听器。
public class ServiceConfig<T> extends ServiceConfigBase<T> {
...
@Override
public void export() {
...
//1.执行相关组件的初始化
//通过获取到的ModuleDeployer来对相关组件进行初始化
//比如会对MetadataReport元数据上报组件进行构建和初始化，以及启动(建立跟zk的连接)
getScopeModel().getDeployer().start();
synchronized (this) {
if (this.exported) {
return;
}
//2.执行服务实例的刷新操作
//也就是刷新ProviderConfig->MethodConfig->ArgumentConfig
if (!this.isRefreshed()) {
//执行AbstractConfig的refresh()方法
this.refresh();
}
...
}
}
...
}
public abstract class AbstractConfig implements Serializable {
...
public void refresh() {
//check and init before do refresh
//调用AbstractConfig的子类ServiceConfigBase的preProcessRefresh()方法
//初始化一个ProviderConfig，也就是Provider服务实例
preProcessRefresh();
//Model组件体系对Dubbo的运行很关键，可以认为它是SPI机制使用的入口
//而ScopeModel是Model组件体系的一个基础，ScopeModel类型是可以转换为ModuleModel、ApplicationModel
//比如像ModuleServiceRepository、ModelEnvironment、BeanFactory等很多通用的组件都可以通过ScopeModel去获取
Environment environment = getScopeModel().getModelEnvironment();//获取Environment对象
List<Map<String, String>> configurationMaps = environment.getConfigurationMaps();
//Search props starts with PREFIX in order
//接下来要获取和拼接preferredPrefix
String preferredPrefix = null;
List<String> prefixes = getPrefixes();
for (String prefix : prefixes) {
if (ConfigurationUtils.hasSubProperties(configurationMaps, prefix)) {
preferredPrefix = prefix;
break;
}
}
if (preferredPrefix == null) {
preferredPrefix = prefixes.get(0);
}
...
//使用反射注入需要的方法
assignProperties(this, environment, subProperties, subPropsConfiguration);
//process extra refresh of subclass, e.g. refresh method configs
//调用AbstractInterfaceConfig的processExtraRefresh()方法
//该方法中preferredPrefix是关键，它的值可能是：dubbo.service.org.apache.dubbo.demo.DemoService
//其中dubbo.service代表dubbo服务名称的一个固定前缀，属于固定拼接的
//而中间的org.apache.dubbo.demo，则是从服务接口所在包名里截取出来的，并且最后会加上服务接口的接口名
//所以preferredPrefix会作为当前dubbo服务的全限定的名字
//而这段refresh的代码的作用，就是处理这个preferredPrefix以及其他相关的配置信息
processExtraRefresh(preferredPrefix, subPropsConfiguration);
postProcessRefresh();
refreshed.set(true);
}
protected void preProcessRefresh() {
// pre-process refresh
}
protected void processExtraRefresh(String preferredPrefix, InmemoryConfiguration subPropsConfiguration) {
// process extra refresh
}
protected void postProcessRefresh() {
// post-process refresh
checkDefault();
}
...
}
public abstract class AbstractInterfaceConfig extends AbstractMethodConfig {
private List<MethodConfig> methods;
...
//该方法会通过反射技术，对需要发布的服务的接口方法和参数封装成MethodConfig、ArgumentConfig
@Override
protected void processExtraRefresh(String preferredPrefix, InmemoryConfiguration subPropsConfiguration) {
if (StringUtils.hasText(interfaceName)) {
//通过反射技术获取需要发布的服务的接口
Class<?> interfaceClass;
interfaceClass = ClassUtils.forName(interfaceName);
...
//Auto create MethodConfig/ArgumentConfig according to config props
Map<String, String> configProperties = subPropsConfiguration.getProperties();
//获取需要发布的服务的接口的所有方法
Method[] methods;
methods = interfaceClass.getMethods();
//接下来对需要发布的服务的接口方法进行处理
//整理出MethodConfig对象及其对应的ArgumentConfig对象
//接口里的每个方法都要创建一个MethodConfig
//方法里的每一个参数都要创建一个ArgumentConfig
for (Method method : methods) {
//因为服务端每次处理客户端调用时，不可能都通过反射来获取method和args的情况
//所以在刚开始启动时就需要对接口进行解析，将所有的method和args整理到methods属性中
if (ConfigurationUtils.hasSubProperties(configProperties, method.getName())) {
MethodConfig methodConfig = getMethodByName(method.getName());
//Add method config if not found
if (methodConfig == null) {
//需要发布的的服务的每个方法，都创建一个MethodConfig对象
methodConfig = new MethodConfig();
methodConfig.setName(method.getName());
//将MethodConfig对象添加到methods属性中
this.addMethod(methodConfig);
}
//Add argument config
//dubbo.service.{interfaceName}.{methodName}.{arg-index}.xxx=xxx
java.lang.reflect.Parameter[] arguments = method.getParameters();
for (int i = 0; i < arguments.length; i++) {
if (getArgumentByIndex(methodConfig, i) == null && hasArgumentConfigProps(configProperties, methodConfig.getName(), i)) {
//方法里的每个args参数，都创建一个ArgumentConfig对象
ArgumentConfig argumentConfig = new ArgumentConfig();
argumentConfig.setIndex(i);
//将ArgumentConfig对象添加到MethodConfig对象中
methodConfig.addArgument(argumentConfig);
}
}
}
}
//refresh MethodConfigs，刷新刚才解析出来的MethodConfig对象
List<MethodConfig> methodConfigs = this.getMethods();
if (methodConfigs != null && methodConfigs.size() > 0) {
//whether ignore invalid method config
Object ignoreInvalidMethodConfigVal = getEnvironment().getConfiguration()
.getProperty(ConfigKeys.DUBBO_CONFIG_IGNORE_INVALID_METHOD_CONFIG, "false");
boolean ignoreInvalidMethodConfig = Boolean.parseBoolean(ignoreInvalidMethodConfigVal.toString());
Class<?> finalInterfaceClass = interfaceClass;
List<MethodConfig> validMethodConfigs = methodConfigs.stream().filter(methodConfig -> {
methodConfig.setParentPrefix(preferredPrefix);
//关联Model组件
methodConfig.setScopeModel(getScopeModel());
methodConfig.refresh();
//verify method config
return verifyMethodConfig(methodConfig, finalInterfaceClass, ignoreInvalidMethodConfig);
}).collect(Collectors.toList());
this.setMethods(validMethodConfigs);
}
}
}
public void addMethod(MethodConfig methodConfig) {
if (this.methods == null) {
this.methods = new ArrayList<>();
}
this.methods.add(methodConfig);
}
...
}
8.执行服务实例发布操作时的主流程
首先通过ScopeModel组件体系获取服务数据存储组件，然后将要发布的服务注册到服务数据存储组件里，接着把相关信息封装成一个服务提供者，并将该服务提供者也注册到服务数据存储组件中，然后生成注册的URL，最后根据协议和生成的注册的URL来发布服务。
public class ServiceConfig<T> extends ServiceConfigBase<T> {
...
@Override
public void export() {
...
synchronized (this) {
...
if (this.shouldExport()) {
//3.执行服务实例的初始化
//也就是会把Metadata元数据给准备好，后续可以进行元数据上报
this.init();
...
}
}
}
public void init() {
//通过SPI机制获取ServiceListener扩展点的所有实现类实例
//然后添加到ServiceConfig的serviceListeners字段里
if (this.initialized.compareAndSet(false, true)) {
//load ServiceListeners from extension
ExtensionLoader<ServiceListener> extensionLoader = this.getExtensionLoader(ServiceListener.class);
this.serviceListeners.addAll(extensionLoader.getSupportedExtensionInstances());
}
//初始化ServiceMetadata，也就是服务元数据
//这需要与前面设置的MetadataCenter元数据中心配合起来看
//ServiceMetadata作为服务实例的元数据，会对服务实例做一些描述，比如版本号、实现类等
initServiceMetadata(provider);
serviceMetadata.setServiceType(getInterfaceClass());
serviceMetadata.setTarget(getRef());
serviceMetadata.generateServiceKey();
}
...
}
9.服务发布过程中ProxyFactory生成Invoker
public class ServiceConfig<T> extends ServiceConfigBase<T> {
...
@Override
public void export() {
...
//4.执行服务实例的发布
//进行debug时，可以通过控制台打印的日志去分析运行流程
//比如通过log日志可以发现服务发布的流程可能涉及：
//一.export Dubbo Service，发布dubbo服务实例
//二.register Dubbo Service，往zk进行注册
//三.启动NettyServer，监听端口和请求处理
//四.服务发现注册
//五.MetadataReport：服务实例上报
//六.关闭JVM时的逆向处理过程
//这里可以作为一个服务发布的直接入口
doExport();
}
protected synchronized void doExport() {
...
//发布服务
doExportUrls();
//服务发布完成后的处理，比如打印日志和回调监听器
exported();
}
...
}
10.服务发布过程中Protocol组件发布Invoker
(1)Protocol协议接口
(2)Protocol组件发布Invoker
(1)Protocol协议接口
public class ServiceConfig<T> extends ServiceConfigBase<T> {
...
@SuppressWarnings({"unchecked", "rawtypes"})
private void doExportUrls() {
//所谓的ScopeModel，真实的类型是ModuleModel
//下面这行代码会通过AbstractMethodConfig的getScopeModel()方法获取ScopeModel
//接着会通过ModuleModel的getServiceRepository()方法去获取ServiceRepository
//事实上，Dubbo会把它的各个组件都集中在ScopeModel(ModuleModel)里，而ScopeModel就类似于设计模式里的门面模式
//ScopeModel、ModuleModel、ApplicationModel、FrameworkModel等多个Model会组成一个Model组件体系
//1.通过ScopeModel组件体系获取服务数据存储组件ModuleServiceRepository
ModuleServiceRepository repository = getScopeModel().getServiceRepository();
//ServiceRepository是Dubbo服务的数据存储组件
//一个系统可以发布多个Dubbo服务
//每个Dubbo服务的核心就是一个接口和一个实现类
//2.把当前要发布的服务注册到Dubbo的服务数据存储组件中
ServiceDescriptor serviceDescriptor;
final boolean serverService = ref instanceof ServerService;
if (serverService) {
serviceDescriptor = ((ServerService) ref).getServiceDescriptor();
repository.registerService(serviceDescriptor);
} else {
serviceDescriptor = repository.registerService(getInterfaceClass());
}
//ProviderModel也就是服务提供者，由于这里是暴露服务出去的，所以属于Provider
//3.把所有相关的信息封装成一个服务提供者ProviderModel
providerModel = new ProviderModel(
serviceMetadata.getServiceKey(),
ref,//ref代表的是实际实现的类，通过泛型传入
serviceDescriptor,//表示服务实例相关的信息
getScopeModel(),
serviceMetadata,
interfaceClassLoader
);
providerModel.setConfig(this);
providerModel.setDestroyRunner(getDestroyRunner());
//3.将服务提供者ProviderModel注册到服务数据存储组件中
repository.registerProvider(providerModel);
//4.生成注册的URL：包含2181的端口号、注册到zk中
//service-discovery-registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=989®istry=zookeeper×tamp=1724302222103 //registry://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=dubbo-demo-api-provider&dubbo=2.0.2&pid=989®istry=zookeeper×tamp=1724302222103
List<URL> registryURLs = ConfigValidationUtils.loadRegistries(this, true);
for (ProtocolConfig protocolConfig : protocols) {
String pathKey = URL.buildKey(
getContextPath(protocolConfig).map(p -> p + "/" + path).orElse(path),
group,
version
);
//stub service will use generated service name
if (!serverService) {
//In case user specified path, register service one more time to map it to path.
//将接口注册到服务数据存储组件中
repository.registerService(pathKey, interfaceClass);
}
//5.调用doExportUrlsFor1Protocol()方法，根据协议和注册的URL来发布服务
doExportUrlsFor1Protocol(protocolConfig, registryURLs);
}
providerModel.setServiceUrls(urls);
}
private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
Map<String, String> map = buildAttributes(protocolConfig);
//remove null key and null value
map.keySet().removeIf(key -> StringUtils.isEmpty(key) || StringUtils.isEmpty(map.get(key)));
//init serviceMetadata attachments
//将map数据放入serviceMetadata中，这与元数据相关
serviceMetadata.getAttachments().putAll(map);
//根据ProtocolConfig构建URL
URL url = buildUrl(protocolConfig, map);
//发布服务
exportUrl(url, registryURLs);
}
...
}
//ScopeModel、ModuleModel、ApplicationModel、FrameworkModel等多个Model会组成一个Model组件体系
public class ModuleModel extends ScopeModel {
public static final String NAME = "ModuleModel";
//ApplicationModel内部封装了其他很多组件，在这里是一个引用关系，通过构造方法传入进来
private final ApplicationModel applicationModel;
//包含了ServiceModule环境相关的数据，里面封装的都是各种各样的配置信息
private ModuleEnvironment moduleEnvironment;
//serviceRepository是一个服务仓储组件，存储了一些服务相关的数据
private ModuleServiceRepository serviceRepository;
//这是module配置管理器，用于存放一些服务相关的配置数据
private ModuleConfigManager moduleConfigManager;
//这是ModuleDeployer组件，用于管理其他的一些组件和模块的生命周期
private ModuleDeployer deployer;
...
}
public class ApplicationModel extends ScopeModel {
...
//包含了多个ModuleModel
private final List<ModuleModel> moduleModels = new CopyOnWriteArrayList<>();
private final List<ModuleModel> pubModuleModels = new CopyOnWriteArrayList<>();
//环境变量、配置信息
private Environment environment;
//服务配置相关的一些信息
private ConfigManager configManager;
//服务数据相关的一些存储
private ServiceRepository serviceRepository;
//属于application层级的一些组件的生命周期管理
private ApplicationDeployer deployer;
//父级组件
private final FrameworkModel frameworkModel;
//内部的一个ModuleModel组件
private ModuleModel internalModule;
//默认的一个ModuleModel组件
private volatile ModuleModel defaultModule;
//internal module index is 0, default module index is 1
private AtomicInteger moduleIndex = new AtomicInteger(0);
//是一个锁
private Object moduleLock = new Object();
...
}
public class FrameworkModel extends ScopeModel {
...
//它没有父层级了，所以只能通过static静态变量，类级别去引用自己的FrameworkModel集合
private static List<FrameworkModel> allInstances = new CopyOnWriteArrayList<>();
//包含了多个ApplicationModel
private List applicationModels = new CopyOnWriteArrayList<>();
//通过Framework、Application、Module各个层级都可以获取到service相关的配置和数据
private FrameworkServiceRepository serviceRepository;
...
}
public class ModuleServiceRepository {
private final ModuleModel moduleModel;
//services，代表服务相关的数据，StubServiceDescriptor
private final ConcurrentMap<String, List<ServiceDescriptor>> services = new ConcurrentHashMap<>();
//consumers(key - group/interface:version, value - consumerModel list)
//代表服务的调用方(consumer即消费方/调用方)
private final ConcurrentMap<String, List<ConsumerModel>> consumers = new ConcurrentHashMap<>();
//providers，代表服务提供方
private final ConcurrentMap<String, ProviderModel> providers = new ConcurrentHashMap<>();
//FrameworkServiceRepository存储的也是一些服务相关的数据
private final FrameworkServiceRepository frameworkServiceRepository;
...
}
public class ModuleServiceRepository {
//services，代表服务相关的数据，StubServiceDescriptor
private final ConcurrentMap<String, List<ServiceDescriptor>> services = new ConcurrentHashMap<>();
...
public ServiceDescriptor registerService(ServiceDescriptor serviceDescriptor) {
return registerService(serviceDescriptor.getServiceInterfaceClass(), serviceDescriptor);
}
public ServiceDescriptor registerService(Class<?> interfaceClazz) {
ServiceDescriptor serviceDescriptor = new ReflectionServiceDescriptor(interfaceClazz);
return registerService(interfaceClazz, serviceDescriptor);
}
public ServiceDescriptor registerService(Class<?> interfaceClazz, ServiceDescriptor serviceDescriptor) {
List<ServiceDescriptor> serviceDescriptors = services.computeIfAbsent(interfaceClazz.getName(), k -> new CopyOnWriteArrayList<>());
synchronized (serviceDescriptors) {
Optional<ServiceDescriptor> previous = serviceDescriptors.stream()
.filter(s -> s.getServiceInterfaceClass().equals(interfaceClazz)).findFirst();
if (previous.isPresent()) {
return previous.get();
} else {
serviceDescriptors.add(serviceDescriptor);
return serviceDescriptor;
}
}
}
...
}(2)Protocol组件发布Invoker
本地发布时使用InjvmProtocol + InjvmExporter，远程发布时使用RegistryProtocol + DestroyableExporter。
RegistryProtocol的export()方法被远程发布调用的时候，会调用到DubboProtocol的export()方法，并最终调用到HeaderExchanger的bind()方法执行NettyTransporter的bind()方法构建Netty服务器。
public class ServiceConfig<T> extends ServiceConfigBase<T> {
...
private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
Map<String, String> map = buildAttributes(protocolConfig);
//remove null key and null value
map.keySet().removeIf(key -> StringUtils.isEmpty(key) || StringUtils.isEmpty(map.get(key)));
//init serviceMetadata attachments
//将map数据放入serviceMetadata中，这与元数据相关
serviceMetadata.getAttachments().putAll(map);
//根据ProtocolConfig构建URL
URL url = buildUrl(protocolConfig, map);
//发布服务
exportUrl(url, registryURLs);
}
private URL buildUrl(ProtocolConfig protocolConfig, Map<String, String> params) {
//获取协议名称
String name = protocolConfig.getName();
if (StringUtils.isEmpty(name)) {
//默认使用Dubbo协议
name = DUBBO;
}
//获取host值
String host = findConfiguredHosts(protocolConfig, provider, params);
//获取port值
Integer port = findConfiguredPort(protocolConfig, provider, this.getExtensionLoader(Protocol.class), name, params);
//根据上面获取的host、port以及前文获取的map集合组装URL
URL url = new ServiceConfigURL(name, null, null, host, port, getContextPath(protocolConfig).map(p -> p + "/" + path).orElse(path), params);
//通过Configurator覆盖或添加新的参数
if (this.getExtensionLoader(ConfiguratorFactory.class).hasExtension(url.getProtocol())) {
url = this.getExtensionLoader(ConfiguratorFactory.class).getExtension(url.getProtocol()).getConfigurator(url).configure(url);
}
url = url.setScopeModel(getScopeModel());
url = url.setServiceModel(providerModel);
return url;
}
private void exportUrl(URL url, List<URL> registryURLs) {
//从URL中获取scope参数，其中可选值有none、remote、local三个，分别代表不发布、发布到本地以及发布到远端
String scope = url.getParameter(SCOPE_KEY);
//scope不为none，才进行发布
if (!SCOPE_NONE.equalsIgnoreCase(scope)) {
//scope为local，只发布到本地
if (!SCOPE_REMOTE.equalsIgnoreCase(scope)) {
exportLocal(url);
}
//export to remote if the config is not local (export to local only when config is local)
//scope为remote，发布到远端的注册中心
if (!SCOPE_LOCAL.equalsIgnoreCase(scope)) {
//进行远程发布
url = exportRemote(url, registryURLs);
if (!isGeneric(generic) && !getScopeModel().isInternal()) {
//通过MetadataUtils推送这个服务实例的元数据到元数据中心
//元数据中心是一个动态的配置中心，可以从里面获取参数，也可以添加监听器监听配置项的变更
MetadataUtils.publishServiceDefinition(url, providerModel.getServiceModel(), getApplicationModel());
}
}
}
this.urls.add(url);
}
private void exportLocal(URL url) {
//创建新URL
URL local = URLBuilder.from(url)
.setProtocol(LOCAL_PROTOCOL)
.setHost(LOCALHOST_VALUE)
.setPort(0)
.build();
local = local.setScopeModel(getScopeModel()).setServiceModel(providerModel);
//本地发布
doExportUrl(local, false);
//exportLocal，指的是发布到本地
//具体就是在jvm内部完成了组件之间的一些交互关系和发布
logger.info("Export dubbo service " + interfaceClass.getName() + " to local registry url : " + local);
}
private URL exportRemote(URL url, List<URL> registryURLs) {
//如果当前配置了至少一个注册中心
if (CollectionUtils.isNotEmpty(registryURLs)) {
//URL里有很多的信息，比如协议、各种参数等
//URL可以在后续代码运行过程中提供配置和信息
//接下来会向每个注册中心发布服务
for (URL registryURL : registryURLs) {
//registryURL.getProtocol()会获取协议
if (SERVICE_REGISTRY_PROTOCOL.equals(registryURL.getProtocol())) {
url = url.addParameterIfAbsent(SERVICE_NAME_MAPPING_KEY, "true");
}
//injvm协议只在exportLocal()中有用，不会将服务发布到注册中心，所以这里忽略injvm协议
if (LOCAL_PROTOCOL.equalsIgnoreCase(url.getProtocol())) {
continue;
}
//设置服务URL的dynamic参数
url = url.addParameterIfAbsent(DYNAMIC_KEY, registryURL.getParameter(DYNAMIC_KEY));
//创建monitorUrl，并作为monitor参数添加到服务URL中
URL monitorUrl = ConfigValidationUtils.loadMonitor(this, registryURL);
if (monitorUrl != null) {
url = url.putAttribute(MONITOR_KEY, monitorUrl);
}
//For providers, this is used to enable custom proxy to generate invoker
//设置服务URL的proxy参数，即生成动态代理方式(jdk或是javassist)，作为参数添加到RegistryURL中
String proxy = url.getParameter(PROXY_KEY);
if (StringUtils.isNotEmpty(proxy)) {
registryURL = registryURL.addParameter(PROXY_KEY, proxy);
}
doExportUrl(registryURL.putAttribute(EXPORT_KEY, url), true);
}
} else {
//不存在注册中心，仅发布服务，不会将服务信息发布到注册中心
doExportUrl(url, true);
}
return url;
}
private void doExportUrl(URL url, boolean withMetaData) {
//动态代理技术有很多种，比如cglib，jdk
//而动态代理就是：面向一个接口，动态生成该接口的一个实现类，然后根据这个实现类再动态生成对应的对象
//这个对象就是动态代理的对象，所以该对象会代理自己背后的一个实现类
//当这个对象被调用时，背后的实现类也会被调用
//ProxyFactory，Proxy就是动态代理
//下面传入的ref指的是实现类
//下面传入的interfaceClass指的是接口
//下面传入的url就是服务实例对外暴露出去的一些核心信息
//proxyFactory.getInvoker()获取到的是Invoker调用组件
//当Dubbo的NettyServer监听到网络连接进行请求处理时，需要有一个调用组件去根据请求进行调用
//Invoker调用组件可以认为是ProxyFactory基于DemoService接口生成的动态代理
//当需要根据请求调用接口时，底层就会回调自己写的实现类DemoServiceImpl
//proxyFactory.getInvoker()会封装一个AbstractProxyInvoker，对本地实现类进行代理
//默认情况下，会通过Javassist技术生成Wrapper，该Wrapper会将本地实现类包装进去
//调用AbstractProxyInvoker的invoke方法时，最终就会基于Javassist动态生成的Wrapper进行调用
//下面这一行代码是为服务实现类的对象创建相应的Invoker
//其中传入的服务url会作为export参数添加到RegistryURL中
//这里的proxyFactory就是ProxyFactory接口的适配器，会通过SPI机制进行初始化
//比如下面就会调用JavassistProxyFactory.getInvoker()方法
//proxyFactory.getInvoker()会获取到Invoker调用组件(生成Invoker动态代理)
//所以下面这一行代码会为本地实现类的对象创建相应的Invoker(封装着AbstractProxyInvoker)
Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, url);
if (withMetaData) {
//DelegateProviderMetaDataInvoker是个装饰类
//它会将当前ServiceConfig和Invoker关联起来
invoker = new DelegateProviderMetaDataInvoker(invoker, this);
}
//调用Protocol的实现进行发布，protocolSPI是Protocol接口的适配器
//进行本地发布时，使用的是InjvmProtocol + InjvmExporter
//进行远程发布时，使用的是RegistryProtocol，它会对DubboProtocol进行包装和装饰
//RegistryProtocol会先执行来处理服务注册的一些事情
//DubboProtocol会后执行来启动NettyServer网络服务器
Exporter<?> exporter = protocolSPI.export(invoker);
exporters.add(exporter);
}
...
}
public class JavassistProxyFactory extends AbstractProxyFactory {
...
@Override
public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) throws RpcException {
//下面会通过Wrapper创建一个包装类对象
//该对象是动态构建出来的，它属于Wrapper的一个子类，里面会拼接一个关键的方法invokeMethod()，拼接代码由javassist动态生成
final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type);
//下面会创建一个实现了AbstractProxyInvoker的匿名内部类
//其doInvoker()方法会直接委托给Wrapper对象的invokeMethod()方法
return new AbstractProxyInvoker<T>(proxy, type, url) {
@Override
protected Object doInvoke(T proxy, String methodName, Class<?>[] parameterTypes, Object[] arguments) throws Throwable {
//当AbstractProxyInvoker.invoke()方法被调用时，便会执行到这里
//这里会通过类似于JDK反射的技术，调用本地实现类如DemoServiceImpl.sayHello()
//这个wrapper对象是由javassist技术动态生成的，已经对本地实现类进行包装
//这个动态生成的wrapper对象会通过javassist技术自己特有的方法
//在invokerMethod()方法被调用时执行本地实现类的目标方法
return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments);
}
};
}
...
}
public abstract class AbstractProxyInvoker<T> implements Invoker<T> {
...
//当Netty Server接受到了请求后，经过解析就会知道是要调用什么
//然后会把解析出来的数据放入Invocation中，通过AbstractProxyInvoker的invoke()方法来进行调用
@Override
public Result invoke(Invocation invocation) throws RpcException {
...
//执行doInvoke()方法，调用业务实现
Object value = doInvoke(proxy, invocation.getMethodName(), invocation.getParameterTypes(), invocation.getArguments());
...
//将value值封装成CompletableFuture对象
CompletableFuture<Object> future = wrapWithFuture(value, invocation);
//再次转换，转换为CompletableFuture类型
CompletableFuture appResponseFuture = future.handle((obj, t) -> {
AppResponse result = new AppResponse(invocation);
...
//将CompletableFuture封装成AsyncRpcResult返回
return new AsyncRpcResult(appResponseFuture, invocation);
}
protected abstract Object doInvoke(T proxy, String methodName, Class<?>[] parameterTypes, Object[] arguments) throws Throwable;
...
}//-> Protocol$Adaptive.export()//-> ProtocolSerializationWrapper.export()//-> ProtocolFilterWrapper.export()//-> ProtocolListenerWrapper.export()//-> InjvmProtocol.export()public class InjvmProtocol extends AbstractProtocol implements Protocol { ... @Override publicExporter export(Invoker invoker) throws RpcException { return new InjvmExporter(invoker, invoker.getUrl().getServiceKey(), exporterMap); } ...}public class InjvmExporter extends AbstractExporter { private final String key; //这就是在JVM里存放了 private final Map> exporterMap; public DubboExporter(Invoker invoker, String key, Map
页:
[1]