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

Статья
05/21/2024

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

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

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

Спецификация OpenAPI.
A SOAP API.
Ресурсы Azure, такие как приложение-функция Azure с триггером HTTP или приложение логики.

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

Кластер Service Fabric.
Пользовательская служба.

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

Управление 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
ARM

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

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

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

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "2023-09-01-preview",
  "name": "myAPIM/myBackend",
  "properties": {
    "url": "https://mybackend.com",
    "protocol": "http",
    "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
ARM

Добавьте фрагмент кода, аналогичный следующему, в шаблон 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
        }
      ]
    }
  }
}

Добавьте фрагмент JSON, аналогичный приведенному ниже, в шаблон ARM для внутреннего ресурса с пулом с балансировкой нагрузки.

{
  "type": "Microsoft.ApiManagement/service/backends",
  "apiVersion": "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"    
        }
      ]
    }
  }
}

Ограничения

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

Блог. Использование автоматического останова Azure Управление API и балансировки нагрузки с помощью Службы Azure OpenAI
Настройте серверную часть Service Fabric с помощью портала Azure.

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

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

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

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

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

Пример

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

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

Пример

Ограничения

Обратная связь

Дополнительные ресурсы

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

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

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

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

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

Пример

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

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

Пример

Ограничения

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

Обратная связь

Дополнительные ресурсы