[[351757]]

 1 超時,無法避免的痛

HTTP調用即通過HTTP協議執(zhí)行一次網絡請求。既然是網絡請求，就有超時的可能性(可能你的網卡，也可能服務器所處網絡卡)，因此在開發(fā)中需要注意：

• 框架設置的默認超時時間是否合理
• 過短，請求還未處理完成，你就急不可待了!
• 過長，請求早已超出正常響應時間而掛了
• 考慮網絡不穩(wěn)定性，超時后可以通過定時任務請求重試
• 注意考慮服務端接口冪等性設計，即是否允許重試
• 考慮框架是否會像瀏覽器那樣限制并發(fā)連接數，以免在高并發(fā)下，HTTP調用的并發(fā)數成為瓶頸

1.1 HTTP調用框架技術選型

• Spring Cloud全家桶

          使用Feign進行聲明式的服務調用。

• 只使用Spring Boot

           HTTP客戶端Apache HttpClient進行服務調用。

1.2 連接超時配置 && 讀取超時參數

雖然應用層是HTTP協議，但網絡層始終是TCP/IP協議。TCP/IP是面向連接的協議，在傳輸數據之前需要建立連接。所以網絡框架都會提供如下超時參數：

 

• 連接超時參數ConnectTimeout

          可自定義配置的建立連接最長等待時間

• 讀取超時參數ReadTimeout

          控制從Socket上讀取數據的最長等待時間。

1.3 常見踩坑點

連接超時配置過長

比如60s。TCP三次握手正常建立連接所需時間很短，在ms級最多到s級，不可能需要十幾、幾十秒，多半是網絡或防火墻配置問題。這時如果幾秒還連不上，那么可能永遠也連不上。所以設置特別長的連接超時無意義，1~5秒即可。

如果是純內網調用，還可以設更短，在下游服務無法連接時，快速失敗

無腦排查連接超時問題

服務一般會有多個節(jié)點，若別的客戶端通過負載均衡連接服務端，那么客戶端和服務端會直接建立連接，此時出現連接超時大概率是服務端問題

而若服務端通過Nginx反向代理來負載均衡，客戶端連接的其實是Nginx，而非服務端，此時出現連接超時應排查Nginx

讀取超時參數和讀取超時“坑點”

只要讀取超時，服務端程序的正常執(zhí)行就一定中斷了?

案例

client接口內部通過HttpClient調用服務端接口server，客戶端讀取超時2秒，服務端接口執(zhí)行耗時5秒。

 

調用client接口后，查看日志：

• 客戶端2s后出現SocketTimeoutException，即讀取超時

• 服務端卻泰然地在3s后執(zhí)行完成

Tomcat Web服務器是把服務端請求提交到線程池處理，只要服務端收到請求，網絡層面的超時和斷開便不會影響服務端的執(zhí)行。因此，出現讀取超時不能隨意假設服務端的處理情況，需要根據業(yè)務狀態(tài)考慮如何進行后續(xù)處理。

讀取超時只是Socket網絡層面概念，是數據傳輸的最長耗時，故將其配置很短

比如100ms。

發(fā)生讀取超時，網絡層面無法區(qū)分如下原因：

• 服務端沒有把數據返回給客戶端
• 數據在網絡上耗時較久或丟包

但TCP是連接建立完成后才傳輸數據，對于網絡情況不是特差的服務調用，可認為：

• 連接超時

          網絡問題或服務不在線

• 讀取超時

          服務處理超時。讀取超時意味著向Socket寫入數據后，我們等到Socket返回數據的超時時間，其中包含的時間或者說絕大部分時間，是服務端處理業(yè)務邏輯的時間

超時時間越長，任務接口成功率越高，便將讀取超時參數配置過長

HTTP請求一般需要獲得結果，屬同步調用。

若超時時間很長，在等待 Server 返回數據同時，Client 線程(通常為 Tomcat 線程)也在等待，當下游服務出現大量超時，程序可能也會受到拖累創(chuàng)建大量線程，最終崩潰。

• 對定時任務或異步任務，讀取超時配置較長問題不大
• 但面向用戶響應的請求或是微服務平臺的同步接口調用，并發(fā)量一般較大，應該設置一個較短的讀取超時時間，以防止被下游服務拖慢，通常不會設置讀取超時超過30s。

評論可能會有人問了，若把讀取超時設為2s，而服務端接口需3s，不就永遠拿不到執(zhí)行結果?

的確，因此設置讀取超時要結合實際情況：

過長可能會讓下游抖動影響到自己

過短又可能影響成功率。甚至，有些時候我們還要根據下游服務的SLA，為不同的服務端接口設置不同的客戶端讀取超時。

1.4 最佳實踐

連接超時代表建立TCP連接的時間，讀取超時代表了等待遠端返回數據的時間，也包括遠端程序處理的時間。在解決連接超時問題時，我們要搞清楚連的是誰;在遇到讀取超時問題的時候，我們要綜合考慮下游服務的服務標準和自己的服務標準，設置合適的讀取超時時間。此外，在使用諸如Spring Cloud Feign等框架時務必確認，連接和讀取超時參數的配置是否正確生效。

2 Feign&&Ribbon

2.1 如何配置超時

為Feign配置超時參數的難點在于，Feign自身有兩個超時參數，它使用的負載均衡組件Ribbon本身還有相關配置。這些配置的優(yōu)先級是啥呢?

2.2 案例

• 測試服務端超時，假設服務端接口，只休眠10min

• Feign調用該接口：

 

• 通過Feign Client進行接口調用

在配置文件僅指定服務端地址的情況下：

clientsdk.ribbon.listOfServers=localhost:45678 

得到如下輸出：

[21:46:24.222] [http-nio-45678-exec-4] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController:26  ] -  
    執(zhí)行耗時：222ms 錯誤：Connect to localhost:45679 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1]  
        failed: Connection refused (Connection refused) executing  
            POST http://clientsdk/feignandribbon/server 

Feign默認讀取超時是1秒，如此短的讀取超時算是“坑”。

分析源碼

自定義配置Feign客戶端的兩個全局超時時間

可以設置如下參數：

feign.client.config.default.readTimeout=3000 
feign.client.config.default.connectTimeout=3000 

修改配置后重試，得到如下日志：

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] - 執(zhí)行耗時：3006ms 錯誤：Read timed out executing POST http://clientsdk/feignandribbon/server 

3秒讀取超時生效。

注意：這里有一個大坑，如果希望只修改讀取超時，可能會只配置這么一行：

feign.client.config.default.readTimeout=3000 

測試會發(fā)現，這樣配置無法生效。

要配置Feign讀取超時，必須同時配置連接超時

查看FeignClientFactoryBean源碼

• 只有同時設置ConnectTimeout、ReadTimeout，Request.Options才會被覆蓋

想針對單獨的Feign Client設置超時時間，可以把default替換為Client的name：

feign.client.config.default.readTimeout=3000 
feign.client.config.default.connectTimeout=3000 
feign.client.config.clientsdk.readTimeout=2000 
feign.client.config.clientsdk.connectTimeout=2000 

單獨的超時可覆蓋全局超時

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] -  
執(zhí)行耗時：2006ms 錯誤：Read timed out executing  
POST http://clientsdk/feignandribbon/server 

除了可以配置Feign，也可配置Ribbon組件的參數以修改兩個超時時間

參數首字母要大寫，和Feign的配置不同。

ribbon.ReadTimeout=4000 
ribbon.ConnectTimeout=4000 

可以通過日志證明參數生效：

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] -  
執(zhí)行耗時：4003ms 錯誤：Read timed out executing  
POST http://clientsdk/feignandribbon/server 

同時配置Feign和Ribbon的參數

誰會生效?

clientsdk.ribbon.listOfServers=localhost:45678 
feign.client.config.default.readTimeout=3000 
feign.client.config.default.connectTimeout=3000 
ribbon.ReadTimeout=4000 
ribbon.ConnectTimeout=4000 

最終生效的是Feign的超時：

[http-nio-45678-exec-3] [WARN ] [o.g.t.c.h.f.FeignAndRibbonController    :26  ] -  
執(zhí)行耗時：3006ms 錯誤：Read timed out executing  
POST http://clientsdk/feignandribbon/server 

同時配置Feign和Ribbon的超時，以Feign為準

在LoadBalancerFeignClient源碼

如果Request.Options不是默認值，就會創(chuàng)建一個FeignOptionsClientConfig代替原來Ribbon的DefaultClientConfigImpl，導致Ribbon的配置被Feign覆蓋：

但若這么配置，最終生效的還是Ribbon的超時(4秒)，難點Ribbon又反覆蓋了Feign?不，這還是因為坑點二，單獨配置Feign的讀取超時無法生效：

clientsdk.ribbon.listOfServers=localhost:45678 
feign.client.config.default.readTimeout=3000 
feign.client.config.clientsdk.readTimeout=2000 
ribbon.ReadTimeout=4000 

3 Ribbon自動重試請求

一些HTTP客戶端往往會內置一些重試策略，其初衷是好的，畢竟因為網絡問題導致丟包雖然頻繁但持續(xù)時間短，往往重試就能成功，

但要留心這是否符合我們期望。

3.1 案例

短信重復發(fā)送的問題，但短信服務的調用方用戶服務，反復確認代碼里沒有重試邏輯。

那問題究竟出在哪里?

Get請求的發(fā)送短信接口，休眠2s以模擬耗時：

 配置一個Feign供客戶端調用：

Feign內部有一個Ribbon組件負責客戶端負載均衡，通過配置文件設置其調用的服務端為兩個節(jié)點：

SmsClient.ribbon.listOfServers=localhost:45679,localhost:45678 

客戶端接口，通過Feign調用服務端

在45678和45679兩個端口上分別啟動服務端，然后訪問45678的客戶端接口進行測試。因為客戶端和服務端控制器在一個應用中，所以45678同時扮演了客戶端和服務端的角色。

在45678日志中可以看到，29秒時客戶端收到請求開始調用服務端接口發(fā)短信，同時服務端收到了請求，2秒后(注意對比第一條日志和第三條日志)客戶端輸出了讀取超時的錯誤信息：

[http-nio-45678-exec-4] [INFO ] [c.d.RibbonRetryIssueClientController:23  ] - client is called 
[http-nio-45678-exec-5] [INFO ] [c.d.RibbonRetryIssueServerController:16  ] - http://localhost:45678/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418 
[http-nio-45678-exec-4] [ERROR] [c.d.RibbonRetryIssueClientController:27  ] - send sms failed : Read timed out executing GET http://SmsClient/ribbonretryissueserver/sms?mobile=13600000000&message=a2aa1b32-a044-40e9-8950-7f0189582418 

而在另一個服務端45679的日志中還可以看到一條請求，客戶端接口調用后的1秒：

[http-nio-45679-exec-2] [INFO ] [c.d.RibbonRetryIssueServerController:16  ] - http://localhost:45679/ribbonretryissueserver/sms is called, 13600000000=>a2aa1b32-a044-40e9-8950-7f0189582418 

客戶端接口被調用的日志只輸出了一次，而服務端的日志輸出了兩次。雖然Feign的默認讀取超時時間是1秒，但客戶端2秒后才出現超時錯誤。

說明客戶端自作主張進行了一次重試，導致短信重復發(fā)送。

3.2 源碼揭秘

查看Ribbon源碼，MaxAutoRetriesNextServer參數默認為1，也就是Get請求在某個服務端節(jié)點出現問題(比如讀取超時)時，Ribbon會自動重試一次：

解決方案

1.把發(fā)短信接口從Get改為Post

API設計規(guī)范：有狀態(tài)的API接口不應定義為Get。根據HTTP協議規(guī)范，Get請求適用于數據查詢，Post才是把數據提交到服務端用于修改或新增。選擇Get還是Post的依據，應該是API行為，而非參數大小。

• 常見誤區(qū)：Get請求的參數包含在Url QueryString中，會受瀏覽器長度限制，所以一些開發(fā)會選擇使用JSON以Post提交大參數，使用Get提交小參數。

2.將MaxAutoRetriesNextServer參數配為0，禁用服務調用失敗后在下一個服務端節(jié)點的自動重試。在配置文件中添加一行即可：

ribbon.MaxAutoRetriesNextServer=0 

問責

至此，問題出在用戶服務還是短信服務?

也許雙方都有問題吧。

• Get請求應該是無狀態(tài)或者冪等的，短信接口可以設計為支持冪等調用
• 用戶服務的開發(fā)同學，如果對Ribbon的重試機制有所了解的話，或許就能在排查問題上少走彎路

最佳實踐

對于重試，因為HTTP協議認為Get請求是數據查詢操作，是無狀態(tài)的，又考慮到網絡出現丟包是比較常見的事情，有些HTTP客戶端或代理服務器會自動重試Get/Head請求。如果你的接口設計不支持冪等，需要關閉自動重試。但，更好的解決方案是，遵從HTTP協議的建議來使用合適的HTTP方法。

4 并發(fā)限制爬蟲抓取

HTTP請求調用還有一個常見的問題：并發(fā)數的限制，導致程序處理性能無法提升。

4.1 案例

某爬蟲項目，整體爬取數據效率很低，增加線程池數量也無謂，只能堆機器。

現在模擬該場景，探究問題本質。

假設要爬取的服務端是這樣的一個簡單實現，休眠1s返回數字1：

爬蟲需多次調用該接口抓取數據，為確保線程池不是并發(fā)瓶頸，使用了一個無線程上限的newCachedThreadPool，然后使用HttpClient執(zhí)行HTTP請求，把請求任務循環(huán)提交到線程池處理，最后等待所有任務執(zhí)行完成后輸出執(zhí)行耗時：

使用默認的PoolingHttpClientConnectionManager構造的CloseableHttpClient，測試一下爬取10次的耗時：

雖然一個請求需要1s執(zhí)行完成，但線程池可擴張使用任意數量線程。

按道理，10個請求并發(fā)處理的時間基本相當于1個請求的處理時間，即1s，但日志中顯示實際耗時5秒：

4.2 源碼解析

PoolingHttpClientConnectionManager源碼有兩個重要參數：

• defaultMaxPerRoute=2，即同一主機/域名的最大并發(fā)請求數為2。我們的爬蟲需要10個并發(fā)，顯然是默認值太小限制了爬蟲的效率。
• maxTotal=20，即所有主機整體最大并發(fā)為20，這也是HttpClient整體的并發(fā)度。我們請求數是10最大并發(fā)是10，20不會成為瓶頸。舉一個例子，使用同一個HttpClient訪問10個域名，defaultMaxPerRoute設置為10，為確保每一個域名都能達到10并發(fā)，需要把maxTotal設置為100。

HttpClient是常用的HTTP客戶端，那為什么默認值限制得這么小?

很多早期的瀏覽器也限制了同一個域名兩個并發(fā)請求。對于同一個域名并發(fā)連接的限制，其實是HTTP 1.1協議要求的，這里有這么一段話：

• Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
• HTTP 1.1協議是20年前制定的，現在HTTP服務器的能力強很多了，所以有些新的瀏覽器沒有完全遵從2并發(fā)這個限制，放開并發(fā)數到了8甚至更大。
• 如果需要通過HTTP客戶端發(fā)起大量并發(fā)請求，不管使用什么客戶端，請務必確認客戶端的實現默認的并發(fā)度是否滿足需求。

嘗試聲明一個新的HttpClient放開相關限制，設置maxPerRoute為50、maxTotal為100，然后修改一下剛才的wrong方法，使用新的客戶端進行測試：

輸出如下，10次請求在1秒左右執(zhí)行完成。可以看到，因為放開了一個Host 2個并發(fā)的默認限制，爬蟲效率得到了大幅提升：

4.3 最佳實踐

若你的客戶端有比較大的請求調用并發(fā)，比如做爬蟲，或是扮演類似代理的角色，又或者是程序本身并發(fā)較高，如此小的默認值很容易成為吞吐量的瓶頸，需要及時調整。