问题描述
如图所示，在 Swarm 集群中部署了 ServiceA 和 ServiceB 这两个服务，服务间通过 grpc 建立长连接实现服务间调用。然而 ServiceA 在调用 ServiceB 时，偶尔会出现如下错误：
java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223)
at sun.nio.ch.IOUtil.read(IOUtil.java:192)
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380)
at io.netty.buffer.PooledUnsafeDirectByteBuf.setBytes(PooledUnsafeDirectByteBuf.java:288)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1100)
at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:367)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:118)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:642)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:565)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:479)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:441)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:745)
在我们查看容器日志时，这个错误出现次数不是很频繁，但是一定会出现，由于这个错误会导致业务系统异常，所以我们花了点时间去处理它。
问题排查
1、 grpc 中间件的问题？
并发测试：50 个线程，10万次请求，重复了 3 次，均能正常响应。因此，排除这种可能性。
2、测试环境网络波动导致的？
持续请求测试：多线程持续请求 4 小时，均能正常响应。然而另外一套测试环境，测试妹子人工测试的时候还是出现这个问题。因此，排除这种可能性。
3、搜索 Connection reset by peer 相关信息
网上很多文章都说明了这个异常可能出现的原因，经过各种 DEBUG，发现这个异常发生时，ServiceA 没有将数据发送到 ServiceB。结合上述 1 和 2 两步的测试，长连接一直维持时无异常；人工测试时，中途会停止请求，时间过长，长连接会断开，ServiceA 无法将数据发送给 ServiceB，就能解释通了。
4、分析 Docker Swarm 中的网络模型
Docker Swarm 中使用 IPVS 将 ServiceA 的请求路由到 ServiceB 的一个实例，ServiceA 与 ServiceB 长连接的建立会经过 IPVS。此处 IPVS 的规则是：当 TCP 会话空闲超过15分钟（900秒）时，IPVS 连接超时并从连接表中清除，即图中 IPVS 与 ServiceB 之间的连接。
下面是两种不同的 timeout ，一种是 IPVS 的，另一种是 TCP 的：
默认 IPVS timeout 值:
ipvsadm -l --timeoutTimeout (tcp tcpfin udp): **900** 120 300
默认 TCP timeout 值:
-
tcp_keepalive_time = **7200**(秒，连接时长) -
tcp_keepalive_intvl = 75(秒，探测时间间隔) -
tcp_keepalive_probes = 9(次，探测频率)
当 IPVS 超时, 它将从连接表中清除。而 IPVS 超时后，时间在 7200s 之内，ServiceA 还是会认为长连接处于连接状态，实则不然，继续调用 ServiceB 则会出现问题。
5、精准复现问题
ServiceA 调用 ServiceB，正常响应，等待 15 分钟以上，ServiceA 继续调用 ServiceB，一定出现 Connection reset by peer 的异常。
问题解决
方式一：ServiceA 在代码层面实现连接重试逻辑
方式二：系统层面设置 TCP 的 timeout
设置 tcp_keepalive_time 小于 900s ，建议 600 ~ 800
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=10
或者编辑文件 /etc/sysctl.conf，添加如下内容：
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 10
为了使配置生效，必须重启 Swarm 中的服务。建议同时应用上述的两种方法。
