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

[someview]

1. 之前有一个需求是诗选sub-pub模式，但是pub模式只需要oneway模式就够了，我在之前采用netpoll库来实践过，发现生产者和消费者速度不匹配，缺乏流控机制。这次看了一下rpcx中的协议部分，发现也没有流控机制。如果没有流控的情况下， 这如何保证不压垮服务端呢。用户层的限流等等，我认为很难匹配服务端端点的实际情况.
2. 我感觉rpcx缺少在微服务网格情况下服务治理的支持，这极大程度上限制了rpcx的应用.
3. 能否为oneway模式提供专门的api而不是采用fn(ctx,req,res, err)的形式来传递呢。这个考虑的出发点是， 清晰的api需要明确知道什么样的参数可以传递, 只是由于语言本身表达能力的限制所以无法实现而已. 例如req是否可以为nil,ctx是否可以为nil, err是否可以为nil，这几者之间是否可以同时为nil.

[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