一.概述
使用者的用戶端調用API Gateway的引擎，API Gateway的引擎調用使用者的後端服務，目前都使用的是TCP串連，關於TCP串連，一些逾時時間的配置會影響到整個通訊過程，配置不合理會導致不同情形的問題，甚至導致故障。本文檔站在API Gateway的角度對API Gateway的用戶端和後端服務做出TCP連線逾時時間配置的建議，以便使用者更好地使用API Gateway，避免遇到一些已知的問題。
關於基於HTTP協議的TCP逾時時間，常見的有以下幾個配置：
串連建立逾時時間（ConnectionTimeout）
發送請求逾時時間（WriteTimeout）
讀取後端服務應答逾時時間（ReadTimeout）
針對ConnectionTimeout和WriteTimeout，我們可以根據網路情況配置不同的值，如果是公網通訊，一般需要配置大一點，比如ConnectionTimeout和WriteTimeout都配置成10秒，如果是內網通訊，則可以配置小一點。
但對於ReadTimeout，需要根據後端服務的處理時間來配置，特別是網關情境，需要配置多個ReadTimeout的時候，需要遵守一定規則。
二.使用API Gateway的TCP連線逾時時間配置原則
下圖是使用者的用戶端在調用API Gateway時鏈路視圖，鏈路比較簡單，用戶端的請求發送給API Gateway，API Gateway將用戶端的請求轉寄給使用者的後端服務，等使用者的後端服務處理完商務邏輯返回應答後，API Gateway將後端服務的應答返回給使用者的用戶端。
在這個通訊過程中，有兩個逾時時間的配置是需要特別關注的：
1.在用戶端配置的API Gateway應答逾時時間（ClientReadTimeout）
2.在API Gateway配置的後端服務逾時時間（APIGatewayBackendTimeout）
根據上圖的圖示，我們可以看到：
ClientReadTimeout = T2 + T3 + T4 + T5
APIGatewayBackendTimeout = T2 + T3 + T4
因此我們在配置ClientReadTimeout和APIGatewayBackendTimeout的時候，一定要遵守一個原則：
APIGatewayReaderTimeout需要大於後端業務處理時間
ClientReadTimeout需要大於APIGatewayBackendTimeout
我們舉個例子，如果後端服務對於一個API的處理時間絕大部分在10秒以內，那麼我們將APIGatewayBackendTimeout設定為10秒，ClientReadTimeout設定為15秒。確保後端應答返回的時候TCP串連沒有被關閉。
如果不按照這個原則進行配置，那麼在使用者後端服務延時較大的情況下，用戶端會在API Gateway返回應答前提前關閉TCP串連，導致API Gateway在應答的時候找不到可用的TCP串連報N502RE的錯誤，嚴重的時候可能會產生雪崩效應。這個配置請務必關注。
三.具體配置
上文說到的ClientReadTimeout需要在用戶端的初始化HttpClient串連池的代碼中配置，拿API Gateway提供的SDK舉例，在下面代碼中配置：
上文說到的APIGatewayBackendTimeout需要在API Gateway定義API的後端服務的時候配置，如下圖所示：
