这是一个创建于 332 天前的主题，其中的信息可能已经有所发展或是发生改变。
某个 grpc 转发服务遇到一个问题，一次双向 stream 的请求，中间可能会有两个负责转发的节点，大概是：
client-->proxyA-->proxyB-->server
proxy 的处理过程是，来自请求发起方(client 方向)的 stream 是 grpc.ServerStream ，之后根据路由表建立向 server 端方向的服务器的 ClientStream 。一个 goroutine 负责从 client 收消息然后发给 server ，一个负责从 server 收消息发给 client 。
目前遇到的问题是，如果 server 返回 error 并关闭连接，proxyB 上负责接收 client 方向请求的 goroutine 会卡在 client 方向的 stream 的 RecvMsg 这里，需要接收一次来自 proxyA 的请求才能退出。同理，proxyA 也需要 client 发送一次请求才能退出。
结果就是当 server 出了问题，需要等 client 发送两次请求才能正常返回 error （第一次请求断开 proxyA 到 proxyB 的连接，第二次断开 client 到 proxyA 的连接）。更严重的是，第一次请求会一直阻塞在这里，直到超时后 context 被 cancel 掉。
我现在的想法是，能不能让 proxyB 在收到 server 返回的错误后手动给 proxyA 发送一个 error 以改善这一过程？毕竟不是所有的 stream 连接都能接受加心跳请求或是重试的，这对业务也是额外的负担。
第 1 条附言 · 332 天前
proxy 主要是解决 client 和 server 不在一个 vpc 的问题，之前不直接断开连接主要是怕断开了之后 goroutine 泄露，不过刚试了下好像没问题，断了连接之后 RecvMsg 会自动退出。。那没事了 感谢楼下各位回复
 |
1
sys64 332 天前
proxy 是四层的负载均衡吗，可以改成 7 层的负载均衡看看。
nginx 好像 1.20 版本就支持 grpc 的负载转发。 |
 |
2
lsk569937453 332 天前
目前遇到的问题是，如果 server 返回 error 并关闭连接，proxyB 上负责接收 client 方向请求的 goroutine 会卡在 client 方向的 stream 的 RecvMsg 这里，需要接收一次来自 proxyA 的请求才能退出。同理，proxyA 也需要 client 发送一次请求才能退出。
======================================================================= proxy 就是应该完全透传收到的请求阿。proxyB 都收到 server 的 error ，并且和 server 的连接都断开了，理所当然的 proxyB 应该和 proxyA 的连接也断开。 ps1:grpc 是长连接没办法做负载均衡的，不知道你为什么要用 proxy 来做？难道是网关？ ps2:proxyB 对长连接的处理直接用两个 io.copy 就完事了。任何一个 copy 出现问题，都可以手动断开两边的连接。 |
 |
3
rrfeng 332 天前 via Android
这明显是 proxy 实现的有问题吧
双向 stream 应该用同一个 ctx ？ |
Select Language