Albumen Kevin

> > https://dubbo.apache.org/zh-cn/blog/dubbo-k8s.html > > 打不开了。 You can refer this in https://github.com/apache/dubbo-website/blob/master/content/zh/blog/news/dubbo-k8s.md. Also, the new implement for kubernetes will be introduced in [Dubbo 3.0](https://github.com/apache/dubbo/tree/3.0/dubbo-registry/dubbo-registry-kubernetes).

Triple 协议的等 1.8.6 发版后用新的 Dubbo 3 Adapter 吧，那个会优先从 Dubbo API 获取应用名

Dubbo 对接 zk & nacos 这块的目标主要是在未来我们要提供支持三方注册中心的能力。现在 istio 是基于 k8s 的 service 去做的，也提供 mcp 数据源的模式。我们需要做的是需要先定义一个服务的格式，这个格式可以满足 xds 的需要，也可以满足 dubbo、sc 这种数据面的需要。然后把 istio 现有的获取 service 得能力调整到对接我们这样一个统一格式。最后基于此再去接入 zk & nacos，指导 zk & nacos 上的数据按照我们的那个格式存储，达到注册中心能力的全适配。

映射的逻辑是提供一个 com.example.DemoInterface => demo-application 的查找逻辑 涉及的接口样例如下： set(interfaceName string, appName string) get(interfaceName string) List watch(interfaceName string) Obserable 需要定义新的 proto，绑定在和 xds 同样的 grpc Chanel

> 借助目前xds的渠道可以较为简单地推送至各个dubbo服务，借助CRD可以较为简单地实现com.example.DemoInterface级别的增量，但内部app name list的增量，直观的方式是由control pannel缓存当前客户端的当前列表，但对control pannel压力很大，要考虑这个级别的增量是否是必要的。cc @AlbumenJ control pannel 缓存就可以，数据量不会特别大

> 上报时的namespace如何处理？下发时的namespace如何处理也是一个问题 cc @AlbumenJ 上报的数据可以基于 namespace 隔离存储，下发的时候也可以支持跨 namespace 订阅。 可以修改下接口，添加 namespace 参数，订阅的时候不指定 namespace 默认就是当前 namespace 获取。

服务查询这块的功能主要是需要提供一个查询当前集群所有服务信息的接口，类似 Dubbo Admin 的服务查询功能。具体到我们控制面需要做的就是提供一个 proto 包括了所有必要的数据，数据类似 xds 的数据，但是是以一个管控的视角去设计的。可以要跑一个 dubbo admin 体验下那个功能。

需要定义一个 proto 用于上报应用级服务发现的元数据信息和接口的服务定义信息，前者是应用级服务发现的时候消费端通过注册中心拿到 revision 之后获取全量服务信息的接口，后者是客户端上报服务元数据的信息用于记录接口的各种参数，满足运维的需要（如服务测试等）技术上本质就是一个存储的功能，提供 set 和 get 的接口就可以了，目前阶段还不需要对数据进行加工。这个 proto 可以直接绑定到 xDS 的 grpc channel 上就行。 元数据的主要涉及的接口有 set(app string, revision string, metadataInfo string) get(app string, revision string) 服务定义的有 set(identifier string,...

怎么注册的，具体是什么做的细节发一下

Dubbo 2.6 已经不在维护很久了，请升级到 Dubbo 3.x 版本。 另外注册 consumer 示例只是为了管控运维使用，真正的服务发现是按 provider 的