暴風(fēng)雨中的 online : .NET Core 版博客站點(diǎn)遭遇的高并發(fā)問(wèn)題進(jìn)展

今天暴風(fēng)雨襲擊了杭州，而昨天暴風(fēng)雨（高并發(fā)問(wèn)題）席卷了園子，留下一片狼藉。

在前天傍晚，我們進(jìn)行了 .net core 版博客站點(diǎn)的第二次發(fā)布嘗試
<https://www.cnblogs.com/cmt/p/11316324.html>，在發(fā)布后通過(guò) kestrel 直接監(jiān)聽(tīng)取代 nginx
轉(zhuǎn)發(fā)解決了高并發(fā)下的1秒延遲問(wèn)題，成功地頂住了下班前的訪問(wèn)小高峰，但這只是一場(chǎng)大雨，第二天的上午和下午的暴風(fēng)雨（訪問(wèn)高峰中的高并發(fā)）才是真正的考驗(yàn)。

昨天，面對(duì)暴風(fēng)雨，我們哼都不敢哼一聲“讓暴風(fēng)雨來(lái)得更猛烈些吧”，只是一直不停地默念“讓暴風(fēng)雨快點(diǎn)過(guò)去吧”，尤其在下午的暴風(fēng)雨襲擊下，跑在 docker
swarm 上 .net core 版博客系統(tǒng)潰不成軍，大量請(qǐng)求響應(yīng)速度極不穩(wěn)定，時(shí)而快如閃電（10ms左右），時(shí)而慢如蝸牛（10s, 30s 甚至超時(shí)）。與
第一次發(fā)布 <https://www.cnblogs.com/cmt/p/11302666.html>
時(shí)不一樣，不僅博客應(yīng)用容器外是暴風(fēng)雨，容器內(nèi)也是暴風(fēng)雨，在容器內(nèi)用 curl 命令訪問(wèn)與外部用瀏覽器訪問(wèn)問(wèn)題一樣（難不成真的是 docker swarm
網(wǎng)絡(luò)的問(wèn)題？kestrel 監(jiān)聽(tīng)取代 nginx 轉(zhuǎn)發(fā)只是將網(wǎng)絡(luò)并發(fā)負(fù)載從 nginx 容器轉(zhuǎn)到了 kestrel 所在的博客應(yīng)用容器。。。有待驗(yàn)證。）

昨天 17:30 左右并發(fā)量回落到一定程度之后，暴風(fēng)雨飄然而去，立刻風(fēng)平浪靜，晴空萬(wàn)里，下午的那場(chǎng)暴風(fēng)雨宛如夢(mèng)中。

在暴風(fēng)雨過(guò)后，我們查看了服務(wù)器的 linux 系統(tǒng)日志，發(fā)現(xiàn)很多下面的日志，而且都發(fā)生在暴風(fēng)雨期間。
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
當(dāng)時(shí) docker swarm 集群中一共5臺(tái) worker 節(jié)點(diǎn)服務(wù)器，統(tǒng)計(jì)了一下每臺(tái)服務(wù)器出現(xiàn) "table full" 日志的數(shù)量。
blog-swarm-n3: 2149 blog-swarm-n4: 1964 blog-swarm-n5: 2451 blog-swarm-n6:
2095 blog-swarm-n7: 0
咦，怎么有1臺(tái)服務(wù)器為0？哦，原來(lái)是這臺(tái)沒(méi)有掛上所有負(fù)載均衡，只承受了 2/3 左右的流量，雖然下的暴風(fēng)雨，但對(duì)這臺(tái)服務(wù)器來(lái)說(shuō)只是一場(chǎng)大雨。

針對(duì)上面的日志，我們調(diào)整了 linux 內(nèi)核的 2 個(gè)設(shè)置置（參考文檔
<https://help.aliyun.com/knowledge_detail/41334.html>），在 /etc/sysctl.conf 中添加
net.netfilter.nf_conntrack_max = 655350
net.netfilter.nf_conntrack_tcp_timeout_established = 1200
這個(gè)調(diào)整成為我們今天唯一的希望，但早上訪問(wèn)高峰來(lái)臨的時(shí)候，迎接我們的不是喜出望外，而是昔日重來(lái)。。。

在熟悉的暴風(fēng)雨面前，我們面臨著艱難的選擇，放棄-退回 windows 上的 .net framework
版博客系統(tǒng)，還是堅(jiān)持-至少要找到一種能抵擋一定程度暴風(fēng)雨的臨時(shí)解決方法？

那臺(tái)沒(méi)有 "table full"
日志的服務(wù)器給了我們啟發(fā)——分而治之，將暴風(fēng)雨變成每一臺(tái)服務(wù)器的大雨，拆分流量到不同的服務(wù)器，減少每臺(tái)服器的并發(fā)連接數(shù)，今天就是通過(guò)這個(gè)臨時(shí)的笨方法扛住了暴風(fēng)雨，大量減少了響應(yīng)速度慢的情況，所以到現(xiàn)在
.net core 版博客站點(diǎn)依然在線。


在抗過(guò)今天上下午訪問(wèn)高峰的暴風(fēng)雨后，杭州也被暴風(fēng)雨襲擊了，因?yàn)橛辛朔孔?，任憑外面風(fēng)吹雨打，我們可以坐在房間里一邊敲著代碼，一邊凝聽(tīng)著窗外的風(fēng)雨聲。對(duì)于這次遇到的高并發(fā)問(wèn)題，我們相信總有一天會(huì)為我們的博客系統(tǒng)建造好房子，在暴風(fēng)雨的風(fēng)吹雨打中瀟灑地在日志中寫著“讓暴風(fēng)雨來(lái)得更猛烈些吧”。

• ? 上一篇：8天入門docker系列 —— 第八天 讓程序跑在swarm集群上
• ? 下一篇：gin+vue的前后端分離開(kāi)源項(xiàng)目