怎么说呢，

学习目标

完成本章后你将能够：

• 完整绘制 ServiceBean 从 Spring 事件触发到 Netty Server 启动的全流程图；
• 说明为何 Dubbo 需要“双重暴露”；
• 阐述 RegistryProtocol 如何将“注册”与“暴露”串联；
• 解释 DubboProtocol.export 中创建 Netty Server 的详细步骤；
• 理解服务暴露各阶段的防御性编程设计。

痛点一这方面。复杂的生命周期难以追踪

Spring 容器启动、ServiceBean 注册、Netty Server 启动、ZK 注册，整个链路耦合度高，初学者往往难以把握各环节何时执行。其实，

. ServiceBean 部署全流程

从 Spring 事件到服务导出的完整链路

Spring容器启动生命周期：
┌──────────────────────────────────────────┐
│ ApplicationContext.refresh │
│ ↓ │
│ finishRefresh │
│ ↓ │
│ 广播 ContextRefreshedEvent │
│ ↓ │
│ ServiceBean.onApplicationEvent │ ← 入口
│ ↓ │
│ export │
│ ↓ │
│ doExport │
│ ↓ │
│ doExportUrls │
└──────────────────────────────────────────┘
// doExportUrls 内部细节
protected synchronized void doExport {
if throw new IllegalStateException;if return，exported = true;if ) path = interfaceName;doExportUrls;}
javascript // loadRegistries 示例
List registryURLs = loadRegistries;java // 对每个协议生成 URL 并导出到每个注册中心
for {
String pathKey = URL.buildKey(
getContextPath.map.orElse。group,version);说起来，providerModel.setServicePath;doExportUrlsFor1Protocol;}

. 双重暴露机制

为什么需要双暴露？

Dubbo Provider 至少需要在两个协议上暴露：

• injvm 协议同一 JVM 内调用无需走网络；
• dubbo 协议跨 JVM 调用走网络。其实，

痛点二的观点是。单一远程暴露导致本地调用性能下降。如果仅通过 dubbo:// 地址调用。同一应用内部 Controller → Dubbo 序列化 → Netty TCP → Netty Server → 反序列化，增加不必要的网络开销。老实说，

本地暴露 InjvmProtocol 模拟实现

public class InjvmProtocolSimulation extends AbstractProtocol {
private static final Map EXPORTER_MAP = new ConcurrentHashMap<>;
@Override public  Exporter export throws RpcException {
String key = serviceKey);InjvmExporter exporter = new InjvmExporter<>;EXPORTER_MAP.put;return exporter;}
@Override public  Invoker refer throws RpcException {
String key = serviceKey;Exporter exporter = EXPORTER_MAP.get;if throw new RpcException;return exporter.getInvoker;}


}


痛点三这方面。InjvmProtocol 的 Map 缓存易导致内存泄漏，需手动清理未使用的 Exporter。

远程暴露 DubboProtocol 模拟实现


public class DubboProtocolExportSimulation extends AbstractProtocol {
private final Map serverMap = new ConcurrentHashMap<>;private final Map;<="" exporter<> ="" exportermap="new" p="">

@Override public  Exporter} export throws RpcException {…话说回来，}

private void openServer {
String key = url.getAddress;老实说，// host:port
ExchangeServer server = serverMap.get;
if {
synchronized{
server=serverMap.get;if{
server=Exchangers.bind;serverMap.put;}
}
}
} 

private final ExchangeHandler requestHandler =
new ExchangeHandlerAdapter{
@Override public CompletableFuture

至于痛点四。Netty Server 启动失败常因端口被占用或配置错误，需要快速定位。

. RegistryProtocol——注册与暴露的桥梁 

职责划分与代码实现概览 

RegistryProtocol.export


public Exporter export throws RpcException {
URL registryUrl=getRegistryUrl;


Protocol protocol=getProtocol;// 包装层次

final ExporterChangeableWrapper exporter=
new ExporterChangeableWrapper(
protocol.export,originInvoker);

Registry registry=getRegistry;

final URL registeredProviderUrl=
getRegisteredProviderUrl);

registry.register;不过，// 写入 ZK

return exporter;}


痛点五这方面。Registry Protocol 与底层 Protocol 的层级混乱，导致调试时很难判断是哪一步出现异常。

注册到 ZK 的节点结构示例 


/dubbo/
└─ /com.example.GreetingService/
└─ /providers/
├─ dubbo%3A%2F%2F192..%3A20880%2F...?version=...
└─ dubbo%3A%2F%2F192..%3A20880%2F...?version=...



ZK 临时节点会在 Provider 下线后自动消失，Consumer 会收到变化通知。按理说，至于痛点六，ZK 节点方法过长或编码不一致导致 Consumer 无法正确订阅。

. 服务曝光完整时序图 


ServiceBean → ServiceConfig → RegistryProtocol → DubboProtocol → ZooKeeper


① onApplicationEvent
② export
③ doExportUrls
④ buildServiceUrl
⑤ create Invoker via ProxyFactory
⑥ RegistryProtocol.export
⑦ DubboProtocol.export
⑧ openServer // Netty bind
⑨ registry.register // ZK 临时节点创建
⑩ 返回 DubboExporter 与 RegistryExporter 合并结果

最终的观点是，RPC 服务可外部访问。
 

痛点七这方面。多步骤中任一步骤失败均可能导致服务不可用，但错误信息往往被包装成通用异常，难以定位根因。

. 本章 



阶段
关键类/方法
主要动作 &
常见问题排查要点 



Spring事件触发

ServiceBean
onApplicationEvent
检查是否已完成 context 初始化。若报错请检查 bean 定义是否有循环依赖。

doExport
ServiceConfig.doExport
确认 exported flag 未被误置为 true 或 false。

建立 URL
doExportUrlsFor1Protocol
URL 参数校验；如 anyhost=true、timeout 等是否符合预期。

创建 Invoker
proxyFactory.getInvoker
检查 ref 对象是否为 null 或未注入。

Registry 与 Protocol 分离


Netty Server 开启


ZK 注册节点写入











⚠️主要要点回顾：



- 服务导出需经历 Spring -> 配置裁剪 -> Invoker 创建 -> 本地+远程 暴露 -> ZK 注册 四个独立环节，每一步都可能是瓶颈。建议做法： - 在 debug 时逐步打印每个阶段的关键参数；建议做法： - 使用日志级别 TRACE 打印底层 Framework 日志，以便快速定位失败位置。



- 双重暴露保证同一 JVM 内调用零网络开销，但需。



- ZooKeeper 临时节点保证 Provider 下线后 Consumer 能及时感知。但方法过长或编码错误会导致订阅失效，需要统一编码规则和方法命名规范。



- 网络端口冲突是最常见的问题之一。请确保所有 Provider 同一地址下只开启一次 Netty Server，可通过 `isServer` 参数控制。



- 若发现 `RpcException` 包含 “No local service found” 或 “registry register failed”，先检查配置中的 `scope`、`remote` 参数还有 Zookeeper 节点权限设置是否正确。