本文档对 Jaws 框架中 Nacos 和 ZooKeeper 两种注册中心实现进行全方位比较。一、底层存储模型维度NacosZooKeeper数据模型扁平化服务模型serviceName group instances树形层级路径模型类似文件系统路径结构jaws/{path}作为 serviceNamegroup 来自 URL/jaws/{group}/{path}/server/{host:port}多层路径数据存储URL 参数全部存入 Instance 的metadataMapURL 完整字符串作为 ZK 节点的 databyte[]节点类型无区分instance 只有 ephemeral 属性区分AVAILABLE_SERVER和CLIENT两种节点类型ZK 路径层级见ZkUtils/jaws/{group}/{servicePath}/server/{host:port} ← 服务提供者 /jaws/{group}/{servicePath}/client/{host:port} ← 服务消费者Nacos 映射见NacosPathUtilsserviceName jaws/{path} group url.getGroup() instance metadata {protocol, path, ...所有URL参数}二、服务注册机制ZooKeeper先删后建注册前先removeNode清除可能残留的旧节点再createNode双节点父路径为PERSISTENT类型服务实例节点为EPHEMERAL类型会话断开自动删除数据载体节点 data 存储url.toFullStr()完整 URL 字符串Nacos直接注册调用namingService.registerInstance()即可无需先清理单实体只注册一个Instance对象设置ephemeraltrue, healthytrue数据载体URL 参数全部放入instance.metadata额外存储protocol和path核心区别ZK 依赖临时节点 会话心跳实现自动下线Nacos 依赖心跳 健康检查机制。三、服务订阅与发现机制ZooKeeper — CuratorCache 监听使用CuratorCache监听/server路径下的子节点变化监听NODE_CREATED/NODE_DELETED事件事件触发后重新getChildren获取全量子节点列表逐个getData解析 URL订阅时还会创建CLIENT临时节点消费者标记Nacos — EventListener 监听使用namingService.subscribe()注册EventListener收到NamingEvent后直接从中获取ListInstance全量实例列表从 metadata 中还原 protocol/path 构建 URL不创建额外的消费者节点核心区别ZK 是被动通知只告诉你节点变了需要自己去拉最新数据Nacos 是主动推送直接给你最新实例列表。四、断线重连机制ZooKeeper — 显式重连ZookeeperRegistry在构造时注册了ConnectionStateListenerif(connectionStateConnectionState.RECONNECTED){reRegisterServices();// 重新注册所有服务reSubscribeServices();// 重新订阅所有服务}因为 ZK 临时节点在会话断开后会丢失重连后必须手动恢复。Nacos — 无显式重连NacosRegistry没有连接状态监听。Nacos 客户端 SDK 内部处理了心跳和重连NamingService会自动维护注册状态。五、服务发现doDiscover维度NacosZooKeeperAPInamingService.getAllInstances(serviceName, group)curator.getChildren().forPath(parentPath)数据解析从 metadata 直接构建 URL逐个子节点getData读取 byte[] 再反序列化 URL容错metadata 无 protocol 时用 refUrl 兜底节点 data 解析失败时用节点名解析 host:port 兜底路径不存在Nacos SDK 内部处理需先checkExists再getChildren六、并发控制两者结构完全一致clientLockReentrantLock保护订阅/取消订阅操作serverLockReentrantLock保护注册/注销操作serviceListeners都是HashMapURL, MapNotifyListener, 具体监听器七、动态配置对比维度NacosDynamicConfigurationZookeeperDynamicConfiguration存储Nacos ConfigServicekey→dataIdgroup 固定为JAWS_CONFIGZK 节点路径/jaws/dynamic-config/{key}读写getConfig/publishConfiggetData/setData/create/delete监听NacosListener回调CuratorCache监听节点变化连接复用独立创建ConfigService与注册用 NamingService 不同实例独立创建CuratorFramework与注册用客户端不同实例删除配置removeConfigcurator.delete()八、Factory 创建对比维度NacosRegistryFactoryZookeeperRegistryFactory客户端NamingFactory.createNamingService(Properties)CuratorFrameworkFactory.builder().build()重试策略Nacos SDK 内部管理ExponentialBackoffRetry(1000, 3)显式配置认证username/password 放入 Propertiesdigest模式 ACL 认证超时CONFIG_LONG_POLL_TIMEOUTsessionTimeoutMsconnectionTimeoutMs分离九、总结特性NacosZooKeeper数据模型扁平面向服务注册设计通用协调服务健康检查服务端主动心跳检测会话超时 临时节点自动消失变更通知推送全量实例列表Watch 通知 客户端重新拉取重连恢复SDK 内部处理应用层无感应用层监听RECONNECTED手动恢复消费者感知不记录消费者信息创建 CLIENT 临时节点标记消费者配置中心原生 ConfigService 支持用节点 data 模拟需自建路径规范代码复杂度较低~183行API 更高级较高~267行需手动管理节点生命周期简而言之Nacos 实现更简洁因为 Nacos SDK 封装了更多服务注册的高层语义ZooKeeper 实现更底层需要手动处理节点创建/删除、会话重连、消费者标记等细节但控制粒度也更细。
本文档对 Jaws 框架中 Nacos 和 ZooKeeper 两种注册中心实现进行全方位比较。一、底层存储模型维度NacosZooKeeper数据模型扁平化服务模型serviceName group instances树形层级路径模型类似文件系统路径结构jaws/{path}作为 serviceNamegroup 来自 URL/jaws/{group}/{path}/server/{host:port}多层路径数据存储URL 参数全部存入 Instance 的metadataMapURL 完整字符串作为 ZK 节点的 databyte[]节点类型无区分instance 只有 ephemeral 属性区分AVAILABLE_SERVER和CLIENT两种节点类型ZK 路径层级见ZkUtils/jaws/{group}/{servicePath}/server/{host:port} ← 服务提供者 /jaws/{group}/{servicePath}/client/{host:port} ← 服务消费者Nacos 映射见NacosPathUtilsserviceName jaws/{path} group url.getGroup() instance metadata {protocol, path, ...所有URL参数}二、服务注册机制ZooKeeper先删后建注册前先removeNode清除可能残留的旧节点再createNode双节点父路径为PERSISTENT类型服务实例节点为EPHEMERAL类型会话断开自动删除数据载体节点 data 存储url.toFullStr()完整 URL 字符串Nacos直接注册调用namingService.registerInstance()即可无需先清理单实体只注册一个Instance对象设置ephemeraltrue, healthytrue数据载体URL 参数全部放入instance.metadata额外存储protocol和path核心区别ZK 依赖临时节点 会话心跳实现自动下线Nacos 依赖心跳 健康检查机制。三、服务订阅与发现机制ZooKeeper — CuratorCache 监听使用CuratorCache监听/server路径下的子节点变化监听NODE_CREATED/NODE_DELETED事件事件触发后重新getChildren获取全量子节点列表逐个getData解析 URL订阅时还会创建CLIENT临时节点消费者标记Nacos — EventListener 监听使用namingService.subscribe()注册EventListener收到NamingEvent后直接从中获取ListInstance全量实例列表从 metadata 中还原 protocol/path 构建 URL不创建额外的消费者节点核心区别ZK 是被动通知只告诉你节点变了需要自己去拉最新数据Nacos 是主动推送直接给你最新实例列表。四、断线重连机制ZooKeeper — 显式重连ZookeeperRegistry在构造时注册了ConnectionStateListenerif(connectionStateConnectionState.RECONNECTED){reRegisterServices();// 重新注册所有服务reSubscribeServices();// 重新订阅所有服务}因为 ZK 临时节点在会话断开后会丢失重连后必须手动恢复。Nacos — 无显式重连NacosRegistry没有连接状态监听。Nacos 客户端 SDK 内部处理了心跳和重连NamingService会自动维护注册状态。五、服务发现doDiscover维度NacosZooKeeperAPInamingService.getAllInstances(serviceName, group)curator.getChildren().forPath(parentPath)数据解析从 metadata 直接构建 URL逐个子节点getData读取 byte[] 再反序列化 URL容错metadata 无 protocol 时用 refUrl 兜底节点 data 解析失败时用节点名解析 host:port 兜底路径不存在Nacos SDK 内部处理需先checkExists再getChildren六、并发控制两者结构完全一致clientLockReentrantLock保护订阅/取消订阅操作serverLockReentrantLock保护注册/注销操作serviceListeners都是HashMapURL, MapNotifyListener, 具体监听器七、动态配置对比维度NacosDynamicConfigurationZookeeperDynamicConfiguration存储Nacos ConfigServicekey→dataIdgroup 固定为JAWS_CONFIGZK 节点路径/jaws/dynamic-config/{key}读写getConfig/publishConfiggetData/setData/create/delete监听NacosListener回调CuratorCache监听节点变化连接复用独立创建ConfigService与注册用 NamingService 不同实例独立创建CuratorFramework与注册用客户端不同实例删除配置removeConfigcurator.delete()八、Factory 创建对比维度NacosRegistryFactoryZookeeperRegistryFactory客户端NamingFactory.createNamingService(Properties)CuratorFrameworkFactory.builder().build()重试策略Nacos SDK 内部管理ExponentialBackoffRetry(1000, 3)显式配置认证username/password 放入 Propertiesdigest模式 ACL 认证超时CONFIG_LONG_POLL_TIMEOUTsessionTimeoutMsconnectionTimeoutMs分离九、总结特性NacosZooKeeper数据模型扁平面向服务注册设计通用协调服务健康检查服务端主动心跳检测会话超时 临时节点自动消失变更通知推送全量实例列表Watch 通知 客户端重新拉取重连恢复SDK 内部处理应用层无感应用层监听RECONNECTED手动恢复消费者感知不记录消费者信息创建 CLIENT 临时节点标记消费者配置中心原生 ConfigService 支持用节点 data 模拟需自建路径规范代码复杂度较低~183行API 更高级较高~267行需手动管理节点生命周期简而言之Nacos 实现更简洁因为 Nacos SDK 封装了更多服务注册的高层语义ZooKeeper 实现更底层需要手动处理节点创建/删除、会话重连、消费者标记等细节但控制粒度也更细。
