伺服器連線超時就是在程式預設的等待時間內沒有得到伺服器的響應，每次傳送請求等待若干秒後只能接受到底層返回的超時報錯資訊，而連線超時也是非常影響使用者體驗的。以前我們公司也經常會出現這樣的問題，很是頭疼。後來聽搞運維的朋友介紹了聽雲公司，這個公司就是從事應用效能管理（APM）和使用者體驗最佳化的第三方加測服務提供商。聽雲Server是服務端應用的私人醫生，3分鐘部署到應用伺服器，安裝成功之後很快就可以獲取監測資料，功能穩定性強，僅在必要的位置進行嵌碼，對應用服務端的效能基本沒有什麼影響。好像是可以申請免費試用的，你可以去試用看看，滿意再選擇。

1. 問題描述

服務端響應超時，有什麼方法解決？

系統響應超時泛指系統沒有宕機，但是業務處理效能差，服務響應低效。通常原因也好理解：

1. 內部程式設計問題：例如資料庫查詢慢、單個程序佔用資源太多、某些處理出現Bug（死迴圈、低效演算法等）

2. 外部原因：業務量快速增長、遠遠超出預計；遭到駭客攻擊如DDos；促銷、特殊事件帶來的使用者量脈衝式爆發

處理思路：保證核心業務和絕大部分使用者。

示例場景 1

上游介面 TP99 超 3s 仍未返回處理結果。

示例場景 2

因網路異常無法連線到上游服務。

2. 解決方案

a. 降級：監控發現資源不足時，對非核心業務不分配資源，全力保證核心業務。例如新聞論壇只保證瀏覽使用者，暫時關閉評論和轉發入口，對購物流程只保留黃金流程的購物體驗，降級優惠券等虛擬資產的使用。 操作上有：通過後門降級（需要單個單個操作）；透過獨立設計的降級系統，觸發降級指令（類似以前電信的Overload信令）。

b. 熔斷：和降級主要針對內部處理能力不足的區別是，主要應對外部業務爆發或攻擊。熔斷機制實現的關鍵首先是有統一的API呼叫層；其次是閾值的設定。一旦啟動，則將某項服務直接中斷，該服務的API呼叫全部直接返回錯誤，如“活動太火爆”、“程式設計師小哥哥送貨去了”之類的提示窗。

c. 限流：降級是從內部降低服務響應級別來做，限流則是從外部訪問壓力角度來說的。限制入口流量在系統訪問能力內，超出的丟棄。常見的是基於請求限流（總累積請求數、時間內請求數）；基於資源限流（內部的連線數、執行緒數等）；實現途徑上看有nginx請求限流、redis集中限流以及jvm記憶體限流等。

d. 排隊：其實類似於限流。一般同時還會在入口提供等待頁面“前面有XXX個使用者在等待，預計還需要XXX分鐘！”，舒緩一下使用者心理，在排隊過程中逐漸處理業務請求，達到限流削峰的目的。