上週五下午,我們在部落格中部署了推薦系統,在博文下方顯示“最新IT新聞”的地方顯示自動推薦的關聯博文。我們用的推薦系統是第四正規化的推薦服務,我們自己只是搭建了一個推薦系統中轉站(基於 ASP.NET Core),接收來自部落格前端的請求,然後將請求轉發給第四正規化的推薦服務,並將響應內容轉發給部落格前端。

這個中轉站的功能非常簡單,就是一個 http 請求/響應搬運工,簡單到讓我們忽視了它會給伺服器帶來的潛在壓力 —— 一邊與部落格前端的請求/響應會產生大量 TCP 連線,一邊與推薦服務的請求/響應會產生大量 TCP 連線,而且由於推薦資料的動態變化特點而無法使用快取。在同樣的負載下,這個搬運工會比其他應用消耗更多的 TCP 連線。

從上週五發布到昨天,由於訪問量沒有達到特別高的高峰,所以問題沒有暴露。今天上午訪問量達到更高峰時,問題出現了。部署在 docker swarm 叢集上的很多站點時不時地出現 500 錯誤,日誌中頻繁出資料庫或 memcached 伺服器網路連線失敗的錯誤。開始我們還以為是之前多次遇到過的節點伺服器不穩定問題引起的,於是將叢集中的伺服器一臺一臺下線、重啟、上線,但這樣操作之後問題依舊。接著把懷疑物件放到了 memcached 伺服器,是不是 memcached 伺服器不穩定引起,於是重啟 memcached 伺服器,但問題依然。

在用完之前的招式、百思不得其解之時突然想到可能是叢集中某些伺服器的 TCP 連線過多達到了限制(Linux 的限制或者阿里雲的限制),如果站在這個角度分析,不管故障的表現還是日誌中的錯誤都可以得到合理的詮釋。於是立馬鎖定了原因,然後自然就想到了我們上週五部署的推薦系統中轉站,趕緊將其下線,500 錯誤即刻消失,叢集上的所有應用都會恢復正常。

非常抱歉,這次故障給大家帶來麻煩了,請大家諒解。我們會吸取這次上線推薦系統時不夠深思熟慮、過於輕敵的教訓,認真反思,努力改進自己的工作。

更新:後來升級至 .NET Core 2.2 Preview 3 ,並將 System.Net.Http 升級至 4.3.4 之後沒出現這個問題,問題與 https://github.com/dotnet/corefx/pull/32568 有關。