跨後端伺服器負載平衡

本頁適用於 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 說明文件。

Apigee 提供多個後端伺服器執行個體的負載平衡和備援功能內建支援，進而提升 API 的可用性。

目標伺服器會將具體端點網址與目標端點設定分離。您可以設定一或多個命名目標伺服器，而非在設定中定義具體網址。然後，在目標端點 HTTPConnection 中，以名稱參照每個目標伺服器。

影片

請觀看下列影片，進一步瞭解如何使用目標伺服器進行 API 路由和負載平衡

關於目標伺服器設定

目標伺服器設定包含名稱、主機、通訊協定和通訊埠，以及用於指出目標伺服器是否已啟用的額外元素。目標伺服器也可以有選用的 <sSLInfo> 物件。

以下程式碼提供目標伺服器設定的範例：

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

如要進一步瞭解 TargetServers API，請參閱 organizations.environments.targetservers。

請參閱 GitHub 上的 TargetServer 和其他實體的結構定義。

建立目標伺服器

請按照下列各節所述，使用 Apigee UI 或 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",
  }'
 

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

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
}

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

[ "target2", "target1" ]

設定目標端點，以便跨指定目標伺服器進行負載平衡

有了兩個可用的目標伺服器，您可以修改目標端點的 <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。

不過，如果 Apigee 確實收到目標的回應，即使回應是 HTTP 錯誤 (例如 404 或 500)，也視為來自目標伺服器的回應，並且重設失敗計數器。為確保錯誤的 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「服務暫時無法使用」錯誤。

路徑

Path 定義 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"
    }
  }'

健康狀態監控功能

透過健康狀態監控功能，您可以主動輪詢目標伺服器設定中定義的後端服務網址，以改善負載平衡設定。啟用健康狀態監控功能後，無法連線或傳回錯誤回應的目標伺服器會標示為不健康。當健康監控器判定目標伺服器處於活動狀態時，就會自動將失敗的目標伺服器重新納入輪替。不需要重新部署 Proxy。

健康狀態監控器會充當簡易的用戶端，透過 TCP 或 HTTP 叫用後端服務：

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

成功和失敗

啟用健康狀態監控功能後，Apigee 就會開始將健康狀態檢查傳送至目標伺服器。健康狀態檢查是傳送至目標伺服器的要求，用於判斷目標伺服器是否處於正常狀態。

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

• 成功：如果健康狀態檢查成功，系統會將目標伺服器視為健康狀態良好。這通常是下列一或多項原因造成的結果：
  • 目標伺服器會接受連線至指定通訊埠的新連線，回應該通訊埠上的要求，然後在指定時間範圍內關閉通訊埠。目標伺服器的回應包含 Connection: close
  • 目標伺服器會以 200 (OK) 或其他您認為可接受的 HTTP 狀態碼回應健康檢查要求。
  • 目標伺服器會以符合預期的訊息主體回應健康狀態檢查要求。

  當 Apigee 判斷伺服器處於正常狀態時，Apigee 會繼續或恢復傳送要求。

• 失敗：目標伺服器可能會因檢查類型不同，以不同方式失敗健康狀態檢查。當目標伺服器發生下列情況時，系統會記錄失敗：
  • 拒絕 Apigee 連線至健康狀態檢查端口。
  • 未在指定時間內回應健康狀態檢查要求。
  • 傳回非預期的 HTTP 狀態碼。
  • 回覆的郵件內文與預期的郵件內文不符。

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

啟用健康監控器

如要為 API Proxy 建立健康監控器，請將 <HealthMonitor> 元素新增至 Proxy 的目標端點 <HTTPTargetConnection 元素設定。

您無法在使用者介面中建立健康監控器。您可以建立 Proxy 設定，並以 ZIP 檔案格式上傳至 Apigee。Proxy 設定是 API Proxy 所有層面的結構化說明。代理程設定包含預先定義目錄結構中的 XML 檔案。詳情請參閱「API Proxy 設定參考資料」。

<HealthMonitor> 設定元素

下表說明 <HealthMonitor> 設定元素：

除了這些元素之外，啟用健康監控功能時，您必須將 <TargetEndpoint> 元素的 <HTTPTargetConnection> 區塊中的 <MaxFailures> 元素設為大於 0 的值。<MaxFailures> 可用於指定從 API Proxy 傳送至目標伺服器的失敗要求數量上限，這項限制會在要求重新導向至其他目標伺服器之前生效。

預設情況下，<MaxFailures> 為 0，表示 Apigee 不會採取任何修正動作。設定健康監控器時，請務必將 <MaxFailures> 設為非零值。

使用 TCP 監控器的健康監控器

以下設定中所述的健康狀態監控器範例會使用 TCP 監控器，每五秒就開啟一次通訊埠 80 的連線，以便輪詢每個目標伺服器。(Port 為選填欄位。如果未指定，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> 設定元素：

使用 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> 設定元素：

<HTTPMonitor>/<Request> 設定元素

健康狀態監控器傳送至輪替中的目標伺服器的外寄要求訊息設定選項。請注意，<Request> 為必要元素。

<HTTPMonitor>/<SuccessResponse> 設定元素

(選用) 比對選項，適用於由輪詢後端服務產生的 HTTP 回應訊息。不相符的回應會使失敗計數增加 1。