【故障公告】推薦系統中轉站撐爆服務器 TCP 鏈接引起的故障

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