Эта страница переведена с помощью Cloud Translation API.

Антипаттерн: Балансировка нагрузки с одним целевым сервером, где MaxFailures установлен на ненулевое значение

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Конфигурация TargetEndpoint определяет способ подключения Apigee Edge к серверной службе или API. Он отправляет запросы и получает ответы от серверной службы. Серверной службой может быть сервер HTTP/HTTPS, NodeJS или размещенная цель.

Внутреннюю службу в TargetEndpoint можно вызвать одним из следующих способов:

Прямой URL-адрес HTTP или HTTPS-сервера
ScriptTarget для скрипта Node.js, размещенного в Edge
HostedTarget для NodeJS, развернутого в размещенной целевой среде
Конфигурация таргетсервера

Аналогично, политику вызова службы можно использовать для вызова любой внешней службы из потока прокси-сервера API. Эта политика поддерживает определение целевых URL-адресов HTTP/HTTPS либо непосредственно в самой политике, либо с помощью конфигурации TargetServer.

Конфигурация таргетсервера

Конфигурация TargetServer отделяет конкретные URL-адреса конечных точек от конфигураций TargetEndpoint или политик вызова службы. На TargetServer ссылаются по имени, а не по URL-адресу в TargetEndpoint. Конфигурация TargetServer будет содержать имя хоста внутренней службы, номер порта и другие сведения.

Вот пример конфигурации TargetServer:

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

TargetServer позволяет вам иметь разные конфигурации для каждой среды. Политику TargetEndpoint/Service Callout можно настроить с помощью одного или нескольких именованных серверов TargetServer с помощью LoadBalancer. Встроенная поддержка балансировки нагрузки повышает доступность API и обеспечивает аварийное переключение между настроенными экземплярами внутреннего сервера.

Вот пример конфигурации TargetEndpoint с использованием TargetServers:

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

Макс.Failures

Конфигурация MaxFailures определяет максимальное количество неудачных запросов к целевому серверу, после которого целевой сервер должен быть помечен как отключенный и исключен из ротации для всех последующих запросов.

Пример конфигурации с указанным MaxFailures :

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
       <Server name="target2"/>
       <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

В приведенном выше примере, если пять последовательных запросов для «target1» не удались, то «target1» будет удалена из ротации, и все последующие запросы будут отправлены только в target2.

Антипаттерн

Не рекомендуется использовать один TargetServer в конфигурации LoadBalancer политики TargetEndpoint или Service Callout с ненулевым значением MaxFailures , поскольку это может иметь неблагоприятные последствия.

Рассмотрим следующий пример конфигурации, в которой есть один TargetServer с именем «target1» и значением MaxFailures , равным 5 (ненулевое значение):

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

Если запросы к TargetServer «target1» завершаются неудачно пять раз (количество указано в MaxFailures ), TargetServer выводится из ротации. Поскольку других целевых серверов для переключения при сбое нет, все последующие запросы к прокси-серверу API с этой конфигурацией завершатся ошибкой 503 Service Unavailable .

Даже если TargetServer «target1» вернется в свое нормальное состояние и сможет отправлять успешные ответы, запросы к прокси-серверу API будут продолжать возвращать ошибки 503. Это связано с тем, что Edge не возвращает TargetServer автоматически в ротацию даже после того, как целевой объект снова запущен и работает. Чтобы решить эту проблему, прокси-сервер API необходимо повторно развернуть для Edge, чтобы снова включить TargetServer.

Если та же конфигурация используется в политике вызова службы, то запросы API получат ошибку 500 после того, как запросы к TargetServer «target1» завершатся неудачно 5 раз.

Влияние

Использование одного TargetServer в конфигурации LoadBalancer политики TargetEndpoint или Service Callout с MaxFailures , установленным в ненулевое значение, приводит к следующим последствиям:

Запросы API постоянно завершаются с ошибкой 503/500 (после того, как запросы завершаются неудачно максимальное количество раз), пока прокси-сервер API не будет повторно развернут.
Более длительный простой, так как это сложно и может потребоваться больше времени для диагностики причины этой проблемы (без предварительного знания об этом антипаттерне).

Лучшая практика

Имейте более одного TargetServer в конфигурации LoadBalancer для более высокой доступности.
Всегда определяйте Health Monitor, если для MaxFailures установлено ненулевое значение. Целевой сервер будет исключен из ротации, когда количество сбоев достигнет числа, указанного в MaxFailures . Наличие HealthMonitor гарантирует, что TargetServer вернется в ротацию, как только целевой сервер снова станет доступен, а это означает, что нет необходимости повторно развертывать прокси .
Чтобы гарантировать, что проверка работоспособности выполняется на том же номере порта, который Edge использует для подключения к целевым серверам, Apigee рекомендует опустить дочерний элемент <Port> в <TCPMonitor> , если он не отличается от порта TargetServer. По умолчанию <Port> совпадает с портом TargetServer.
Пример конфигурации с HealthMonitor:
```
<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>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>
```
Если существует какое-либо ограничение, например, только один TargetServer и HealthMonitor не используется, не указывайте MaxFailures в конфигурации LoadBalancer .
Значение MaxFailures по умолчанию — 0. Это означает, что Edge всегда пытается подключиться к цели для каждого запроса и никогда не удаляет целевой сервер из ротации.