MasterKenway

refactor needed [WIP]

> 使用方案1 > > @MasterKenway 了解

working on it

1. 针对服务上线对应元数据的删除问题较为复杂，在第一版中暂时不实现 2. revision 区分于 etcd 的 MVCC，可以视作一个根据元数据内容计算出来的 MD5 的 key （哈希算法需要考虑碰撞的情况，考虑使用比较不容易碰撞的算法或设计一个检查机制） 3. 注册中心使用的服务元数据”，用于服务发现的， “服务运维使用的服务元数据”，描述了接口出入参等，用于运维的。前者可以理解成是为了构建url，后者则是让运维的人知道现在发布的接口具体有哪些参数（参考 Java 版 Dubbo 的实现）

4. 元数据对于 Endpoint 维度来说是静态的，在服务启动之后不会进行改动，因此对于服务端来说可以只考虑上报的逻辑 5. 原本消费端通过 Listener 监听 Provider 的元数据变动，现在则是将监听逻辑做到控制面中，通过 grpc 主动推送给消费端

https://dubbogoproxy.yuque.com/dubbogoproxy/vld1hq/hm6vdz

服务发现元数据 CRD 定义 ``` apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: # name must match the spec fields below, and be in the form: . name: metadata.networking.dubbo.io spec: # group name to...

目前进度遇到使用 istio build-tools 生成 CRD 相关代码时遇到 import proto 文件查找失败的问题 repo: https://github.com/dubbo-go-pixiu/operator-api 日志如下： ``` kenway@DESKTOP-9LOOPCM:/mnt/d/Workspace/GolandProjects/api$ make gen ./clean.sh ./gen.sh Syncing ./networking/v1beta1/destination_rule.proto from networking/v1alpha3/destination_rule.proto Syncing ./networking/v1beta1/gateway.proto from networking/v1alpha3/gateway.proto Syncing ./networking/v1beta1/service_entry.proto from networking/v1alpha3/service_entry.proto...

sorry for my mistake that did not show another part of the code. I actually create a new Producer.Message, thanks a lot for solving my problem.

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