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

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

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

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

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

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

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

Конфигурация 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>

MaxFailures

Параметр 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 будет исключен из ротации. Поскольку других TargetServer для переключения нет, все последующие запросы к API-прокси с такой конфигурацией будут завершаться ошибкой 503 Service Unavailable .

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

Если в политике вызова сервиса используется та же конфигурация, то запросы к целевому серверу "target1" будут завершаться с ошибкой 500 после пяти неудачных попыток.

Влияние

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

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

Передовая практика

Для повышения доступности используйте более одного TargetServer в конфигурации LoadBalancer .
Всегда указывайте монитор работоспособности, если параметр MaxFailures имеет ненулевое значение. Целевой сервер будет удален из ротации, когда количество сбоев достигнет числа, указанного в MaxFailures . Наличие монитора работоспособности гарантирует, что целевой сервер будет снова включен в ротацию, как только он станет доступен, а это значит, что нет необходимости повторно развертывать прокси .
Чтобы гарантировать выполнение проверки работоспособности на том же номере порта, который 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 всегда пытается подключиться к целевому серверу для каждого запроса и никогда не удаляет целевой сервер из ротации.