Реализация Fallback с использованием API Gateway

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

Реализация откатов с использованием APISIX

Для реализации механизма отката с использованием APISIX можно использовать встроенную функцию приоритетов upstream или плагин response-rewrite для возврата предопределенного ответа при сбое вызова сервиса. Вот пошаговый пример настройки обоих методов отката.

Предварительные требования

Это руководство предполагает, что следующие инструменты установлены локально:

• Перед началом работы рекомендуется иметь базовое понимание APISIX. Знание ключевых концепций, таких как API Gateway, маршруты, upstream, Admin API, плагины и протокол HTTP, также будет полезным.
• Docker используется для установки контейнеризованных etcd и APISIX.
• Установите cURL для отправки запросов к сервисам для проверки.

Запуск Docker-проекта APISIX

Этот проект использует предопределенный файл конфигурации Docker Compose для настройки, развертывания и запуска APISIX, etcd, Prometheus и других сервисов одной командой. Сначала клонируйте репозиторий apisix-docker на GitHub, откройте его в любимом редакторе, перейдите в папку example и запустите проект, выполнив команду docker compose up в терминале из корневой папки проекта.

При запуске проекта Docker загружает все необходимые образы. Он также запускает два примера серверных сервисов web1 и web2. Полный список сервисов можно увидеть в файле docker-compose.yaml.

Откат с включенными приоритетами upstream в APISIX

Вы можете настроить каждый узел upstream с определенным уровнем приоритета. Когда узел с более высоким приоритетом выходит из строя, API Gateway может перенаправить трафик на вторичный узел с более низким приоритетом. По умолчанию приоритет всех узлов равен 0, узлы с отрицательным приоритетом могут быть настроены как резервные.

Создайте маршрут к двум сервисам и настройте атрибут приоритета для каждого узла сервиса upstream:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "upstream":{
      "nodes":[
         {
            "host":"web1",
            "port":80,
            "weight":1,
            "priority":0
         },
         {
            "host":"web2",
            "port":80,
            "weight":1,
            "priority":-1
         }
      ]
   }
}'

• methods: Указывает HTTP-метод, который будет соответствовать этому маршруту. В данном случае это GET.
• uri: Это путь, который будет соответствовать маршруту. Таким образом, любой GET-запрос к /get будет обработан этим маршрутом.
• nodes: Это массив серверов backend. Каждый объект в массиве представляет сервер с его host, port и weight. Параметр weight используется для балансировки нагрузки; в данном случае оба сервера имеют вес 1, что обычно означает равномерное распределение трафика.
• priority: Это дополнительная конфигурация для двух узлов (web1, web2). Поле priority используется для определения порядка выбора узлов. Узел с более низким приоритетом (большим отрицательным числом) будет использоваться только в случае недоступности всех узлов с более высоким приоритетом (меньшими отрицательными числами или положительными числами).

Проверьте, получаете ли вы ответ только от сервиса web1, когда отправляете запрос на маршрут:

curl "http://127.0.0.1:9080/get"

Вы должны увидеть ответ, похожий на следующий:

hello web1

Это означает, что web1 выполнился первым, так как он функционирует. Теперь остановите контейнер сервиса web1, чтобы проверить, переключится ли APISIX на сервис web2.

docker container stop example-web1-1

Теперь, если вы снова отправите запрос на маршрут, вы получите ответ от резервного сервиса, который мы указали.

curl "http://127.0.0.1:9080/get"
hello web2

По умолчанию запрос сначала направляется на сервис один, и если он недоступен, происходит откат на сервис два через 60 секунд. Вы также можете изменить это время, установив атрибут timeout объекта Upstream. Другой стратегией отката может быть использование во время выпусков. Если новая версия API содержит ошибки, вы можете перенаправить трафик на старую версию, которая находится в режиме ожидания, с использованием функции traffic split в APISIX. Откат на предыдущую версию, если новая версия имеет проблемы. Этот метод отката также хорошо работает с проверками здоровья Upstream.

Откат с использованием плагина Response Rewrite в APISIX

Плагин response-rewrite в APISIX позволяет изменять код состояния ответа, тело и заголовки перед возвратом клиенту. Это может быть особенно полезно для реализации механизма отката, предоставляя ответ по умолчанию при сбое сервиса upstream.

Если вы следовали первому подходу, перезапустите контейнер сервиса web1 в Docker:

docker container start example-web1-1

Чтобы использовать плагин response-rewrite для отката, его нужно настроить в маршруте. Вот пример того, как можно включить плагин с помощью команды curl:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "plugins":{
      "response-rewrite":{
         "status_code":200,
         "body":"{\"message\":\"This is a fallback response when the service is unavailable\"}",
         "vars":[
            [
               "status",
               "==",
               503
            ]
         ]
      }
   },
   "upstream":{
      "nodes":{
         "web1:80":1
      }
   }
}'

В приведенном выше примере мы определили один серверный сервис (web1:80), на который должен направляться трафик при совпадении этого маршрута. Если сервис upstream (web1:80) отвечает с кодом состояния 503 Service Unavailable, плагин response-rewrite изменит ответ на 200 OK с пользовательским телом JSON. Это эффективно создает резервный ответ, когда сервис upstream недоступен.

"vars": [["status", "==", 503]]: Это условие указывает плагину применять перезапись только в случае, если исходный код состояния ответа равен 503 Service Unavailable.

Теперь, если вы отправите запрос на маршрут, вы должны получить измененный ответ:

curl "http://127.0.0.1:9080/get"

{"message":"This is a fallback response when the service is unavailable"}

Проблемы реализации механизма отката

Откаты являются критически важным компонентом устойчивого проектирования системы. Однако они могут вызвать дополнительные проблемы, если реализованы неправильно. При обсуждении стратегий отката проблемы могут различаться между однопользовательскими средами и распределенными системами. Давайте рассмотрим их, чтобы понять их на примерах и узнать, как избежать их с использованием APISIX.

Сложность тестирования логики отката

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

APISIX можно настроить для маршрутизации трафика с целью симуляции различных сценариев, включая условия отката. Это позволяет проводить более реалистичное тестирование логики отката в контролируемых условиях, гарантируя, что резервные сервисы могут справляться с производственным трафиком.

Откаты сами могут выйти из строя

Если резервное решение не так устойчиво, как ожидалось, оно может выйти из строя под повышенной нагрузкой, которая возникает при его активации, вызывая каскадный сбой. Кроме того, откат на менее эффективный сервис может увеличить время ответа и нагрузку, что потенциально может привести к замедлению или отказу всей системы. Например, API может иметь откат на запись логов в локальную файловую систему, когда удаленный сервис логирования недоступен. Это может привести к замедлению производительности из-за синхронных операций ввода-вывода файлов.

С APISIX вы можете приоритизировать трафик, чтобы гарантировать, что критические запросы обрабатываются в первую очередь. Это может предотвратить перегрузку резервного сервиса и ухудшение производительности системы.

Откаты имеют операционные риски

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

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

Откаты содержат скрытые и усиленные ошибки

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

APISIX поддерживает непрерывное A/B-тестирование и канареечные выпуски, позволяя командам тестировать пути отката в производственной среде с небольшим процентом трафика. Это постоянное воздействие может помочь выявить скрытые ошибки до того, как они станут критическими.

Откаты редко используются

Механизмы отката редко используются, поэтому при их активации они могут не работать так, как ожидается, из-за отсутствия регулярного тестирования и обновлений. Например, API, предоставляющий географические данные, может иметь откат на статический набор данных, когда динамический источник данных недоступен. Если этот откат редко используется, он может предоставлять устаревшую информацию при активации, так как он не обновляется или тестируется регулярно.

С другой стороны, APISIX позволяет настраивать динамическую маршрутизацию и может использоваться для периодического перенаправления части трафика на резервные сервисы. Это гарантирует, что пути отката регулярно проверяются и остаются готовыми к использованию.

Заключение

Откаты — это страховочная сетка для случаев, когда что-то идет не так с API. Используя конфигурацию upstream или плагин response-rewrite в APISIX, разработчики могут предоставлять продуманные, удобные для пользователя ответы, которые поддерживают функциональность системы и доверие пользователей. Ключевым моментом является предвидение потенциальных точек сбоя и проектирование откатов, которые обеспечивают наилучший возможный опыт в данных обстоятельствах.

Связанные ресурсы

• 10 распространенных шаблонов проектирования устойчивости API с использованием API Gateway
• Лучшие практики создания надежных API