Dubbo/Triple direct & auto proxy

[mark4z]

What would you like to be added:

背景

现有dgp.filter.http.dubboproxy通过泛化调用代理dubbo，注册发现/路由/负载均衡均内置在dubbo-go的泛化调用中，无法利用到Pixiu现有的Router和Cluster的能力。
另一方面，triple代理目前不支持应用级服务发现，而且仍需要adapters+api_config来路由

目标

1. 废弃adapters+api_config结合将信息写到Router的方式
2. dgp.filter.http.directdubboproxy直接代理能力扩展，配合Router和Cluster完成dubbo代理
3. triple代理配合Router和Cluster完成dubbo代理，同时支持接口级与服务级代理
4. dubbo/triple协议代理/group/version可指定也可按约定根据元数据自动选择
5. dubbo/triple代理客户端连接池管理
6. dubbo/triple统一调用方式
7. 支持nacos/zk
8. 找不到路由时的友好提示
9. 增加丰富的samples演示以上功能

How to

代理所需的信息即一个${appName}/${className}/${method} + group + version 即三元组应该被路由到哪个Cluster，最后从Cluster中选择一个Ip后，借助dgp.filter.http.directdubboproxy即可完成一次代理。
这部分信息可以从注册中心拿到，其中${appName}/${className}/${method} + group + version作为路由，即Router(三元组)->Cluster(EndPoints)。

以Nacos为例
配置文件：registry/nacos/go-server/conf/dubbogo.yml（https://github.com/apache/dubbo-go-samples）

元数据

接口级

服务列表

服务名	分组名称
providers:org.apache.dubbo.UserProvider.Test2:myInterfaceVersion:myInterfaceGroup	myGroup

服务详情

IP	端口	健康状态	元数据
192.168.128.1	20000	true	methods=GetUser interface=org.apache.dubbo.UserProvider.Test2 path=/org.apache.dubbo.UserProvider.Test2 protocol=dubbo group=myInterfaceGroup version=myInterfaceVersion application=myApp
192.168.128.1	20001	true	methods=GetUser interface=org.apache.dubbo.UserProvider.Test2 path=/org.apache.dubbo.UserProvider.Test2 protocol=dubbo group=myInterfaceGroup version=myInterfaceVersion application=myApp

应用级

服务名	分组名称
myApp	myGroup

应用详情

IP	端口	元数据
192.168.128.1	20001	...
192.168.128.1	20000	...

服务映射

Data Id	Group
org.apache.dubbo.UserProvider.Test2	mapping

服务映射详情（应用名）
myApp,myApp2,myApp3

实现

对于接口级，考虑将${appName}/${className}/${method} + group + version拼接起来做为一个Router项，并将EndPoints生成一个Cluster
对于应用级，则更为简单，以${appName}做为Router项，并将EndPoints生成一个Cluster即可。
接口级注册则可利用协议元数据中protocol=dubbo/triple自动选择dubbo/triple client调用。

Why is this needed:

[FoghostCn]

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

最终实现是不是可以统一成接口级的实现，应用级用元数据补全 url 就行了，这样实现起来更统一，对目前的代码改动量小

[mark4z]

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

最终实现是不是可以统一成接口级的实现，应用级用元数据补全 url 就行了，这样实现起来更统一，对目前的代码改动量小

1. 按照/${appName}/${className}/${method}
2. 统一成接口级