В этом разделе изложены ключевые функции, поддерживаемые APIG. Для получения подробной информации о региональной доступности каждой функции вы можете обратиться к консоли.
Жизненный цикл API включает создание, публикацию, удаление и окончательное удаление API. Управление жизненным циклом API позволяет быстро и эффективно раскрывать возможности сервиса. Для подробностей см. Process Flow.
APIG интегрирует входящий трафик (Kubernetes Ingress) и управление микросервисами (Kubernetes Gateway API) в один шлюз, повышая производительность, упрощая архитектуру и снижая затраты на развертывание и эксплуатацию.
С помощью встроенного инструмента отладки вы можете отлаживать API, используя различные HTTP‑заголовки и тела запросов. Этот инструмент упрощает процесс разработки API и снижает затраты на разработку и обслуживание API. Для подробностей см. Debugging an API.
API может быть опубликован в разных средах. Повторная публикация API в той же среде перезапишет предыдущую версию API. APIG отображает историю публикаций (включая версию, описание, дату и время, а также среду) каждого API. Вы можете откатить API к любой исторической версии, чтобы удовлетворить требования dark launch и обновления версии. Для подробностей см. Publishing an API.
Переменные среды управляемы и специфичны для сред. Переменные API будут заменены значениями переменных в среде, в которой API будет опубликован. Вы можете создавать переменные в разных средах, чтобы вызывать разные бэкенд‑сервисы, используя один и тот же API. Для подробностей см. (Optional) Configuring the Environment and Environment Variables.
APIG предоставляет визуализированный, в реальном времени мониторинг API и отображает несколько метрик, включая количество запросов, задержку вызова и количество ошибок. Метрики помогают понять использование API, позволяя выявлять потенциальные риски сервиса. Для получения подробной информации см. Configuring an Alarm Rule.
Каналы Virtual Private Cloud (VPC) (load balance channels) могут быть созданы для доступа к ресурсам в VPC и для экспонирования бэкенд‑сервисов, развернутых в VPC. Каналы VPC распределяют запросы API к бэкенд‑сервисам и могут быть подключены к серверам и реестрам микросервисов. Поддерживаются Backend load balancing и dark launch policies. Для получения подробной информации см. (Optional) Creating a Load Balance Channel.
Mock backends имитируют ответы API для circuit breakers, деградации сервиса и перенаправления.
APIG поддерживает HTTP/2, который является крупным обновлением HTTP и изначально назывался HTTP 2.0. Он предоставляет возможности, такие как бинарное кадрирование, мультиплексирование и сжатие заголовков, улучшая производительность передачи для достижения низкой задержки и высокой пропускной способности.
В отличие от HTTP 1.x, где данные передаются в текстовом формате, данные в HTTP 2.0 разбиваются на сообщения и фреймы для бинарного кодирования. По сравнению с разбором строк (текст), бинарный разбор проще, менее подвержен ошибкам и обеспечивает более высокую производительность передачи.
С бинарным кодированием HTTP 2.0 больше не полагается на несколько соединений для одновременной обработки и отправки запросов и ответов.
Для одного и того же доменного имени все запросы выполняются по единому соединению, и каждое соединение может обрабатывать произвольное количество сообщений. Сообщение состоит из одного или нескольких фреймов, которые могут передаваться в произвольном порядке и затем объединяться на основе stream ID в заголовке каждого фрейма. Это сокращает задержку и повышает эффективность.
HTTP 2.0 использует кодировщик для уменьшения размера передаваемых заголовков. Как клиент, так и сервер хранят таблицу полей заголовков, чтобы избегать повторной передачи одинаковых заголовков, обеспечивая высокую пропускную способность.