Поделиться через

Серверные компоненты в Управлении API

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API

Серверная часть (или серверная часть API) в Управлении API — это служба HTTP, которая реализует внешний API и его операции.

При импорте некоторых API Управление API автоматически настраивает серверную часть API. Например, Управление API настраивает серверную веб-службу при импорте:

Управление API также поддерживает использование других ресурсов Azure, таких как сервер API, например:

Преимущества серверных компонентов

Управление API поддерживает внутренние сущности, чтобы управлять внутренними службами API. Серверная сущность инкапсулирует сведения о серверной службе, повышая повторное использование в API и улучшенную систему управления.

Используйте серверные серверы для одного или нескольких следующих элементов:

  • Авторизация учетных данных запросов в серверную службу
  • Воспользуйтесь преимуществами Управление API функций для хранения секретов в Azure Key Vault, если именованные значения настроены для проверки подлинности параметра заголовка или запроса.
  • Определение правил разбиения цепи для защиты серверной части от слишком большого количества запросов
  • Маршрутизация или балансировка нагрузки запросов к нескольким серверным службам

Настройте и управляйте внутренними сущностями в портал Azure или с помощью API или средств Azure.

Ссылка на серверную часть с помощью политики set-backend-service

После создания серверной части можно ссылаться на URL-адрес внутреннего сервера в API. set-backend-service Используйте политику для направления входящего запроса API на серверную часть. Если вы уже настроили серверную веб-службу для API, можно использовать set-backend-service политику для перенаправления запроса на серверную сущность. Например:

<policies>
    <inbound>
        <base />
        <set-backend-service backend-id="myBackend" />
    </inbound>
    [...]
<policies/>

Вы можете использовать условную логику с set-backend-service политикой для изменения эффективной серверной части в зависимости от расположения, вызываемого шлюза или других выражений.

Например, вот политика маршрутизации трафика в другую серверную часть на основе вызываемого шлюза:

<policies>
    <inbound>
        <base />
        <choose>
            <when condition="@(context.Deployment.Gateway.Id == "factory-gateway")">
                <set-backend-service backend-id="backend-on-prem" />
            </when>
            <when condition="@(context.Deployment.Gateway.IsManaged == false)">
                <set-backend-service backend-id="self-hosted-backend" />
            </when>
            <otherwise />
        </choose>
    </inbound>
    [...]
<policies/>

Средство разбиения цепи

Управление API предоставляет свойство разбиения канала в серверном ресурсе для защиты серверной службы от перегрузки слишком большим количеством запросов.

  • Свойство разбиения цепи определяет правила для переключения канала, например числа или процента условий сбоя в течение определенного интервала времени и диапазона кодов состояния, указывающих на сбои.
  • При переключениях канала Управление API перестает отправлять запросы в серверную службу в течение определенного времени и возвращает 503-й ответ на клиент.
  • После настроенной длительности поездки канал сбрасывается и трафик возобновляется на серверную часть.

Серверный выключатель — это реализация шаблона разбиения цепи, позволяющего серверной части восстановиться после перегруженных ситуаций. Он расширяет общие политики ограничения скорости и ограничения параллелизма, которые можно реализовать для защиты шлюза Управление API и внутренних служб.

Примечание.

  • В настоящее время серверный выключатель не поддерживается на уровне потребления Управление API.
  • Из-за распределенной природы архитектуры Управление API правила останова цепи являются приблизительными. Разные экземпляры шлюза не синхронизируются и будут применять правила разбиения цепи на основе сведений об одном экземпляре.
  • В настоящее время для внутреннего разбиения цепи можно настроить только одно правило.

Пример

Используйте REST API Управление API или шаблон Bicep или ARM для настройки разбиения цепи в серверной части. В следующем примере средство разбиения цепи в myBackend в Управление API экземпляре myAPIM выполняется при наличии трех или более 5xx кодов состояния, указывающих на ошибки сервера в течение 1 часа.

Автоматический выключатель сбрасывается через 1 час. Retry-After Если заголовок присутствует в ответе, средство разбиения цепи принимает значение и ожидает указанного времени, прежде чем отправлять запросы в серверную часть снова.

Добавьте фрагмент кода, аналогичный следующему, в шаблон Bicep для внутреннего ресурса с разбителем канала:

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackend'
  properties: {
    url: 'https://mybackend.com'
    protocol: 'https'
    circuitBreaker: {
      rules: [
        {
          failureCondition: {
            count: 3
            errorReasons: [
              'Server errors'
            ]
            interval: 'PT1H' 
            statusCodeRanges: [
              {
                min: 500
                max: 599
              }
            ]
          }
          name: 'myBreakerRule'
          tripDuration: 'PT1H'  
          acceptRetryAfter: true
        }
      ]
    }
   }
 }

Пул с балансировкой нагрузки

Управление API поддерживает серверные пулы, если требуется реализовать несколько внутренних серверов для API и запросов балансировки нагрузки в этих серверных службах.

Используйте внутренний пул для таких сценариев, как показано ниже.

  • Распределить нагрузку на несколько внутренних серверных компонентов, которые могут иметь отдельные серверные разбиения цепи.
  • Переместите нагрузку из одного набора серверных компонентов в другой для обновления (сине-зеленое развертывание).

Чтобы создать внутренний пул, задайте type для свойства серверной pool части и укажите список серверных серверов, составляющих пул.

Примечание.

  • В настоящее время в пул серверной части можно включить только один серверные серверы. Вы не можете добавить серверную часть типа pool в другой серверный пул. В пул можно включить до 30 серверных компонентов.
  • Благодаря распределенной природе архитектуры Управление API серверная балансировка нагрузки приблизительная. Разные экземпляры шлюза не синхронизируются и будут балансировать нагрузку на основе сведений об одном экземпляре.

Параметры балансировки нагрузки

Управление API поддерживает следующие параметры балансировки нагрузки для серверных пулов:

  • Циклический перебор. По умолчанию запросы распределяются равномерно по серверным серверам в пуле.
  • Весовые значения: весовые значения назначаются серверным службам в пуле, а запросы распределяются по серверным службам на основе относительного веса, назначенного каждой серверной части. Используйте этот параметр для таких сценариев, как проведение сине-зеленого развертывания.
  • На основе приоритета: серверные серверы организованы в группах приоритетов, а запросы отправляются в серверные части в порядке групп приоритетов. В группе приоритетов запросы распределяются равномерно по серверной части или (при назначении) в соответствии с относительным весом, назначенным каждой серверной части.

Примечание.

Серверные серверы в группах с более низким приоритетом будут использоваться только в том случае, если все серверные части в группах с более высоким приоритетом недоступны, так как правила разбиения цепи споткнуты.

Пример

Используйте rest API Управление API или шаблон Bicep или ARM для настройки внутреннего пула. В следующем примере серверная часть myBackendPool в экземпляре Управление API myAPIM настраивается с серверным пулом. Примеры серверных серверов в пуле называются backend-1 и backend-2. Обе серверные части находятся в группе с наивысшим приоритетом; в группе серверная часть-1 имеет больший вес, чем серверная часть-2 .

Добавьте фрагмент кода, аналогичный следующему, в шаблон Bicep для внутреннего ресурса с пулом с балансировкой нагрузки:

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    pool: {
      services: [
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-1'
          priority: 1
          weight: 3
        }
        {
          id: '/subscriptions/<subscriptionID>/resourceGroups/<resourceGroupName>/providers/Microsoft.ApiManagement/service/<APIManagementName>/backends/backend-2'
          priority: 1
          weight: 1
        }
      ]
    }
  }
}

Ограничения

Связанный контент