暴風雨中的 online : .NET Core 版博客站點遭遇的高併發問題進展

今天暴風雨襲擊了杭州，而昨天暴風雨（高併發問題）席捲了園子，留下一片狼藉。

在前天傍晚，咱們進行了 .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 版博客站點依然在線。

在抗過今天上下午訪問高峯的暴風雨後，杭州也被暴風雨襲擊了，由於有了房子，任憑外面風吹雨打，咱們能夠坐在房間裏一邊敲着代碼，一邊凝聽着窗外的風雨聲。對於此次遇到的高併發問題，咱們相信總有一天會爲咱們的博客系統建造好房子，在暴風雨的風吹雨打中瀟灑地在日誌中寫着「讓暴風雨來得更猛烈些吧」。