GitHub user AlexStocks added a comment to the discussion: metadata
文章的宏观主线基本是对的，尤其是“应用级发现里 registry 负责给实例，metadata 负责把实例恢复成服务语义”这条线；但有几处说法讲得太顺了，落到 dubbo-go 现实现状上会失真。 **主要偏差** - `MetadataService` 不是“provider 默认都会暴露”的能力，它只在 `metadata-type != remote` 时才导出；如果走远端元数据存储，provider 会把 app metadata 发布到 report，但本地不会导出 metadata RPC 服务。[metadata/options.go#L63](/D:/test/github/dubbo-go/metadata/options.go#L63) [service_discovery_registry.go#L92](/D:/test/github/dubbo-go/registry/servicediscovery/service_discovery_registry.go#L92) [metadata_service_url_params_customizer.go#L58](/D:/test/github/dubbo-go/registry/servicediscovery/customizer/metadata_service_url_params_customizer.go#L58) - 文章把 `revision` 描述成“当前服务集合的一份摘要”，这个方向对，但实现上没那么强。当前 `resolveRevision` 只用了 `application + path + version + port + methods` 做 CRC 累加，并没有把 `group`、`protocol`、参数集等完整纳入；所以“服务语义变化就一定触发 revision 变化”这个说法，在现实现状下偏强。[service_revision_customizer.go#L87](/D:/test/github/dubbo-go/registry/servicediscovery/customizer/service_revision_customizer.go#L87) - 文章把 “接口 -> 应用” 映射讲成 metadata 体系里一个自然组成部分，但在 dubbo-go 里它实际上强依赖 `metadata report` 后端。`Map/Get` 都直接走 report；如果没有 metadata report，自动映射就会失败，consumer 只能靠 `provided-by` 这类显式配置兜底。[service_name_mapping.go#L65](/D:/test/github/dubbo-go/metadata/mapping/metadata/service_name_mapping.go#L65) [service_discovery_registry.go#L254](/D:/test/github/dubbo-go/registry/servicediscovery/service_discovery_registry.go#L254) - `metadata` 模块不只是维护 provider 暴露服务集合，它也在维护 consumer 的订阅 URL 集合，并计算 `dubbo.subscribed-services.revision`。文章几乎只从 provider 视角讲“服务快照”，少了 consumer 侧这半边状态模型。[metadata.go#L40](/D:/test/github/dubbo-go/metadata/metadata.go#L40) [service_revision_customizer.go#L73](/D:/test/github/dubbo-go/registry/servicediscovery/customizer/service_revision_customizer.go#L73) - “实例级元数据表达能力偏弱”这个判断可以保留，但文章写得有点过窄。当前实例 metadata 里不只有 `revision` 和 metadata 入口参数，还会写 `dubbo.endpoints`（多协议端口信息）、`meta-v`（metadata service version）、`dubbo.metadata.storage-type` 等字段，所以它不是只有最小二元组，只是离 Java 那种更丰满的实例模型还有距离。[protocol_ports_metadata_customizer.go#L49](/D:/test/github/dubbo-go/registry/servicediscovery/customizer/protocol_ports_metadata_customizer.go#L49) [metadata_service_version_customizer.go#L48](/D:/test/github/dubbo-go/registry/servicediscovery/customizer/metadata_service_version_customizer.go#L48) [service_discovery_registry.go#L117](/D:/test/github/dubbo-go/registry/servicediscovery/service_discovery_registry.go#L117) - “接口到应用映射的动态能力不够强”需要加限定条件。不是完全弱，而是“后端实现不均匀”：Nacos 和 Zookeeper 都接了 listener，consumer 订阅链路里也会注册 mapping listener；但 Etcd 实现没有真正处理 listener，所以这个能力不是全局一致的。[service_discovery_registry.go#L246](/D:/test/github/dubbo-go/registry/servicediscovery/service_discovery_registry.go#L246) [nacos/report.go#L134](/D:/test/github/dubbo-go/metadata/report/nacos/report.go#L134) [zookeeper/report.go#L111](/D:/test/github/dubbo-go/metadata/report/zookeeper/report.go#L111) [etcd/report.go#L95](/D:/test/github/dubbo-go/metadata/report/etcd/report.go#L95) **有一处值得单独强调** - 文章把 `MetadataService` 更像讲成“远程访问入口”，但在 dubbo-go 代码里，`DefaultMetadataService` 先是一个本地单例状态容器，负责存取 exported/subscribed URLs 和按 revision 查内存中的 `MetadataInfo`；RPC 导出只是它的一层暴露形式，不是它的全部定义。[metadata.go#L27](/D:/test/github/dubbo-go/metadata/metadata.go#L27) [metadata_service.go#L49](/D:/test/github/dubbo-go/metadata/metadata_service.go#L49) GitHub link: https://github.com/apache/dubbo-go/discussions/3300#discussioncomment-16618679 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
