超時，沒錯就是它，或又稱爲延時。
超時再細分，又分爲DB超時，緩存超時，RPC超時。下面是一個統計分析圖，尤其是RPC超時所佔比重最大，這是因爲分佈式系統架構的思想已植根於每位程序架構者的思維，而RPC是分佈式乃至微服務環境中不可或缺的一個因素。
爲什麼經常發生超時
現在處在一個各種分工的年代，打車可用用滴滴，吃飯可以叫外賣，寄快遞可以用京東物流，需要依賴。系統分工下來也一樣，存儲數據需要數據庫，提高響應速度需要用緩存，分佈式結構化需要RPC調用等等。就連叫外賣還有可能因小哥路上堵車而耽誤了呢。系統的環境也一樣，網絡帶來了不確定性，還記得腦裂問題嗎，在一個高可用的且有服務狀態的系統中如果因爲網絡問題當正常通訊的多個節點之間突然斷開，就會形成不再有通訊的相互獨立的節點，比如我們常配置的MySQL主從複製，如果發生這種腦裂問題就會影響數據讀取的準確性。CAP不能同時滿足的最大的根源之一實際上也是網絡超時造成的。
RPC調用的分類有多種，比如從通信協議層面看有基於http協議的調用，基於二進制協議的調用，更多的基於tcp協議的調用，以及還有單語言RPC(如RMI等)和跨語言平臺的RPC(如google protobuffer等)，但無論哪種類型及是否跨語言平臺，從RPC的調用鏈上看，網絡都牢牢的把握住了客戶端和服務端的聯繫，發送和接收數據都繞不開它。當然RPC的超時還有其它原因，比如序列化超時、服務端接口性能以及可能的服務端機器負載，甚至還有GC的耗時長短都會影響RPC調用。
我們如何做
加超時設置，報警閾值要調整得當。對重要同步調用需要分組線程池隔離，甚至分開部署，做到局部不要影響全部。需要深刻明白局部穩定不等於整體穩定，系統穩定也不等於業務穩定，比如舉一個例子來說，有時候系統監控沒有任何異常報警，可能你的監控只是應用層級的，說具體點就是Nginx或者Tomcat這個層面，如果因爲服務商域名解析導致用戶調用超時，原先現有的系統監控則沒有辦法監控到，會仍然認爲業務運行良好，實際則只能幹粑粑的等待用戶反饋。當然這種情況可以結合其他方面規則監控一定程度避免。總之意識要清晰，對超時這類問題。
具體定位方法：(參考《架構修煉之道》第6章內容)
1.首先第一想到的就是要分析網絡情況，看是否網絡延遲嚴重，是否有TCP重傳，TCP重傳次數不能太大。
2.分析服務端和調用端的運行情況，看是否壓力較大，比如cpu使用率，cpu負載，內存佔用大小等。
3.看傳輸對象是否很大，很複雜，請儘量簡單，這個對序列化有很大影響。
4.如果服務端有隊列，試着減少隊列，或者改爲固定線程池，線程特別多，可以試試減少線程大小。
5.控制cpu使用率不要太高，儘量不超80%，不行該擴容就擴容。另外大部分業務都是I/0密集型，並非計算密集型。達到80%的時候一定注意負載是否有問題了，要麼線程阻塞，要麼就趕緊擴容吧。
6.有可能的話，可以以單次耗時爲準，查看下單次耗時的差距，從而看看是否是某些參數的請求導致耗時比較長。
7.看看服務端是否有full gc，你懂的。STW。如果頻繁yong gc也不是好事兒，無論yong還是full都會STW，只是耗時長短問題。如下圖所示採樣一天時間內的fg次數，這是一個比較正常的情況，但如果平均耗時較大肯定會響應當時的調用響應時間。
8.排除了以上種種因素，還沒有定位到原因，那麼就需要嘗試如下方法了：可在服務端通過tcpdump抓包，用wireshark分析rpc請求在服務端耗時，定位是服務端還是調用端耗時長，然後進一步確定原因。
延伸
針對超時再延伸一些內容，就這次618備戰過程中梳理出的幾點內容分享如下：
1、 在代碼review的過程中，我們對如何寫一段好的的代碼，仍然要縝密，比如，對方法粒度的控制上，如何做到小方法解決一個功能，粒度控制的不好。想對某一個單一的功能D增加ump監控，往往卻包含了A、B、C功能。
2、 外部資源依賴等，這些資源的監控，還是有遺漏的，務須做到外部調用必有監控（包括DB、緩存、RPC等所有依賴資源）。
3、 日誌異常打印信息不豐富，只輸出了異常棧，當然比沒有強的多了，但還是不夠，我們需要把入參打印出來，讓前後文信息豐富起來，才能更快的定位問題。
4、 Jvm的報警我們沒有添加全面，比如GC次數報警，單位時間內GC次數報警過多肯定不是好事情，另外一次GC的時間也要關注。
5、 方法的報警我們沒有添加全面，比如方法調用次數監控，以及時間粒度要做到1分鐘的粒度，如果超過1分鐘在遇到線上問題的情況下就是一個等待，這個成本太大，會對排查造成延遲。
6、 對可降級的點，我們梳理的，只能說，仍然不夠到位。我們要的場景是這樣，既然是應對措施，那麼將來發生的問題，在我們的應對措施裏面如果碰到，我們直接點擊出去，降級就好了，達到一種這樣的效果，當然後來都已經補充。
7、 大家對問題的敏感度，求知慾不強，線上一旦有風吹草動需要有足夠的嗅覺意識，看到異常的蛛絲馬跡需要糾個明白，比如性能突然上來又下去，需要考察背後的原因，不能只看看就了事。
8、 我們在架構升級和需求之間徘徊不定，像部署結構及拆解方案，我們也都之前有碰過，但需求永遠是做不完的，每個人站在自己的立場考慮問題，也是正常的。但是咱們技術人員肯定要知道自己的真實情況，其實真有了必要改造系統的感覺的時候，可以每次迭代改造，比如10%這樣的進度往前走。
9、 對線上問題處理的思路和方法，還是要持續鍛鍊，像ump它不僅僅是簡單的一個讓你看看tp99就好了，裏面的對比查看，按機器維度查看，高級搜索條件使用，如何結合cap系統等，這些光靠培訓只是讓你知道而已，甚至培訓的過程中知道的還不是那麼貼切，還是需要大家積極的參與到值班，實際解決問題中，進行實際的操作鍛鍊。
畢業季兩句話，上大學是爲了什麼？兩件事情最爲重要：一是掌握學習的能力，二是養成合作的習慣。--某位大咖
寫文章就是要寫文章，發的時間不分休息日和工作日，看到是一種緣分。--我說的 ????
