上周五下午，我們在博客中部署了推薦系統，在博文下方顯示“最新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 有關。