跨後端伺服器負載平衡

您目前查看的是 Apigee Edge 說明文件。
前往 Apigee X 說明文件
info

Apigee Edge 內建負載平衡和容錯移轉功能,可跨多個後端伺服器執行個體運作,提升 API 可用性。

TargetServer 設定會將具體端點網址與 TargetEndpoint 設定分離。每個 TargetServer 都會在 TargetEndpoint HTTPConnection 中依名稱參照。您可以在設定中定義具體網址,也可以設定一或多個具名 TargetServer,如「TargetEndpoint」一節所述。

TargetServer 定義包含名稱、主機和通訊埠,以及指出 TargetServer 是否已啟用或停用的額外元素。

影片

觀看下列影片,進一步瞭解如何使用目標伺服器進行 API 轉送和負載平衡

影片 說明
使用目標伺服器進行負載平衡 在目標伺服器之間平衡 API 負載。
根據環境使用目標伺服器進行 API 路由 根據環境將 API 導向至不同的目標伺服器。
使用目標伺服器進行 API 轉送和負載平衡 (傳統 Edge) 在傳統 Edge UI 中,根據環境將 API 路由至不同目標伺服器,並在目標伺服器之間進行 API 負載平衡。

TargetServer 設定範例

下列程式碼會定義目標伺服器:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

TargetServer 設定元素

下表說明用於建立及設定 TargetServer 的元素:

名稱 說明 預設 是否必要?
name TargetServer 設定的名稱,在環境中不得重複。TargetServer 名稱只能包含英數字元。 N/A
Host

後端服務的主機網址 (不含通訊協定)。

N/A
Port 後端服務監聽的通訊埠 N/A
IsEnabled 布林值,表示 TargetServer 設定是否已啟用或停用。 這樣一來,您就能將 TargetServer 移出輪替,不必修改 API Proxy 設定。常見的用途是編寫應用程式或指令碼,根據預期容量需求、維護時間表等,自動啟用或停用 TargetServer。 true

使用使用者介面管理目標伺服器

管理目標伺服器,詳情請見下文。

邊緣

如要使用 Edge UI 管理目標伺服器,請按照下列步驟操作:

  1. 登入 apigee.com/edge
  2. 在左側導覽列中,依序選取「管理」>「環境」>「目標伺服器」
  3. 選取所需環境,例如「test」或「prod」
  4. 如要建立目標伺服器:
    1. 按一下「+ 目標伺服器」
    2. 輸入目標伺服器的名稱、主機和通訊埠。

      例如:

      • 名稱:target1
      • 主機:1.mybackendservice.com
      • 通訊埠:80
    3. 視需要選取「SSL」SSL
    4. 選取「已啟用」,啟用目標伺服器。
    5. 按一下 [新增]。
  5. 如要編輯目標伺服器,請按照下列步驟操作:
    1. 將游標懸停在要編輯的目標伺服器上,顯示動作選單。
    2. 按一下「」。
    3. 編輯目標伺服器值。
    4. 按一下「更新」
  6. 如要刪除目標伺服器:
    1. 將游標移到要刪除的目標伺服器上,顯示動作選單。
    2. 按一下「」。
    3. 按一下「刪除」確認操作。

Classic Edge (Private Cloud)

如要使用傳統版 Edge UI 存取「建立 Proxy」精靈,請按照下列步驟操作:

  1. 登入 http://ms-ip:9000,其中 ms-ip 是管理伺服器節點的 IP 位址或 DNS 名稱。
  2. 在左側導覽列中,依序選取「API」>「環境設定」>「目標伺服器」
  3. 選取所需環境,例如「test」或「prod」
  4. 如要建立目標伺服器:
    1. 按一下 [編輯]
    2. 按一下「+ 目標伺服器」
    3. 輸入目標伺服器的名稱、主機和通訊埠。

      例如:

      • 名稱:target1
      • 主機:1.mybackendservice.com
      • 通訊埠:80
    4. 選取「已啟用」,啟用目標伺服器。
    5. 按一下 [儲存]
  5. 如要編輯目標伺服器,請按照下列步驟操作:
    1. 按一下 [編輯]
    2. 編輯目標伺服器值。
    3. 按一下 [儲存]
  6. 如要刪除目標伺服器:
    1. 按一下 [編輯]
    2. 按一下「刪除」

使用 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。 定義兩個 TargetServer,提供 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 呼叫,擷取環境中的 TargetServer 清單:

$ 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,在具名 TargetServer 之間進行負載平衡

現在您有兩個可用的 TargetServer,可以修改 TargetEndpoint HTTP 連線設定,依名稱參照這兩個 TargetServer:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

上述設定是負載平衡最基本的設定。負載平衡器支援三種負載平衡演算法:循環配置、加權和最少連線。預設演算法為「循環式」。由於上述設定未指定任何演算法,API Proxy 傳送至後端伺服器的外送要求會交替使用 target1 和 target2。

<Path> 元素會形成所有目標伺服器的 TargetEndpoint URI 的 basepath。只有在使用 <LoadBalancer> 時才會用到。否則系統會忽略。在上述範例中,抵達「target1」的要求會是 http://target1/test,其他目標伺服器也是如此。

設定負載平衡器選項

您可以在負載平衡器和 TargetServer 層級使用負載平衡和容錯移轉選項,調整可用性。本節將說明這些選項。

演算法

設定 <LoadBalancer> 使用的演算法。可用的演算法包括 RoundRobinWeightedLeastConnections,以下將分別說明。

round robin

預設演算法 (循環式) 會依伺服器在目標端點 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。

最少連線

如果負載平衡器設定為使用最少連線演算法,系統會將連出要求轉送至開啟的 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> 元素新增至負載平衡器設定。Edge 也會將含有這些代碼的回應視為失敗。

在下列範例中,五次要求失敗後 (包括來自目標伺服器的部分 5XX 回應),系統會從輪替中移除 target1

<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,但未設定健康狀態監控器,Apigee 會在偵測到第一次失敗時,自動將目標伺服器從輪替中移除。Apigee 會每五分鐘檢查一次目標伺服器的健康狀態,並在伺服器正常回應時,將其放回輪替。

重試

如果啟用重試功能,只要發生回應失敗 (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,請使用與 TargetEndpoints 相同的 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 到後端 (Cloud 和 Private Cloud) 設定 TLS」。

TargetServer 結構定義

如要查看 TargetServer 和其他實體的結構定義,請前往 GitHub

健康狀態監控功能

健康狀態監控功能會主動輪詢 TargetServer 設定中定義的後端服務網址,有助於改善負載平衡設定。啟用健康狀態監控後,如果 HealthMonitor 判斷 TargetServer 處於啟用狀態,系統就會自動將失敗的 TargetServer 放回輪替。

健康狀態監控功能適用於 <MaxFailures>。如果未啟用健康狀態監控,<MaxFailures> 會指定從 API Proxy 到 TargetServer 的失敗要求數,導致要求重新導向至其他 TargetServer。在重新部署 Proxy 之前,系統會將失敗的 TargetServer 從輪替中移除。

啟用健康狀態監控後,失敗的 TargetServer 會自動放回輪替,不需要重新部署 Proxy。

HealthMonitor 會做為簡單的用戶端,透過 TCP 或 HTTP 叫用後端服務:

  • TCP 用戶端只會確保可以開啟通訊端。
  • 您會設定 HTTP 用戶端,向後端服務提交有效的 HTTP 要求。您可以定義 HTTP GET、PUT、POST 或 DELETE 作業。HTTP 監控器呼叫的回應必須與 <SuccessResponse> 區塊中設定的設定相符。

成功和失敗

啟用健康狀態監控後,Edge 會開始將健康狀態檢查傳送至目標伺服器。健康狀態檢查是傳送至目標伺服器的要求,可判斷目標伺服器是否正常運作。

健康狀態檢查可能有以下兩種結果:

  • 成功:如果健康狀態檢查成功,目標伺服器就會視為健康狀態良好。這通常是因為下列一或多項原因:
    • 目標伺服器會接受指定通訊埠的新連線,回應該通訊埠的要求,然後在指定時間範圍內關閉通訊埠。目標伺服器的回應包含「Connection: close」
    • 目標伺服器會以 200 (OK) 或您認為可接受的其他 HTTP 狀態碼,回應健康狀態檢查要求。
    • 目標伺服器會回應健康狀態檢查要求,並傳送與預期郵件內文相符的郵件內文。

    當 Edge 判斷伺服器健康狀態良好時,就會繼續或恢復傳送要求。

  • 失敗:目標伺服器可能會因健康狀態檢查類型而以不同方式失敗。如果目標伺服器發生下列情況,系統可能會記錄失敗:
    • 拒絕從 Edge 連線至健康狀態檢查埠。
    • 未在指定時間內回應健康狀態檢查要求。
    • 傳回的 HTTP 狀態碼異常。
    • 回覆的郵件內文與預期郵件內文不符。

    如果目標伺服器未通過健康狀態檢查,Edge 會增加該伺服器的失敗次數。如果該伺服器的失敗次數達到或超過預先定義的門檻 (<MaxFailures>),Edge 就會停止傳送要求至該伺服器。

啟用 HealthMonitor

如要建立 HealthMonitor,請將 <HealthMonitor> 元素新增至 Proxy 的 TargetEndpoint HTTPConnection 設定。您無法在 UI 中執行這項操作。您需要建立 Proxy 設定,然後以 ZIP 檔案格式上傳至 Edge。Proxy 設定是 API Proxy 各個層面的結構化說明。Proxy 設定包含預先定義目錄結構中的 XML 檔案。詳情請參閱 API Proxy 設定參考資料

簡單的 HealthMonitor 會定義 IntervalInSec,並搭配 TCPMonitor 或 HTTPMonitor。<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 設定元素的 HealthMonitor

下表說明 TCPMonitor 設定元素:

名稱 說明 預設 是否必要?
IsEnabled 啟用或停用 HealthMonitor 的布林值。 false
IntervalInSec 每次輪詢 TCP 要求之間的時間間隔 (以秒為單位)。 0
ConnectTimeoutInSec 必須建立與 TCP 連接埠的連線,才算成功。如果在指定間隔內無法連線,系統會將其視為連線失敗,並增加 TargetServer 的負載平衡器失敗次數。 0
Port (選用步驟) 要建立 TCP 連線的通訊埠。如未指定,TCPMonitor 連接埠即為 TargetServer 連接埠。 0

HTTPMonitor

使用 HTTPMonitor 的範例 HealthMonitor 會每五秒向後端服務提交一次 GET 要求。下例會在要求訊息中新增 HTTP Basic Authorization 標頭。「回應」設定定義了要與後端服務實際回應進行比較的設定。在下方範例中,預期回應為 HTTP 回應代碼 200 和自訂 HTTP 標頭 ImOK,其值為 YourOK。如果回應不符,負載平衡器設定會將要求視為失敗。

HTTPMonitor 支援設定為使用 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 設定元素的 HealthMonitor

下表說明 HTTPMonitor 設定元素:

名稱 說明 預設 是否必要?
IsEnabled 啟用或停用 HealthMonitor 的布林值。 false
IntervalInSec 每次輪詢要求之間的時間間隔 (以秒為單位)。 0
Request

HealthMonitor 傳送至輪替 TargetServer 的外送要求訊息設定選項。

路徑不支援變數。

N/A
IsSSL 指定是否要使用 HTTPS (安全 HTTP) 監控連線。

可能的值:
  • true:使用 HTTPS。
  • false:使用 HTTP。
  • 未指定:使用目標伺服器設定。
false
ConnectTimeoutInSec TCP 連線交握必須在幾秒內完成,才算成功連線至 HTTP 服務。如果在指定間隔內無法連線,系統會將其視為失敗,並增加 TargetServer 的 LoadBalancer 失敗次數。 0
SocketReadTimeoutInSec 資料必須在幾秒內從 HTTP 服務讀取,才算成功。如果在指定間隔內無法讀取,系統會將其視為失敗,並增加 TargetServer 的 LoadBalancer 失敗次數。 0
Port 將建立與後端服務的 HTTP 連線的通訊埠。 N/A
Verb 用於每個輪詢 HTTP 要求至後端服務的 HTTP 動詞。 N/A
Path 附加至 TargetServer 中定義網址的路徑。使用路徑元素在 HTTP 服務上設定「輪詢端點」。 N/A

IncludeHealthCheckIdHeader

可讓您追蹤上游系統的健康檢查要求。IncludeHealthCheckIdHeader 接受布林值,預設為 false。如果設為 true,則會有名為 X-Apigee-Healthcheck-IdHeader,並注入健康狀態檢查要求。標頭的值會動態指派,格式為 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 要求不需要這個元素。 N/A
SuccessResponse 輪詢後端服務產生的連入 HTTP 回應訊息比對選項。不相符的回應會使失敗次數增加 1。 N/A
ResponseCode 預期從輪詢的 TargetServer 收到的 HTTP 回應代碼。如果代碼與指定代碼不同,就會導致失敗,並增加輪詢後端服務的計數。您可以定義多個 ResponseCode 元素。 N/A
Headers 一或多個 HTTP 標頭和值的清單,預期會從輪詢的後端服務收到。如果回應中的任何 HTTP 標頭或值與指定項目不同,就會導致失敗,且輪詢的 TargetServer 計數會增加 1。您可以定義多個 Header 元素。 N/A