本頁內容適用於 Apigee 和 Apigee Hybrid。
查看
Apigee Edge 說明文件。
Apigee 內建負載平衡和容錯移轉功能,可跨多個後端伺服器執行個體運作,提升 API 的可用性。
目標伺服器會將具體端點網址與目標端點設定分離。您可以在設定中定義一或多個具名目標伺服器,不必定義具體網址。然後,每個目標伺服器都會在目標端點 HTTPConnection 中依名稱參照。
影片
觀看下列影片,進一步瞭解如何使用目標伺服器進行 API 轉送和負載平衡
影片 | 說明 |
---|---|
使用目標伺服器進行負載平衡 | 在目標伺服器之間平衡 API 負載。 |
根據環境使用目標伺服器進行 API 路由 | 根據環境將 API 導向至其他目標伺服器。 |
關於目標伺服器設定
目標伺服器設定包含名稱、主機、通訊協定和通訊埠,以及指出目標伺服器是否已啟用或停用的額外元素。目標伺服器也可以有選用的
<sSLInfo>
物件。
以下程式碼提供目標伺服器設定範例:
{ "name": "target1", "host": "1.mybackendservice.com", "protocol": "http", "port": "80", "isEnabled": "true" }
如要進一步瞭解 TargetServers API,請參閱 organizations.environments.targetservers。
如要查看 TargetServer 和其他實體的結構定義,請前往 GitHub。
建立目標伺服器
請按照下列各節所述,使用 Apigee UI 或 API 建立目標伺服器。
Cloud 控制台中的 Apigee
如要使用 Cloud 控制台中的 Apigee 建立目標伺服器,請按照下列步驟操作:
在 Google Cloud 控制台中,前往「管理」>「環境」頁面。
- 選取要定義新目標伺服器的環境。
- 按一下窗格頂端的「目標伺服器」。
- 按一下「+ 建立目標伺服器」。
在提供的欄位中輸入名稱、主機、通訊協定和通訊埠。「通訊協定」選項包括:適用於 REST 型目標伺服器的「HTTP」、適用於 gRPC 型目標伺服器的「gRPC - Target」,以及「gRPC - External callout」。如要瞭解 gRPC Proxy 支援,請參閱建立 gRPC API Proxy。
您也可以選擇選取「Enable SSL」(啟用 SSL)。請參閱安全資料傳輸層 (SSL) 憑證總覽。
- 點選「建立」。
傳統版 Apigee
如要使用傳統版 Apigee UI 建立目標伺服器,請按照下列步驟操作:
- 登入 Apigee 使用者介面。
- 依序選取「管理」>「環境」>「TargetServers」。
- 從「環境」下拉式清單中,選取要定義新目標伺服器的環境。
Apigee 使用者介面會顯示所選環境中的目前目標伺服器清單:
- 按一下「+ 目標伺服器」,即可將新的目標伺服器新增至所選環境。
系統會顯示「新增目標伺服器」對話方塊:
- 按一下「已啟用」,啟用新的目標伺服器。 定義。
在提供的欄位中輸入名稱、主機、通訊協定和通訊埠。「通訊協定」選項為「HTTP」或「GRPC」。
您也可以選取「SSL」SSL核取方塊。如要進一步瞭解這些欄位,請參閱「TargetServers」(4MV4D 影片)。
- 按一下「新增」。
Apigee 會建立新的目標伺服器定義。
- 建立新的目標伺服器後,您可以編輯 API Proxy,並變更
<HTTPTargetConnection>
元素來參照新的定義。
Apigee API
以下各節提供使用 Apigee API 建立及列出目標伺服器的範例。
詳情請參閱 TargetServers API。
使用 API 在環境中建立目標伺服器
如要建立名為 target1
的目標伺服器,並在通訊埠 80
上連線至 1.mybackendservice.com
,請使用下列 API 呼叫:
curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \ -X POST \ -H "Content-Type:application/json" \ -H "Authorization: Bearer $TOKEN" \ -d ' { "name": "target1", "host": "1.mybackendservice.com", "protocol": "http", "port": "80", "isEnabled": "true", }'
其中 $TOKEN
會設為您的 OAuth 2.0 存取權杖,如「取得 OAuth 2.0 存取權杖」一文所述。如要瞭解本範例使用的 curl
選項,請參閱「使用 curl」。如要瞭解可使用的環境變數,請參閱為 Apigee API 要求設定環境變數。
以下是回應範例:
{ "host" : "1.mybackendservice.com", "protocol": "http", "isEnabled" : true, "name" : "target1", "port" : 80 }
使用下列 API 呼叫建立第二個目標伺服器。 定義兩個目標伺服器時,您會提供兩個目標端點可用於負載平衡的網址:
curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \ -X POST \ -H "Content-Type:application/json" \ -H "Authorization: Bearer $TOKEN" \ -d ' { "name": "target2", "host": "2.mybackendservice.com", "protocol": "http", "port": "80", "isEnabled": "true", }'
以下是回應範例:
{ "host" : "2.mybackendservice.com", "protocol": "http", "isEnabled" : true, "name" : "target2", "port" : 80 }
使用 API 列出環境中的目標伺服器
如要列出環境中的目標伺服器,請使用下列 API 呼叫:
curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \ -H "Authorization: Bearer $TOKEN"
以下是回應範例:
[ "target2", "target1" ]
現在,部署在 test
環境中的 API Proxy 有兩個目標伺服器可供使用。如要在這些目標伺服器之間進行流量負載平衡,請在 API Proxy 的目標端點中設定 HTTP 連線,以使用目標伺服器。
設定目標端點,在具名目標伺服器之間進行負載平衡
現在您有兩個可用的目標伺服器,可以修改目標端點的 <HTTPTargetConnection>
元素,依名稱參照這兩個目標伺服器:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
上述設定是最基本的負載平衡設定。負載平衡器支援三種負載平衡演算法:RoundRobin
、Weighted
和 LeastConnections
。預設演算法為「循環式」。由於上述設定未指定任何演算法,API Proxy 傳送至後端伺服器的外送要求會交替使用 target1
和 target2
。
<Path>
元素會形成所有目標伺服器的目標端點 URI 的 basepath。只有在使用 <LoadBalancer>
時才會用到。否則系統會忽略。在上述範例中,抵達 target1
的要求會轉送至 http://target1/test
,其他目標伺服器也是如此。
設定負載平衡器選項
如要調整可用性,請在負載平衡器和目標伺服器層級設定負載平衡和容錯移轉選項,詳情請參閱下列章節。
演算法
設定 <LoadBalancer>
使用的演算法。可用的演算法包括 RoundRobin
、Weighted
和 LeastConnections
,以下將分別說明。
循環制
預設演算法 (循環式) 會依伺服器在目標端點 HTTP 連線中列出的順序,將要求轉送至每個目標伺服器。例如:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
加權
加權負載平衡演算法可讓您為目標伺服器設定流量負載比例。加權 LoadBalancer 會根據每個目標伺服器的權重,將要求直接分配至目標伺服器。因此,加權演算法會要求你為每個目標伺服器設定 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 連線最少的目標伺服器。例如:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
失敗次數上限
API Proxy 對目標伺服器發出的要求失敗次數上限,超過這個上限後,系統就會將要求重新導向至其他目標伺服器。
如果回應失敗,表示 Apigee 未收到目標伺服器的任何回應。發生這種情況時,失敗計數器會增加 1。
不過,即使回應是 HTTP 錯誤 (例如 404
或 500
),只要 Apigee 收到目標的回應,就會視為目標伺服器傳回回應,並重設失敗計數器。為確保不良的 HTTP 回應 (例如 500
) 也會增加失敗計數器,盡快將不正常的伺服器從負載平衡輪替中移除,您可以在負載平衡器設定中新增 <ServerUnhealthyResponse>
元素,並包含 <ResponseCode>
子項元素。Apigee 也會將含有這些代碼的回應視為失敗。
在下列範例中,target1
在五次要求失敗後會從輪替中移除,包括 404
和目標伺服器的一些 5XX
回應。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> <ServerUnhealthyResponse> <ResponseCode>404</ResponseCode> <ResponseCode>500</ResponseCode> <ResponseCode>502</ResponseCode> <ResponseCode>503</ResponseCode> </ServerUnhealthyResponse> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
MaxFailures 的預設值為 0。也就是說,Apigee 會針對每個要求嘗試連線至目標,且絕不會從輪替中移除目標伺服器。
建議搭配健康監控器使用 MaxFailures > 0。 如果將 MaxFailures 設為大於 0,目標伺服器在失敗次數達到指定次數時,就會從輪替中移除。如果已設定健康狀態監控器,Apigee 會在目標伺服器恢復運作後,根據該健康狀態監控器的設定,自動將目標伺服器放回輪替。詳情請參閱「健康狀態監控」。
請注意,一般 API 呼叫和健康狀態監控器發起的呼叫都會計入 MaxFailures 數。
另請注意,每個目標伺服器的執行失敗次數會以負載平衡器為單位進行維護。舉例來說,假設 Proxy 有兩個目標端點,每個端點都有負載平衡器,且兩個負載平衡器都設定為使用同一組目標伺服器。在這種情況下,一個目標端點的失敗只會計入對應的負載平衡器。不會影響其他目標端點的輪替。
或者,如果您設定 MaxFailures > 0,但未設定健康狀態監控器,Apigee 會在偵測到第一次失敗時,自動將目標伺服器從輪替中移除。Apigee 會每五分鐘檢查目標伺服器的健康狀態,並在伺服器正常回應時,將其放回輪替。
重試
如果啟用重試功能,只要發生回應失敗 (I/O 錯誤或 HTTP 逾時),或收到的回應符合 <ServerUnhealthyResponse>
設定的值,系統就會重試要求。如要進一步瞭解如何設定 <ServerUnhealthyResponse>
,請參閱上方的「最多失敗次數」。
根據預設,<RetryEnabled>
會設為 true
。設為 false
即可停用重試。
例如:
<RetryEnabled>false</RetryEnabled>
IsFallback
您可以將一個 (且只能一個) 目標伺服器設為備援伺服器。負載平衡器不會使用備用伺服器,直到負載平衡器從輪替中移除所有其他目標伺服器為止。發生這種情況時,所有流量都會轉送至備援伺服器,直到其他目標伺服器回報健康狀態,並重新加入輪替為止。例如:
<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>
上述設定會導致 target1
和 target2
之間的循環配置資源負載平衡,直到 target1
和 target2
都無法使用為止。如果 target1
和 target2
無法使用,所有流量都會改為傳送至 target3
。
如果備援伺服器健康狀態不良,Apigee 就不會將流量轉送至該伺服器。
API 呼叫會改為傳回 503
「服務暫時無法使用」錯誤。
路徑
路徑定義 URI 片段,附加至目標伺服器發給後端伺服器的所有要求。
這個元素接受常值字串路徑或訊息範本。訊息範本可讓您在執行階段替換變數字串。舉例來說,在下列目標端點定義中,路徑會使用 {mypath}
的值:
<HTTPTargetConnection> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <LoadBalancer> <Server name="testserver"/> </LoadBalancer> <Path>{mypath}</Path> </HTTPTargetConnection>
設定 TLS/SSL 的目標伺服器
如果您使用目標伺服器定義後端服務,且後端服務要求連線使用 HTTPS 通訊協定,則必須在目標伺服器定義中啟用 TLS/SSL。這是必要步驟,因為 host
標記不允許您指定連線通訊協定。
設定單向 TLS/SSL
使用下列設定定義具有單向 TLS/SSL 的目標伺服器。在本範例中,Apigee 會向後端服務發出 HTTPS 要求:
{ "name": "target1", "host": "mocktarget.apigee.net", "protocol": "http", "port": "443", "isEnabled": "true", "sSLInfo": { "enabled": "true" } }
設定嚴格的安全資料傳輸層 (SSL) 強制執行
如要在目標伺服器定義中指定嚴格的 SSL 強制執行,請在 sSLInfo
區塊中將 enforce
設為 true
,如以下範例所示:
{ "name": "target1", "host": "mocktarget.apigee.net", "protocol": "http", "port": "443", "isEnabled": "true", "sSLInfo": { "enabled": "true", "enforce": "true" } }
設定雙向 TLS/SSL
如果後端服務需要雙向或相互 TLS/SSL,您可以為目標伺服器設定與目標端點相同的 TLS/SSL 設定:
{ "name": "TargetServer 1", "host": "www.example.com", "protocol": "http", "port": "443", "isEnabled": "true", "sSLInfo": { "enabled": "true", "clientAuthEnabled": "true", "keyStore": "keystore-name", "keyAlias": "keystore-alias", "trustStore": "truststore-name", "ignoreValidationErrors": "false", "ciphers": [] } }
使用 API 設定嚴格的 SSL
如要使用 API 呼叫建立目標伺服器,並嚴格執行 SSL,請按照下列步驟操作:
curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \ -X POST \ -H "Content-Type:application/json" \ -H "Authorization: Bearer $TOKEN" \ -d ' { "name": "TargetServer 1", "host": "www.example.com", "protocol": "http", "port": 443, "isEnabled": true, "sSLInfo": { "enabled":true, "enforce":true, "clientAuthEnabled":true, "keyStore":"keystore-name", "keyAlias":"keystore-alias", "ciphers":[], "protocols":[], "clientAuthEnabled":true, "ignoreValidationErrors":false, "trustStore":"truststore-name" } }'
健康狀態監控功能
健康狀態監控功能會主動輪詢目標伺服器設定中定義的後端服務 URL,有助於改善負載平衡設定。啟用健康狀態監控後,系統會將無法連線或傳回錯誤回應的目標伺服器標示為健康狀態不良。當健康狀態監控器判定目標伺服器處於啟用狀態時,系統會自動將失敗的目標伺服器放回輪替。不需要重新部署 Proxy。
健康狀態監控器會充當簡易用戶端,透過 TCP 或 HTTP 叫用後端服務:
- TCP 用戶端只會確保可以開啟通訊端。
- 您會設定 HTTP 用戶端,向後端服務提交有效的 HTTP 要求。您可以定義 HTTP
GET
、PUT
、POST
或DELETE
作業。HTTP 監控器呼叫的回應必須符合<SuccessResponse>
區塊中設定的設定。
成功和失敗
啟用健康狀態監控功能後,Apigee 會開始將健康狀態檢查傳送至目標伺服器。健康狀態檢查是傳送至目標伺服器的要求,用於判斷目標伺服器是否正常運作。
健康狀態檢查可能有以下兩種結果:
- 成功:健康狀態檢查成功時,目標伺服器會視為健康狀態良好。這通常是下列一或多項原因所致:
- 目標伺服器會接受指定通訊埠的新連線,回應該通訊埠的要求,然後在指定時間範圍內關閉通訊埠。目標伺服器的回應包含
Connection: close
- 目標伺服器會以
200 (OK)
或您認為可接受的其他 HTTP 狀態碼,回應健康狀態檢查要求。 - 目標伺服器會以符合預期訊息主體的訊息主體,回應健康狀態檢查要求。
Apigee 判斷伺服器健康狀態良好時,會繼續或恢復傳送要求。
- 目標伺服器會接受指定通訊埠的新連線,回應該通訊埠的要求,然後在指定時間範圍內關閉通訊埠。目標伺服器的回應包含
- 失敗:目標伺服器可能會因健康狀態檢查類型而以不同方式失敗。如果目標伺服器發生下列情況,系統可能會記錄失敗:
- 拒絕 Apigee 連線至健康狀態檢查埠。
- 未在指定時間內回應健康狀態檢查要求。
- 傳回非預期的 HTTP 狀態碼。
- 回覆的郵件內文與預期郵件內文不符。
如果目標伺服器未通過健康狀態檢查,Apigee 會增加該伺服器的失敗次數。如果該伺服器的失敗次數達到或超過預先定義的門檻 (
<MaxFailures>
),Apigee 就會停止傳送要求至該伺服器。
啟用健康狀態監控器
如要為 API Proxy 建立健康狀態監控器,請將 <HealthMonitor>
元素新增至 Proxy 目標端點的 <HTTPTargetConnection
元素設定。
您無法在 UI 中建立健康狀態監控器,您需要建立 Proxy 設定,然後以 ZIP 檔案形式上傳至 Apigee。Proxy 設定是 API Proxy 各個層面的結構化說明。Proxy 設定包含預先定義目錄結構中的 XML 檔案。詳情請參閱「API Proxy 設定參考資料」。
<HealthMonitor>
設定元素
下表說明 <HealthMonitor>
設定元素:
名稱 | 說明 | 預設 | 是否必要 |
---|---|---|---|
IsEnabled |
啟用或停用健康狀態監控功能的布林值。 | false | 否 |
IntervalInSec |
每次輪詢 TCP 或 HTTP 要求之間的時間間隔 (以秒為單位)。 | 0 | 是 |
HTTPMonitor 或 TCPMonitor |
用於輪詢目標伺服器的 TCP 或 HTTP 用戶端定義。 | 不適用 | 是 |
除了這些元素外,如要啟用健康狀態監控器,您還必須將 <TargetEndpoint>
元素 <HTTPTargetConnection>
區塊中的 <MaxFailures>
元素設為大於 0 的值。<MaxFailures>
用於指定 API Proxy 可發出至目標伺服器的失敗要求數量上限,超過上限後,要求就會重新導向至其他目標伺服器。
預設值 <MaxFailures>
為 0,表示 Apigee 不會採取任何修正措施。設定健康狀態監控器時,請務必將 <MaxFailures>
設為非零值。
使用 TCP 監控器進行健康狀態監控
下列設定中說明的健康狀態監控器範例會使用 TCP 監控器,每五秒開啟一次通訊埠 80 的連線,輪詢每個目標伺服器。(通訊埠為選填欄位。如未指定,TCP 監控通訊埠就是目標伺服器通訊埠。
在這個健康狀態監控器設定範例中:
- 如果連線失敗或連線時間超過 10 秒,該目標伺服器的失敗次數就會增加 1。
- 如果連線成功,目標伺服器的失敗次數就會重設為 0。
您可以將健康狀態監控器新增為目標端點 <HTTPTargetConnection>
元素的子項,如下所示:
<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> </TargetEndpoint>
<TCPMonitor>
設定元素
下表說明 <TCPMonitor>
設定元素:
名稱 | 說明 | 預設 | 是否必要 |
---|---|---|---|
ConnectTimeoutInSec |
必須在指定時間內建立 TCP 通訊埠連線,才算成功。如果在指定間隔內無法連線,系統會將其視為連線失敗,並增加目標伺服器的負載平衡器失敗次數。 | 0 | 是 |
Port |
(選用步驟) 建立 TCP 連線的通訊埠。如未指定,TCP 監控通訊埠就是目標伺服器通訊埠。 | 0 | 否 |
使用 HTTP 監控器進行健康狀態監控
下列設定中說明的範例健康狀態監控器使用 HTTP 監控器,每五秒向後端服務提交一次 GET
要求,並在要求訊息中加入 HTTP 基本授權標頭。
在這個健康狀態監控器設定範例中:
- 後端服務預期會傳回 HTTP 回應碼
200
。 - 自訂 HTTP 基本授權標頭
ImOK
的預期值為YourOK
。 <UseTargetServerSSLInfo>
元素會設為true
,以便使用目標伺服器<SSLInfo>
區塊中的 SSL 參數。
透過這項設定,系統會將預期的回應代碼和標頭值與後端服務的實際回應進行比較。如果回應不符,負載平衡器設定會將要求視為失敗。
根據預設,健康狀態監控器無法從目標伺服器存取金鑰儲存區、信任儲存區或其他 SSL 參數。
如要啟用健康監控器對這些參數的存取權,以便支援相互 TLS,請在 <Request>
區塊中新增 <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
。
<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> <HTTPMonitor> <Request> <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> <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> </HTTPTargetConnection> </TargetEndpoint>
<HTTPMonitor>
設定元素
下表說明頂層 <HTTPMonitor>
設定元素:
名稱 | 說明 | 預設 | 是否必要 |
---|---|---|---|
Request |
健康狀態監控器傳送至輪替目標伺服器的外寄要求訊息。 | 不適用 | 是 |
SuccessResponse |
(選用) 輪詢後端服務產生的 HTTP 回應訊息比對選項。 | 不適用 | 否 |
<HTTPMonitor> 或 <Request> 設定元素
健康狀態監控器傳送至輪替目標伺服器的外送要求訊息設定選項。請注意,<Request>
是必要元素。
名稱 | 說明 | 預設 | 是否必要 |
---|---|---|---|
ConnectTimeoutInSec |
TCP 連線交握必須在幾秒內完成,HTTP 服務才會視為成功。如果在指定間隔內無法連線,系統會將其視為失敗,並增加目標伺服器的 LoadBalancer 失敗次數。 | 0 | 否 |
SocketReadTimeoutInSec |
資料必須在幾秒內從 HTTP 服務讀取,才算成功。如果在指定間隔內無法讀取,系統會將其視為失敗,並增加目標伺服器的 LoadBalancer 失敗次數。 | 0 | 否 |
Port |
將建立與後端服務的 HTTP 連線的通訊埠。 | 目標伺服器通訊埠 | 否 |
Verb |
用於每個輪詢 HTTP 要求至後端服務的 HTTP 動詞。 | 不適用 | 否 |
Path |
附加至目標伺服器中定義網址的路徑。使用 Path 元素在 HTTP 服務上設定「輪詢端點」。請注意,Path 元素不支援變數。 |
不適用 | 否 |
UseTargetServerSSLInfo |
如果 UseTargetServerSSLInfo 為 true,傳送至目標伺服器的健康狀態監控要求會使用目標伺服器 SSLInfo (「sSLInfo」) 區塊的 SSL 參數。否則,健康狀態監控器將無法使用通訊協定、金鑰儲存區和信任儲存區等 SSL 參數。 |
false | 否 |
| 可讓您追蹤上游系統的健康檢查要求。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 要求不需要這個元素。 |
不適用 | 否 |
Header |
預期從輪詢的後端服務收到一或多個 HTTP 標頭和值。如果回應中的 HTTP 標頭或值與指定項目不同,就會導致失敗,且輪詢目標伺服器的計數會增加 1。您可以定義多個 Header 元素。 | 不適用 | 否 |
IsSSL |
如果為 true,表示健康狀態監控要求會使用 HTTPS 傳送。 | 否 | 否 |
TrustAllSSL |
指定 HTTP 監控檢查是否會自動信任所有 SSL 憑證。 | 否 | 否 |
<HTTPMonitor>/<SuccessResponse> 設定元素
(選用) 輪詢後端服務產生的連入 HTTP 回應訊息比對選項。不相符的回應會使失敗次數增加 1。
名稱 | 說明 | 預設 | 是否必要 |
---|---|---|---|
ResponseCode |
預期從輪詢目標伺服器收到的 HTTP 回應碼。如果代碼與指定代碼不同,就會導致失敗,且輪詢後端服務的計數會遞增。您可以定義多個 ResponseCode 元素。 | 不適用 | 否 |
Header |
預期從輪詢的後端服務收到一或多個 HTTP 標頭和值。如果回應中的 HTTP 標頭或值與指定項目不同,就會導致失敗,且輪詢目標伺服器的計數會增加 1。您可以定義多個 Header 元素。 | 不適用 | 否 |