增加流控和增强对xds的支持 about rpcx

[smallnest]

1. 这可以实现一个流控的插件，如果没有贡献者开发，后续我会实现一个
2. 其实我觉得微服务网格的场景中，大家使用grpc就好了。 但是也非常欢迎有人贡献
3. 第三个可以使用最新的Oneshot方法，不需要传入reply

[someview]

1. 这可以实现一个流控的插件，如果没有贡献者开发，后续我会实现一个
2. 其实我觉得微服务网格的场景中，大家使用grpc就好了。 但是也非常欢迎有人贡献
3. 第三个可以使用最新的Oneshot方法，不需要传入reply

这个流控看起来也不是很简单， 我觉得流控最佳的方案还是消费者告诉生产者降低发送速度。
grpc主要还是背靠大厂，云原生支持得比较好。rpcx协议比较简单，也容易实现.
我们现在有一个需求是这样， rpc客户端发送消息给服务端， 客户端可以异步接收响应。然后服务端可以发送响应，也可以不发送响应。这个希望能够把消息流量属性和业务属性分离开来，一方面是解耦，另一方面是观测，在使用deepflow类似的云原生观测系统的时候，能够使用ebpf来从中进行链路追踪。这就要求，在服务端异步sendmessage回去的时候，需要携带和请求到来时的标识。现在，rpcx的bidistreamclient看起来做不到这件事情.

[smallnest]

1. 这可以实现一个流控的插件，如果没有贡献者开发，后续我会实现一个
2. 其实我觉得微服务网格的场景中，大家使用grpc就好了。 但是也非常欢迎有人贡献
3. 第三个可以使用最新的Oneshot方法，不需要传入reply

这个流控看起来也不是很简单， 我觉得流控最佳的方案还是消费者告诉生产者降低发送速度。 grpc主要还是背靠大厂，云原生支持得比较好。rpcx协议比较简单，也容易实现. 我们现在有一个需求是这样， rpc客户端发送消息给服务端， 客户端可以异步接收响应。然后服务端可以发送响应，也可以不发送响应。这个希望能够把消息流量属性和业务属性分离开来，一方面是解耦，另一方面是观测，在使用deepflow类似的云原生观测系统的时候，能够使用ebpf来从中进行链路追踪。这就要求，在服务端异步sendmessage回去的时候，需要携带和请求到来时的标识。现在，rpcx的bidistreamclient看起来做不到这件事情.

如果你是这个需要的话，可以传递meta数据：https://github.com/rpcxio/rpcx-examples/blob/master/metadata/client/client.go

[someview]

1. 这可以实现一个流控的插件，如果没有贡献者开发，后续我会实现一个
2. 其实我觉得微服务网格的场景中，大家使用grpc就好了。 但是也非常欢迎有人贡献
3. 第三个可以使用最新的Oneshot方法，不需要传入reply

这个流控看起来也不是很简单， 我觉得流控最佳的方案还是消费者告诉生产者降低发送速度。 grpc主要还是背靠大厂，云原生支持得比较好。rpcx协议比较简单，也容易实现. 我们现在有一个需求是这样， rpc客户端发送消息给服务端， 客户端可以异步接收响应。然后服务端可以发送响应，也可以不发送响应。这个希望能够把消息流量属性和业务属性分离开来，一方面是解耦，另一方面是观测，在使用deepflow类似的云原生观测系统的时候，能够使用ebpf来从中进行链路追踪。这就要求，在服务端异步sendmessage回去的时候，需要携带和请求到来时的标识。现在，rpcx的bidistreamclient看起来做不到这件事情.

如果你是这个需要的话，可以传递meta数据：https://github.com/rpcxio/rpcx-examples/blob/master/metadata/client/client.go

在ebpf获取到rpcx协议里面的metadata然后进行解析.确实可以使用这种形式. 所有疑问已经得到解答

[someview]

1. 这可以实现一个流控的插件，如果没有贡献者开发，后续我会实现一个
2. 其实我觉得微服务网格的场景中，大家使用grpc就好了。 但是也非常欢迎有人贡献
3. 第三个可以使用最新的Oneshot方法，不需要传入reply

这个流控看起来也不是很简单， 我觉得流控最佳的方案还是消费者告诉生产者降低发送速度。 grpc主要还是背靠大厂，云原生支持得比较好。rpcx协议比较简单，也容易实现. 我们现在有一个需求是这样， rpc客户端发送消息给服务端， 客户端可以异步接收响应。然后服务端可以发送响应，也可以不发送响应。这个希望能够把消息流量属性和业务属性分离开来，一方面是解耦，另一方面是观测，在使用deepflow类似的云原生观测系统的时候，能够使用ebpf来从中进行链路追踪。这就要求，在服务端异步sendmessage回去的时候，需要携带和请求到来时的标识。现在，rpcx的bidistreamclient看起来做不到这件事情.

如果你是这个需要的话，可以传递meta数据：https://github.com/rpcxio/rpcx-examples/blob/master/metadata/client/client.go

存在一个很困惑的地方，https://github.com/rpcxio/rpcx-examples/blob/master/metadata/client/client.go，
send方法调用的时候，直接就用conn.write了，没有锁，这让我非常困惑。完全不明白这是什么情况

[someview]

1. 这可以实现一个流控的插件，如果没有贡献者开发，后续我会实现一个
2. 其实我觉得微服务网格的场景中，大家使用grpc就好了。 但是也非常欢迎有人贡献
3. 第三个可以使用最新的Oneshot方法，不需要传入reply

这个流控看起来也不是很简单， 我觉得流控最佳的方案还是消费者告诉生产者降低发送速度。 grpc主要还是背靠大厂，云原生支持得比较好。rpcx协议比较简单，也容易实现. 我们现在有一个需求是这样， rpc客户端发送消息给服务端， 客户端可以异步接收响应。然后服务端可以发送响应，也可以不发送响应。这个希望能够把消息流量属性和业务属性分离开来，一方面是解耦，另一方面是观测，在使用deepflow类似的云原生观测系统的时候，能够使用ebpf来从中进行链路追踪。这就要求，在服务端异步sendmessage回去的时候，需要携带和请求到来时的标识。现在，rpcx的bidistreamclient看起来做不到这件事情.

如果你是这个需要的话，可以传递meta数据：https://github.com/rpcxio/rpcx-examples/blob/master/metadata/client/client.go

存在一个很困惑的地方，https://github.com/rpcxio/rpcx-examples/blob/master/metadata/client/client.go， send方法调用的时候，直接就用conn.write了，没有锁，这让我非常困惑。完全不明白这是什么情况,net.Conn标准接口并不是并发安全调用的啊

[smallnest]

Multiple goroutines may invoke methods on a Conn simultaneously.
https://pkg.go.dev/net#Conn