跨多个后端服务器进行负载均衡

您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。 信息

Apigee Edge 内置了在多个后端服务器实例之间对负载均衡和故障切换的支持，从而提高 API 的可用性。

TargetServer 配置将具体的端点网址与 TargetEndpoint 配置分离。在 TargetEndpoint HTTPConnection 中按名称引用每个 TargetServer。您可以配置一个或多个已命名的 TargetServer，而不是在配置中定义具体的网址，如TargetEndpoint 部分所述。

TargetServer 定义包括名称、主机和端口，还带有其他元素指示 TargetServer 已启用还是已停用。

视频

观看以下视频，详细了解如何使用目标服务器进行 API 路由和负载均衡

TargetServer 配置示例

以下代码定义了一个目标服务器：

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

TargetServer 配置元素

下表介绍了用于创建和配置 TargetServer 的元素：

使用界面管理目标服务器

管理目标服务器，如下所述。

使用 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" ]

现在，在测试环境中部署的 API 代理可以使用两个 TargetServer。为了在这些 TargetServer 之间实现流量负载平衡，您需要将 API 代理的目标端点中的 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 代理到后端服务器的出站请求将在 target1 和 target 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 配置成比例的流量负载。加权负载平衡器按照与每个 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 代理发送到 TargetServer（它将请求重定向至另一个 TargetServer）的失败请求数量上限。

响应失败意味着 Apigee 不会收到目标服务器的任何响应。当出现这种情况时，失败计数器会加 1。

但是，当 Apigee 确实收到目标的响应时，即使响应为 HTTP 错误（例如 500），也算作目标服务器的响应，并且失败计数器会被重置。为了帮助失败计数器在错误的 HTTP 响应（例如 500）下也加 1，以便尽快让运行状况不佳的服务器停止进行负载均衡轮替，您可以将带有 <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，根据该 HealthMonitor 的配置，Apigee 会在目标再次正常运行后，自动将 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> 标记不支持指定连接协议。Edge 向后端服务发出 HTTPS 请求的单向 TLS/SSL 的 TargetServer 定义如下所示：

<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 到后端（云和私有云）的 TLS。

TargetServer 架构

请参阅 GitHub 上的 TargetServer 和其他实体的架构。

运行状况监控

借助运行状况监控，您可以主动轮询 TargetServer 配置中定义的后端服务网址，以增强负载平衡配置。启用运行状况监控功能后，当 HealthMonitor 确定 TargetServer 处于活动状态时，发生故障的 TargetServer 将会自动重新置于轮替中。

运行状况监控与 <MaxFailures> 配合工作。如果未启用运行状况监控功能，则 <MaxFailures> 会指定从 API 代理发送到 TargetServer（它将请求重定向至另一个 TargetServer）的失败请求数量上限。然后，在您重新部署代理之前，发生故障的 TargetServer 会停止轮替。

启用运行状况监控功能后，发生故障的 TargetServer 会自动重新置于轮替中，无需重新部署代理。

HealthMonitor 可充当一个简单的客户端，通过 TCP 或 HTTP 调用后端服务：

• TCP 客户端仅确保能够打开套接字。
• 您可将 HTTP 客户端配置为向后端服务提交有效的 HTTP 请求。您可以定义 HTTP GET、PUT、POST 或 DELETE 操作。HTTP 监视器调用的响应必须与 <SuccessResponse> 块中配置的设置相匹配。

成功和失败

启用健康状况监控功能后，Edge 会开始向目标服务器发送健康检查。健康检查是发送到目标服务器的请求，用于确定目标服务器健康状况是否良好。

健康检查可能产生两种结果：

• 成功：成功进行健康检查后，目标服务器被视为健康状况良好。通常，以下一项或多项原因导致此结果：
  • 目标服务器接受与指定端口的新连接，响应该端口上的请求，然后在指定时间范围内关闭端口。目标服务器返回的响应包含“Connection: close”
  • 目标服务器将响应健康检查请求，返回状态代码 200 (OK) 或您认为可以接受的其他 HTTP 状态代码。
  • 目标服务器将响应健康检查请求，返回与预期消息正文相匹配的消息正文。

  当 Edge 认为服务器运行状况良好时，Edge 会继续向服务器发送请求。

• 失败：目标服务器因各种原因而未通过健康检查，具体取决于检查类型。当目标服务器出现以下情况时，系统会记录失败：
  • 拒绝从 Edge 连接到健康检查端口。
  • 在指定时间段内未响应健康检查请求。
  • 返回意外的 HTTP 状态代码。
  • 回复消息正文与预期消息正文不匹配。

  当目标服务器未通过健康检查时，Edge 会将服务器的失败计数加 1。如果该服务器的失败次数达到或超过预定义的阈值 (<MaxFailures>)，则 Edge 会停止向该服务器发送请求。

启用 HealthMonitor

如需创建 HealthMonitor，请将 <HealthMonitor> 元素添加到代理的 TargetEndpoint 的 HTTPConnection 配置中。您不能在界面中执行此操作。但是您可以创建一个代理配置，并将其作为 ZIP 文件上传到 Edge。代理配置是 API 代理各个方面的结构化描述。代理配置包括预定义目录结构中的 XML 文件。如需了解详情，请参阅 API 代理配置参考文档。

简单的 HealthMonitor 定义了 IntervalInSec 与 TCPMonitor 或 HTTPMonitor 的组合。<MaxFailures> 元素指定从 API 代理发送到 TargetServer（它将请求重定向至另一个 TargetServer）的失败请求数量上限。默认情况下，<MaxFailures> 为 0，表示 Edge 不执行任何纠正操作。配置 Health Monitor 时，请确保将 <TargetEndpoint> 标记的 <HTTPTargetConnection> 标记中的 <MaxFailures> 设置为非零值。

TCPMonitor

以下配置定义了一个 HealthMonitor，它通过每 5 秒在端口 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 配置元素：

HTTPMonitor

使用 HTTPMonitor 的示例 HealthMonitor 每 5 秒向后端服务提交一次 GET 请求。以下示例将 HTTP Basic Authorization 标头添加到请求消息中。响应配置定义了要与后端服务的实际响应进行比较的设置。在以下示例中，预期响应是 HTTP 响应代码 200，以及其值为 YourOK 的自定义 HTTP 标头 ImOK。如果响应不匹配，则负载均衡器配置将请求视为失败。

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 配置元素：