今天暴风雨袭击了杭州，而昨天暴风雨（高并发问题）席卷了园子，留下一片狼藉。

在前天傍晚，我们进行了 .net core 版博客站点的第二次发布尝试，在发布后通过 kestrel 直接监听取代 nginx 转发解决了高并发下的1秒延迟问题，成功地顶住了下班前的访问小高峰，但这只是一场大雨，第二天的上午和下午的暴风雨（访问高峰中的高并发）才是真正的考验。

昨天，面对暴风雨，我们哼都不敢哼一声“让暴风雨来得更猛烈些吧”，只是一直不停地默念“让暴风雨快点过去吧”，尤其在下午的暴风雨袭击下，跑在 docker swarm 上 .net core 版博客系统溃不成军，大量请求响应速度极不稳定，时而快如闪电（10ms左右），时而慢如蜗牛（10s, 30s 甚至超时）。与第一次发布时不一样，不仅博客应用容器外是暴风雨，容器内也是暴风雨，在容器内用 curl 命令访问与外部用浏览器访问问题一样（难不成真的是 docker swarm 网络的问题？kestrel 监听取代 nginx 转发只是将网络并发负载从 nginx 容器转到了 kestrel 所在的博客应用容器。。。有待验证。）

昨天 17:30 左右并发量回落到一定程度之后，暴风雨飘然而去，立刻风平浪静，晴空万里，下午的那场暴风雨宛如梦中。

在暴风雨过后，我们查看了服务器的 linux 系统日志，发现很多下面的日志，而且都发生在暴风雨期间。

Aug  8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet

Aug  8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet

Aug  8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet

当时 docker swarm 集群中一共5台 worker 节点服务器，统计了一下每台服务器出现 "table full" 日志的数量。

blog-swarm-n3: 2149

blog-swarm-n4: 1964

blog-swarm-n5: 2451

blog-swarm-n6: 2095

blog-swarm-n7: 0

咦，怎么有1台服务器为0？哦，原来是这台没有挂上所有负载均衡，只承受了 2/3 左右的流量，虽然下的暴风雨，但对这台服务器来说只是一场大雨。

针对上面的日志，我们调整了 linux 内核的 2 个设置置（参考文档），在 /etc/sysctl.conf 中添加

net.netfilter.nf_conntrack_max = 655350

net.netfilter.nf_conntrack_tcp_timeout_established = 1200

这个调整成为我们今天唯一的希望，但早*问高峰来临的时候，迎接我们的不是喜出望外，而是昔日重来。。。

在熟悉的暴风雨面前，我们面临着艰难的选择，放弃-退回 windows 上的 .net framework 版博客系统，还是坚持-至少要找到一种能抵挡一定程度暴风雨的临时解决方法？

那台没有 "table full" 日志的服务器给了我们启发——分而治之，将暴风雨变成每一台服务器的大雨，拆分流量到不同的服务器，减少每台服器的并发连接数，今天就是通过这个临时的笨方法扛住了暴风雨，大量减少了响应速度慢的情况，所以到现在 .net core 版博客站点依然在线。

在抗过今天上下午访问高峰的暴风雨后，杭州也被暴风雨袭击了，因为有了房子，任凭外面风吹雨打，我们可以坐在房间里一边敲着代码，一边凝听着窗外的风雨声。对于这次遇到的高并发问题，我们相信总有一天会为我们的博客系统建造好房子，在暴风雨的风吹雨打中潇洒地在日志中写着“让暴风雨来得更猛烈些吧”。