Mark4z

看起来CI不怎么稳定

Awesome ！

@jhump Yes, similar but needs to be a little smarter. That's because when some third-party proto dependencies are compiled by gogoprotoc, but you can't simply recompile it, like ‘k8s.io/api’, the...

Yeah, I think u are right.

客户端已经可以成功使用delta拉取数据 

上报部分也已经完成，剩余一些Bug和优化工作

> > 上报时的namespace如何处理？下发时的namespace如何处理也是一个问题 cc @AlbumenJ > > 上报的数据可以基于 namespace 隔离存储，下发的时候也可以支持跨 namespace 订阅。 可以修改下接口，添加 namespace 参数，订阅的时候不指定 namespace 默认就是当前 namespace 获取。 @AlbumenJ 对于订阅，通常会使用ads的ResourceNames来指定资源，这里我建议使用形如 a.b.c.hellowrold|dubbo-demo的形式来订阅跨namespace的interface，dubbo-demo即要订阅的namespace。因为ads里要增加字段略微有些复杂，ads的定义在envoy的组织下，需要再fork一个仓库，意义不大。

指定namespace的方式已经完成，形式为 a.b.c.hellowrold|dubbo-demo订阅来自dubbo-demo的对应service，a.b.c.hellowrold| 或者 a.b.c.hellowrold默认订阅订阅者所在的namespace

接入文档 https://dubbogoproxy.yuque.com/dubbogoproxy/vld1hq/srgix1anpmpin444/edit

> 1. 兼容性问题：之前的实现 path 是 `/${appName}/${className}/${method}/${version}` ，新的实现会是 `/${appName}/${className}/${method}`，version 放到 header 里，会和之前的版本不兼容性 > 2. 目前的应用级实现是通过元数据接口补全了全部信息的，是不是可以和接口级实现进行统一，这样就不用前缀匹配了，避免出现 pixiu 这边 path 校验通过了，请求后端 dubbo 服务的时候发现没有方法这种 case > > 最终实现是不是可以统一成接口级的实现，应用级用元数据补全 url 就行了，这样实现起来更统一，对目前的代码改动量小 1. 按照/${appName}/${className}/${method} 2. 统一成接口级