一、几个问题
- 生产者暴露和消费者的引用是怎么触发的?
- 消费者引用的服务提供者在同一个应用中,dubbo是如何避免跨网络通信的?
- 核心:服务暴露
- 服务实例是如何变成一个远程服务的?
- 服务暴露涉及的核心API,ServiceConfig、Protocol、ProxyFactory,这些API在服务暴露过程中作用?
- 核心:服务引用
- 何时与服务端建立连接?
- 除了监听注册中心的服务提供者列表,还有监听其他内容的节点吗?
- 服务提供者发生变更时,消费端是如何刷新提供者列表的?刷新时存在什么问题?
- 服务引用涉及的核心API,ReferenceConfig、Protocol、ProxyFactory、RegistryDirectory,这些API在服用引用过程中的作用?
二、开局的两张图
1、服务暴露与引用核心流程图
(从上图可以看出服务的暴露和引用是逆向的两个流程,核心就是URL<——>Invoker<T><——>Instance<T>的转换。)
2、服务暴露与引用脑图。
(Dubbo源码分析版本基于2.7.3版本,在2.7.5之后服务的暴露与引用的触发方式略有不同,不过核心流程是相同的。)
三、源码分析
3.1 服务暴露核心代码流程
1、ContextRefreshedEvent事件触发ServiceBean#export -> ServiceConfig#doExport-> ServiceConfig#doExportUrls->ServiceConfig#doExportUrlsFor1Protocol
// ServiceBean<T> 来源:
// 1、XML配置解析标签<dubbo:service...
// 2、Spring注解扫描org.apache.dubbo.config.annotation.Service(2.7.7及之后升级为@DubboService)
// 3、API创建即手动new 创建
@Override
public void onApplicationEvent(ContextRefreshedEvent event) {
if (!isExported() && !isUnexported()) {
if (logger.isInfoEnabled()) {
logger.info("The service ready on spring started. service: " + getInterface());
}
// 服务暴露核心方法
export();
}
}
// 调用父类方法ServiceConfig#export
public synchronized void export() {
checkAndUpdateSubConfigs();
if (!shouldExport()) {
return;
}
// 延迟暴露
if (shouldDelay()) {
DELAY_EXPORT_EXECUTOR.schedule(this::doExport, getDelay(), TimeUnit.MILLISECONDS);
} else {
// 进行暴露
doExport();
}
}
// doExport 方法核心调用
private void doExportUrls() {
// 加载注册中心
List<URL> registryURLs = loadRegistries(true);
// 多个协议暴露,进行遍历
for (ProtocolConfig protocolConfig : protocols) {
String pathKey = URL.buildKey(getContextPath(protocolConfig).map(p -> p + "/" + path).orElse(path), group, version);
ProviderModel providerModel = new ProviderModel(pathKey, ref, interfaceClass);
ApplicationModel.initProviderModel(pathKey, providerModel);
// 以固定协议暴露到多个注册中心(如果存在多个的话)
doExportUrlsFor1Protocol(protocolConfig, registryURLs);
}
}
2、服务暴露,ServiceConfig#doExportUrlsFor1Protocol,主要进行本地服务暴露与远程服务暴露。(本地服务暴露,避免了本地引用的跨服务器调用的问题)
// 类:ServiceConfig
private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) {
.....
// 省略代码包含是否进行服务暴露、是否只暴露远程服务的判断
exportLocal(url);
}
// 暴露本地服务
private void exportLocal(URL url) {
URL local = URLBuilder.from(url)
// 修改协议为本地协议:injvm
.setProtocol(LOCAL_PROTOCOL)
.setHost(LOCALHOST_VALUE)
.setPort(0)
.build();
// SPI 适配到InjvmProtocol#export
Exporter<?> exporter = protocol.export(
// PROXY_FACTORY.getInvoker 将实例转换为Invoker
PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, local));
exporters.add(exporter);
logger.info("Export dubbo service " + interfaceClass.getName() + " to local registry url : " + local);
}
Dubbo远程服务暴露源码,主要是注册中心暴露方式与非注册中心,直接通过协议暴露。
// ServiceConfig#doExportUrlsFor1Protocol 远程服务暴露部分
// registryURLs 不为空,暴露服务到注册中心
if (CollectionUtils.isNotEmpty(registryURLs)) {
// 遍历暴露到多注册中心
for (URL registryURL : registryURLs) {
// 省略了关于监控部分内容
// 通过代理工厂ProxyFactory将实例转换为Invoker,底层默认使用的Javassit,
//
// 简单理解,ProxyFactory生成的代理Invoker,是在RPC调用请求过来,
// 通过请求信息中的,方法名称、参数类型、返回值等,匹配到ref对应的方法。
Invoker<?> invoker = PROXY_FACTORY.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(EXPORT_KEY, url.toFullString()));
// 包转操作,主要保存invoker和ServiceConfig之间的关系,类很简单
DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);
// 协议暴露,通过SPI匹配到具体的协议,见下一代码块儿(核心内容)!!!!
Exporter<?> exporter = protocol.export(w