StatusCode

虽然当时确实解决了问题，但也一直怀疑我们在使用方式上肯定有问题，毕竟 gRPC 在很多开源项目中都被验证过，理论上肯定不是这么处理问题的，所以并不推荐这么玩。

方案2：调整 TCP keepalive

在进行日志分析时，发现生产环境并没有此类型错误日志，所以问题基本和代码本身没什么关系，猜测是环境上的原因，而本地开发环境和生产环境的最大区别是：开发环境的服务通过 Docker Swarm 进行部署，线上环境则是使用 k8s 。所以尝试从 Docker Swarm 上进行问题定位，最终找到相关资料 gRPC streaming keepAlive doesn't work with docker swarm (虽然 issue 聊的是 grpc-go ，但其实和语言无关) 和 IPVS connection timeout issue ，问题和我们遇到的基本一致。

经过多次测试验证确定出问题的原因是当通过 Docker Swarm 部署 （基于 overlay 网络） gRPC 服务（基于 TCP），客户端调用服务端会经过 IPVS 处理，IPVS 简单来说就是传输级的负载均衡器，可以将基于 TCP 和 UDP 的服务请求转发到真实服务。gRPC 服务启动时，IPVS 中会将此 TCP 连接记录到连接跟踪表，但为了保持连接跟踪表干净，900s（默认的 timeout，不支持调整）内空闲的连接会被清理 ，IPVS 更多介绍

[root@node1]~# ipvsadm -l --timeout
Timeout (tcp tcpfin udp): 900 120 300

所以当客户端发请求时，如果 IPVS 的连接跟踪表中不存在对应连接，则会返回 Connection reset by peer ，重置后第二次请求就正常了。

所以解决方式就是使 IPVS 的连接跟踪表一直有该服务的连接状态，在 Linux 的内核参数中，有 TCP 的 keepalive 默认设置，时间是 7200s，我们只需要将其改成小于 900s，这样不到 900s 就发起探测，使连接状态一直保持。因为如果使用默认的 7200s 探测一次，IPVS 的连接跟踪表中此服务可能在 900s 的时候就已经被清理，所以在 901s~7200s 这个区间内有客户端请求进来就会出错。

[root@node1]~# sysctl -a | grep keepalive
net.ipv4.tcp_keepalive_time = 7200 # 表示当 keepalive 启用的时候，TCP 发送 keepalive 消息的频度，缺省是2小时
net.ipv4.tcp_keepalive_probes = 9 # 如果对方不予应答，探测包的发送次数
net.ipv4.tcp_keepalive_intvl = 75 # keepalive 探测包的发送间隔

修改可通过编辑 /etc/sysctl.conf 文件，调整后需 重启 gRPC 服务 ：

net.ipv4.tcp_keepalive_time = 800 #800s 没必要太小，其他两个参数也可相应做些调整
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15

如果不希望修改内核参数，也可以在 gRPC 服务代码中通过修改 grpc.keepalive_time_ms，参考：Keepalive User Guide for gRPC Core 和 Grpc_arg_keys，服务端默认 grpc.keepalive_time_ms 也是 7200s，和内核参数一样，以下是 .NET 代码例子（其他语言类似）：

var server = new Server(new List<ChannelOption>
{
  new ChannelOption("grpc.keepalive_time_ms", 800000), // 发送 keepalive 探测消息的频度
  new ChannelOption("grpc.keepalive_timeout_ms", 5000), // keepalive 探测应答超时时间
  new ChannelOption("grpc.keepalive_permit_without_calls", 1) // 是否允许在没有任何调用时发送 keepalive
})
{
  Services = { ServiceA },
  Ports = { new ServerPort(host, port, ServerCredentials.Insecure) },
};

再回头看看为什么生产环境的 k8s 没有这个问题，首先 kube-proxy 是支持 IPTABLES 和 IPVS 两种模式的，但目前我们使用的是 IPTABLES，当然还有很多区别，不过涉及更多运维层面的介绍我就不吹逼了，毕竟不在掌握范围内 。

参考链接

• gRPC streaming keepAlive doesn't work with docker swarm
• IPVS
• IPVS connection timeout issue
• Keepalive User Guide for gRPC Core
• Grpc_arg_keys