gRPC 是一个高性能、开源和通用的 RPC 框架，面向移动和 HTTP/2 设计，也是目前流行的微服务架构中比较突出的跨语言 RPC 框架。
一直以来，我们的微服务都是基于 gRPC 来开发，使用的语言有 .NET、JAVA、Node.js，整体还比较稳定，当然整个过程中踩过的坑也不少，今天主要介绍 gRPC 服务使用 Docker Swarm 部署遇到的问题。
问题描述
服务端空闲（没有接受到任何请求）一段时间后（不到 20 分钟），客户端 第一次 向服务端发请求会失败，重新请求则成功，具体错误日志如下，提示 gRPC 服务端将连接重置：
Grpc.Core.RpcException: Status(StatusCode=Unavailable, Detail="Connection reset by peer")
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Grpc.Core.Internal.AsyncCall`2.UnaryCall(TRequest msg)
at Grpc.Core.DefaultCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)
at Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx)
at Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation)
解决方案
方案1：重试机制
最初通过查看官方文档对 StatusCode=Unavailable 的解释，发现当前遇到的问题确实可以使用重试机制来处理，所以在客户端对 gRPC 服务的调用全部添加了重试策略。
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，当然还有很多区别，不过涉及更多运维层面的介绍我就不吹逼了，毕竟不在掌握范围内 。
网友评论