Серверные компоненты в Управлении 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 2023-03-01, Управление API предоставляет свойство разбиения каналов в серверном ресурсе для защиты серверной службы от перегрузки слишком много запросов.

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

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

Примечание.

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

Пример

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

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

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

Пул с балансировкой нагрузки (предварительная версия)

Начиная с предварительной версии API 2023-05-01, Управление API поддерживает серверные пулы, если требуется реализовать несколько серверных серверов для API и балансировки нагрузки запросов между этими серверными службами. В настоящее время серверный пул поддерживает балансировку нагрузки с циклическим перебором.

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

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

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

Примечание.

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

Пример

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

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

resource symbolicname 'Microsoft.ApiManagement/service/backends@2023-05-01-preview' = {
  name: 'myAPIM/myBackendPool'
  properties: {
    description: 'Load balancer for multiple backends'
    type: 'Pool'
    protocol: 'http'
    url: 'https://example.com'
    pool: {
      services: [
        {
          id: '/backends/backend-1'
        }
        {
          id: '/backends/backend-2'
        }
      ]
    }
  }
}

Ограничение

Для уровней Разработчика и Premium экземпляр Управление API, развернутый во внутренней виртуальной сети, может вызывать ошибки HTTP 500BackendConnectionFailure, если URL-адрес конечной точки шлюза и внутренний URL-адрес совпадают. Если вы столкнулись с этим ограничением, следуйте инструкциям, приведенным в статье об ограничении запросов для самостоятельной цепочки Управление API в режиме внутренней виртуальной сети в блоге Tech Community.

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