您正在查看 Apigee Edge 說明文件。
參閱 Apigee X 說明文件。 資訊
Apigee Edge 針對多個後端伺服器執行個體提供負載平衡和容錯移轉的內建支援功能,可提升 API 的可用性。
TargetServer 設定會將具體端點網址與 TargetEndpoint 設定分離。每個 TargetServer 都會由 TargetEndpoint HTTPConnection 中的名稱參照。您可以按照 TargetEndpoint 一節中的說明,設定一或多個已命名的 TargetServer,不必在設定中定義具體網址。
TargetServer 定義包含名稱、主機和通訊埠,其他元素則用於指出 TargetServer 啟用或停用。
影片
請觀看下方影片,進一步瞭解如何使用目標伺服器進行 API 轉送和負載平衡
影片 | 說明 |
---|---|
使用目標伺服器進行負載平衡 | 跨目標伺服器負載平衡 API。 |
根據使用目標伺服器的環境進行 API 轉送 | 根據環境將 API 轉送至不同的目標伺服器。 |
透過目標伺服器進行 API 轉送和負載平衡 (傳統版邊緣) | 根據環境將 API 轉送至其他目標伺服器,並在傳統版 Edge UI 中跨目標伺服器對 API 進行負載平衡。 |
TargetServer 設定範例
下列程式碼定義了目標伺服器:
<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >
TargetServer 設定元素
下表說明用於建立及設定 TargetServer 的元素:
名稱 | 說明 | 預設 | 必填與否 |
---|---|---|---|
name |
TargetServer 設定的名稱,在環境中不得重複。TargetServer 名稱只能包含英數字元。 | 不適用 | 可 |
Host |
後端服務的主機網址 (不含通訊協定)。 | 不適用 | 可 |
Port |
後端服務正在監聽的通訊埠 | 不適用 | 可 |
IsEnabled |
布林值,指出 TargetServer 設定是否已啟用。如此一來,您就可以在不修改 API Proxy 設定的情況下,將 TargetServer 移出旋轉。常見用途是撰寫應用程式或指令碼,以便根據預期的容量需求、維護時間表等方式自動啟用或停用 TargetServer。 | true |
可 |
透過使用者介面管理目標伺服器
管理目標伺服器,如下所述。
Edge
如何使用 Edge UI 管理目標伺服器:
- 登入 apigee.com/edge。
- 在左側導覽列中,依序選取「Admin」>「Environments」>「Target Servers」。
- 選取所需環境,例如 test 或 prod。
- 如何建立目標伺服器:
- 按一下「+ 目標伺服器」。
- 輸入目標伺服器的名稱、主機和通訊埠。
例如:
- 名稱:target1
- 主機:1.mybackendservice.com
- 通訊埠:80
- 視需要選取「SSL」。
- 選取「已啟用」來啟用目標伺服器。
- 按一下 [新增]。
- 如要編輯目標伺服器,請按照下列步驟操作:
- 將遊標移到您要編輯的目標伺服器上,即可顯示動作選單。
- 按一下「」。
- 編輯 targer 伺服器值。
- 按一下「更新」。
- 如要刪除目標伺服器:
- 將滑鼠遊標移到要刪除的目標伺服器上,即可顯示動作選單。
- 按一下「」。
- 按一下「Delete」(刪除) 來確認作業。
傳統版邊緣 (Private Cloud)
如要使用傳統版 Edge UI 存取「Create Proxy」精靈:
- 登入
http://ms-ip:9000
,其中 ms-ip 是 Management Server 節點的 IP 位址或 DNS 名稱。 - 在左側導覽列中,依序選取「API」>「環境設定」>「目標伺服器」。
- 選取所需環境,例如 test 或 prod。
- 如何建立目標伺服器:
- 按一下「編輯」。
- 按一下「+ 目標伺服器」。
- 輸入目標伺服器的名稱、主機和通訊埠。
例如:
- 名稱:target1
- 主機:1.mybackendservice.com
- 通訊埠:80
- 選取「已啟用」來啟用目標伺服器。
- 點按「儲存」。
- 如要編輯目標伺服器,請按照下列步驟操作:
- 按一下「編輯」。
- 編輯 targer 伺服器值。
- 點按「儲存」。
- 如要刪除目標伺服器:
- 按一下「編輯」。
- 按一下「刪除」。
使用 API 管理目標伺服器
您可以使用 Edge API 建立、刪除、更新、取得及列出目標伺服器。詳情請參閱「TargetServers」。
使用下列 API 呼叫建立目標伺服器:
$ curl -H "Content-Type:text/xml" -X POST -d \ '<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
回應範例:
{ "host" : "1.mybackendservice.com", "isEnabled" : true, "name" : "target1", "port" : 80 }
建立第一個 TargetServer 後,請使用下列 API 呼叫建立第二個 TargetServer。定義兩個 TargetServers,就能提供兩個網址,讓 TargetEndpoint 用於負載平衡:
$ curl -H "Content-type:text/xml" -X POST -d \ '<TargetServer name="target2"> <Host>2.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
回應範例:
{ "host" : "2.mybackendservice.com", "isEnabled" : true, "name" : "target2", "port" : 80 }
使用下列 API 呼叫可擷取環境中的 TargetServers 清單:
$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
回應範例:
[ "target2", "target1" ]
現在有兩個 TargetServer 可供測試環境中部署的 API Proxy 使用。為了對這些 TargetServer 的流量進行負載平衡,請在 API Proxy 的目標端點中設定 HTTP 連線,以便使用 TargetServer。
如限制主題所述,每個環境最多只能有 500 個 TargetServer。
設定 TargetEndpoint,以便跨已命名的 TargetServers 進行負載平衡
現在您已有兩個 TargetServers,可以修改 TargetEndpoint HTTP 連線設定,以名稱參照這兩個 TargetServer:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
上述設定是最基本的負載平衡設定。負載平衡器支援三種負載平衡演算法:循環配置演算法、加權和最低連線。「Round Robin」是預設演算法。由於上方設定未指定演算法,因此從 API Proxy 傳送至後端伺服器的傳出要求會交替處理,分別位於 target1 和目標 2 之間。
<Path>
元素會構成所有目標伺服器的 TargetEndpoint URI 基準路徑。只有在使用 <LoadBalancer>
時才會使用。否則系統會忽略它。在上述範例中,傳送至「target1」的要求將會是 http://target1/test
,以此類推。
設定負載平衡器選項
您可以在負載平衡器和 TargetServer 層級使用負載平衡和容錯移轉選項調整可用性。本節將說明這些選項。
演算法
設定 <LoadBalancer>
使用的演算法。可用的演算法包括 RoundRobin
、Weighted
和 LeastConnections
,以下逐一說明。
循環制
預設的演算法是循環配置,會按照伺服器在目標端點 HTTP 連線中的順序,將要求轉送至每個 TargetServer。例如:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
加權
加權負載平衡演算法可讓您為 TargetServer 設定按比例計算的流量負載。加權的 LoadBalancer 會根據每個 TargetServer 的權重,以直接比例將要求分配給 TargetServer。因此,使用加權演算法時,您必須為每個 TargetServer 設定 weight
屬性。例如:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>Weighted</Algorithm> <Server name="target1"> <Weight>1</Weight> </Server> <Server name="target2"> <Weight>2</Weight> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
在這個示例中,系統會針對每個轉送至 target1 的要求,將兩個要求轉送至 target2。
最少連線
設定為使用最低連線演算法的 LoadBalancer,會將傳出要求轉送至最小開放 HTTP 連線的 TargetServer。例如:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
失敗次數上限
從 API Proxy 傳送至 TargetServer 的失敗要求數量上限,導致要求重新導向至其他 TargetServer。
回應失敗代表 Apigee 不會收到目標伺服器傳送的任何回應。發生這種情況時,失敗計數器會遞增 1。
不過,當 Apigee 收到目標的回應時,即便回應是 HTTP 錯誤 (例如 500
),也算是來自目標伺服器的回應,且失敗計數器也會重設。為了確保無效的 HTTP 回應 (例如 500
) 也會增加失敗計數器,讓錯誤計數器盡快從負載平衡輪替中擷取不健康的伺服器,您可以在負載平衡器設定中新增包含 <ResponseCode>
子元素的 <ServerUnhealthyResponse>
元素。邊緣也會將這些代碼的回應視為失敗。
在以下範例中,如果收到五個失敗的要求,target1
就會從輪替中移除,包括來自目標伺服器的部分 5XX
回應。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> <ServerUnhealthyResponse> <ResponseCode>500</ResponseCode> <ResponseCode>502</ResponseCode> <ResponseCode>503</ResponseCode> </ServerUnhealthyResponse> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
MaxFailures 預設為 0。這表示 Edge 一律會嘗試連線至每項要求的目標,而且絕對不會將目標伺服器從輪替中移除。
最好將 MaxFailures > 0 與 HealthMonitor 搭配使用。如果您設定 MaxFailures > 0,當目標失敗次數達到您指定的次數時,系統就會將 TargetServer 從輪替中移除。設有 HealthMonitor 時,Apigee 會根據 HealthMonitor 的設定在目標再次執行且再次執行後,自動將 TargetServer 輪替回輪替。詳情請參閱「健康狀態監控」一文。
或者,如果您設定 MaxFailures > 0,而且並未設定 HealthMonitor,Apigee 偵測到 Apigee 偵測到失敗後,就不會自動將 TargetServer 重新納入輪替作業。在這種情況下,您必須先重新部署 API Proxy,然後 Apigee 才會將 TargetServer 重新排回輪替。請參閱「部署 API Proxy」一節。
重試
如果已啟用重試功能,只要發生回應失敗 (I/O 錯誤或 HTTP 逾時) 或收到的回應與 <ServerUnhealthyResponse>
設定的值相符,系統就會重試要求。
如要進一步瞭解如何設定 <ServerUnhealthyResponse>
,請參閱上方的失敗次數上限一節。
<RetryEnabled>
預設為 true
。如要停用重試功能,請設為 false
。
例如:
<RetryEnabled>false</RetryEnabled>
IsFallback
一個 (也只能) 一個 TargetServer 設為「備用」伺服器。除非負載平衡器將所有其他 TargetServer 識別為無法使用,否則負載平衡處理常式中不會包含備用 TargetServer。如果負載平衡器判定所有 TargetServer 都無法使用,則所有流量都會轉送至備用伺服器。例如:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <Server name="target3"> <IsFallback>true</IsFallback> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
上述設定會導致目標 1 和 2 之間的循環配置平衡,直到兩個目標 1 和 2 都無法使用為止。如果目標 1 和 2 無法使用,所有流量都會轉送至目標 3。
路徑
路徑會定義 URI 片段,該片段會附加至 TargetServer 傳送至後端伺服器的所有要求。
此元素接受常值字串路徑或訊息範本。訊息範本可讓您在執行階段執行變數字串替換作業。例如,在下列目標端點定義中,路徑的 {mypath}
值會用於路徑:
<HTTPTargetConnection> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <LoadBalancer> <Server name="testserver"/> </LoadBalancer> <Path>{mypath}</Path> </HTTPTargetConnection>
設定 TLS/SSL 的目標伺服器
如果您使用 TargetServer 定義後端服務,且後端服務需要連線以使用 HTTPS 通訊協定,您就必須在 TargetServer 定義中啟用 TLS/SSL。由於 <Host>
標記不允許指定連線通訊協定,因此這是必要步驟。下圖為單向 TLS/SSL 的 TargetServer 定義,其中 Edge 會向後端服務發出 HTTPS 要求:
<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
如果後端服務需要雙向或雙向 TLS/SSL,您可以使用與 TargetEndpoint 相同的 TLS/SSL 設定來設定 TargetServer:
<TargetServer name="TargetServer 1"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
如要進一步瞭解 <SSLInfo>
屬性 (例如 <Ciphers>
和 <ClientAuthEnabled>
),請參閱設定私有雲的 API 的 TLS 存取權一文,瞭解如何為虛擬主機設定這些屬性。
如需設定傳出 TLS/SSL 的完整操作說明,請參閱設定從 Edge 傳送至後端的 TLS (Cloud 和 Private Cloud)。
TargetServer 結構定義
請參閱 GitHub 上的 TargetServer 和其他實體結構定義。
狀態監控
健康狀態監控功能可讓您主動輪詢 TargetServer 設定中定義的後端服務網址,藉此強化負載平衡設定。啟用健康狀態監控功能後,當 HealthMonitor 判定 TargetServer 處於啟用狀態時,故障的 TargetServer 會自動移回輪替作業。
狀態監控功能可搭配 <MaxFailures>
使用。在未啟用健康狀態監控功能的情況下,<MaxFailures>
會指定從 API Proxy 傳送至 TargetServer 的失敗要求數量,使要求重新導向至另一個 TargetServer。接著,系統會將失敗的 TargetServer 從輪替中移除,直到您重新部署 Proxy 為止。
啟用健康狀態監控功能後,失敗的 TargetServer 就會自動移回輪替,不需要透過 Proxy 重新部署。
HealthMonitor 可做為簡易用戶端,透過 TCP 或 HTTP 叫用後端服務:
- TCP 用戶端只是確保通訊端可以開啟。
- 您要設定 HTTP 用戶端,向後端服務提交有效的 HTTP 要求。您可以定義 HTTP GET、PUT、POST 或 DELETE 作業。HTTP 監控呼叫的回應必須與
<SuccessResponse>
區塊中的設定相符。
成功和失敗
啟用健康狀態監控功能後,Edge 就會開始傳送健康狀態檢查至您的目標伺服器。健康狀態檢查是傳送到目標伺服器的要求,用來判斷目標伺服器的健康狀態是否良好。
健康狀態檢查可能會產生下列其中一項結果:
- 成功:成功執行健康狀態檢查時,系統會將目標伺服器視為健康狀態良好。這通常是下列一或多項結果:
- 目標伺服器接受對指定通訊埠的新連線,回應該通訊埠的要求,然後在指定的時間範圍內關閉通訊埠。目標伺服器的回應中包含「Connection: Close」(連線:關閉)
- 目標伺服器會以 200 (OK) 或其他 HTTP 狀態碼回應健康狀態檢查要求,
- 目標伺服器回應健康狀態檢查要求時,系統會傳送與預期訊息內文相符的訊息內文。
當 Edge 判定伺服器的健康狀態良好時,Edge 會繼續或繼續向其傳送要求。
- 失敗:目標伺服器可能會因檢查類型而以不同方式失敗健康狀態檢查。系統會在目標伺服器發生下列情況時記錄失敗:
- 拒絕從 Edge 傳送至健康狀態檢查通訊埠的連線。
- 未在指定時間範圍內回應健康狀態檢查要求。
- 傳回非預期的 HTTP 狀態碼。
- 回覆的訊息內文與預期訊息內文不符。
如果目標伺服器未通過健康狀態檢查,Edge 就會增加該伺服器的失敗次數。如果該伺服器的失敗次數達到或超過預先定義的門檻 (
<MaxFailures>
),Edge 就會停止向該伺服器傳送要求。
啟用健康監控器
如要建立 HealthMonitor,請將 <HealthMonitor>
元素新增至 TargetEndpoint 的 Proxy 的 HTTPConnection 設定。您無法在 UI 中進行這項操作。而是改為建立 Proxy 設定,並以 ZIP 檔案的形式上傳至 Edge。Proxy 設定是 API Proxy 各層面的結構化說明。Proxy 設定包含預先定義的目錄結構中的 XML 檔案。詳情請參閱 API Proxy 設定參考資料。
簡單的 HealthMonitor 可定義結合 TCP 監控器或 HTTP 監控器的 IntervalInSec
,<MaxFailures>
元素會指定從 API Proxy 傳送至 TargetServer 的失敗要求數量上限,讓要求重新導向至其他 TargetServer。<MaxFailures>
預設為 0,表示 Edge 不會執行修正動作。設定健康狀態監控器時,請務必將 <TargetEndpoint>
標記的 <HTTPTargetConnection>
標記中的 <MaxFailures>
設為非零的值。
TCPMonitor
下列設定會定義一個 HealthMonitor,透過每五秒在通訊埠 80 開啟連線,藉此輪詢每個 TargetServer。(通訊埠為選用項目,如果未指定,則 TCPMonitor 通訊埠是 TargetServer 通訊埠)。
- 如果連線失敗或連線時間超過 10 秒,該 TargetServer 的失敗次數就會增加 1。
- 如果連線成功,TargetServer 的失敗次數就會重設為 0。
您可以將 HealthMonitor 新增為 TargetEndpoint HTTPTargetConnetion 元素的子項元素,如下所示:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <Port>80</Port> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> . . .
使用 TCPMonitor 設定元素的健康監控應用程式
下表說明 TCPMonitor 設定元素:
名稱 | 說明 | 預設 | 必填與否 |
---|---|---|---|
IsEnabled |
啟用或停用 HealthMonitor 的布林值。 | false | 否 |
IntervalInSec |
每個輪詢 TCP 要求之間的時間間隔 (以秒為單位)。 | 0 | 可 |
ConnectTimeoutInSec |
必須建立與 TCP 通訊埠連線的時間,才會視為成功。若無法在指定的時間間隔內建立連線,就會計為失敗,導致 TargetServer 的負載平衡器失敗次數增加。 | 0 | 可 |
Port |
選用設定。要建立 TCP 連線的通訊埠。如未指定,TCPMonitor 通訊埠則為 TargetServer 通訊埠。 | 0 | 否 |
HTTPMonitor
使用 HTTPMonitor 的 HealthMonitor 範例每五秒鐘會向後端服務提交 GET 要求,以下範例會在要求訊息中新增 HTTP 基本授權標頭。「回應」設定會定義要與後端服務實際回應比較的設定。在以下範例中,預期回應為 HTTP 回應代碼 200
,以及值為 YourOK
的自訂 HTTP 標頭 ImOK
。如果回應不相符,負載平衡器設定會將要求視為失敗。
HTTP 監控器支援設為使用 HTTP 和單向 HTTPS 通訊協定的後端服務。但不支援下列功能:
- 雙向 HTTPS (也稱為雙向 TLS/SSL)
- 自行簽署的憑證。
請注意,HTTP 監控器中的所有要求與回應設定,僅適用於必須叫用的後端服務。
<HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <IsSSL>true</IsSSL> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>80</Port> <Verb>GET</Verb> <Path>/healthcheck</Path> <Header name="Authorization">Basic 12e98yfw87etf</Header> <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> <Header name="ImOK">YourOK</Header> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
使用 HTTPMonitor 設定元素的健康監控應用程式
下表說明 HTTPMonitor 設定元素:
名稱 | 說明 | 預設 | 必填與否 |
---|---|---|---|
IsEnabled |
啟用或停用 HealthMonitor 的布林值。 | false | 否 |
IntervalInSec |
每個輪詢要求之間的時間間隔 (以秒為單位)。 | 0 | 可 |
Request |
針對由 HealthMonitor 傳送至輪替時 TargetServer 的傳出要求訊息設定選項。 「路徑」不支援變數。 |
不適用 | 可 |
IsSSL |
指定是否要使用 HTTPS (安全的 HTTP) 監控連線。 可能的值:
|
false | 否 |
ConnectTimeoutInSec |
傳送至 HTTP 服務的 TCP 連線握手必須完成的時間 (以秒為單位),才算成功。若未能在指定時間間隔內進行連線,就會計為一次失敗,導致 TargetServer 的失敗次數增加。 | 0 | 否 |
SocketReadTimeoutInSec |
時間 (以秒為單位),這種時間過後必須從 HTTP 服務讀取資料才能視為成功。如果在指定時間間隔內讀取失敗,系統就會計為失敗,進而增加 LoadBalancer 的 TargetServer 失敗次數。 | 0 | 否 |
Port |
要建立連至後端服務的 HTTP 連線的通訊埠。 | 不適用 | 否 |
Verb |
針對每個向後端服務輪詢 HTTP 要求而使用的 HTTP 動詞。 | 不適用 | 否 |
Path |
附加至 TargetServer 所定義網址的路徑。請使用路徑元素在 HTTP 服務中設定「輪詢端點」。 | 不適用 | 否 |
| 可讓您追蹤上游系統的健康狀態檢查要求。IncludeHealthCheckIdHeader 使用布林值,並預設為 false 。如果設為 true ,則系統會將名為 X-Apigee-Healthcheck-Id 的 Header 插入健康狀態檢查要求。標頭的值是以動態方式指派,且格式為 ORG/ENV/SERVER_UUID/N,其中 ORG 是機構名稱,ENV 是環境名稱,SERVER_UUID 是識別 MP 的專屬 ID,N 則是自 1970 年 1 月 1 日以來經過的毫秒數。
產生的要求標頭示例: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
|
false | 否 |
Payload |
為每個輪詢 HTTP 要求產生的 HTTP 主體。請注意,GET 要求不需要此元素。 | 不適用 | 否 |
SuccessResponse |
受輪詢後端服務產生的傳入 HTTP 回應訊息的比對選項。不相符的回應會使失敗次數增加 1。 | 不適用 | 否 |
ResponseCode |
預期會從輪詢的 TargetServer 接收 HTTP 回應代碼。如果代碼與指定的程式碼不同,則會產生失敗,並增加輪詢後端服務的數量。您可以定義多個 ResponseCode 元素。 | 不適用 | 否 |
Headers |
預期會從輪詢的後端服務接收的一或多個 HTTP 標頭和值清單。如果回應中有任何 HTTP 標頭或值與指定的值不同,則會導致失敗,輪詢的 TargetServer 數量就會增加 1。可以定義多個標頭元素。 | 不適用 | 否 |