10 распространенных шаблонов проектирования устойчивости API с использованием API Gateway
November 1, 2023
Устойчивость API заключается в создании надежных API, которые могут выдерживать различные вызовы, обеспечивая их эффективное функционирование. API Gateway играют ключевую роль в этом, выступая в качестве точки входа для внешних запросов и управляя взаимодействием между различными сервисами, учитывая распространенные шаблоны устойчивости API. Один из популярных API Gateway с открытым исходным кодом, Apache APISIX, предоставляет множество функций для повышения устойчивости и надежности API. В этой статье мы рассмотрим 10 распространенных шаблонов проектирования устойчивости API и то, как их можно реализовать с помощью APISIX.
Вот список всех 10 шаблонов устойчивости API:
- Ограничение скорости.
- Повторная попытка.
- Тайм-аут.
- Резервный вариант.
- Кэширование.
- Избыточность.
- Проверки состояния.
- Прерыватель цепи.
- Разделение на отсеки.
- Внедрение ошибок.
Что такое устойчивость API?
Устойчивость API — это способность API стабильно и надежно выполнять свои функции, даже в условиях ошибок, высокой нагрузки или неожиданных ситуаций. Речь идет не о предотвращении сбоев, а о принятии факта, что сбои будут происходить, и о реагировании на них таким образом, чтобы избежать простоев или потери данных. Цель устойчивости — вернуть приложение в полностью работоспособное состояние после сбоя. Устойчивые API разработаны для того, чтобы справляться со сбоями грациозно, независимо от того, происходят ли эти сбои внутри самого API, от зависимых сервисов или из-за внешних факторов, таких как проблемы с сетью или задержки, несовместимость версий API и другие проблемы, которые могут возникнуть из-за изменений в окружении или неожиданного поведения пользователей.
Почему устойчивость API на уровне API Gateway?
Многие существующие фреймворки для разработки программного обеспечения включают набор практик и шаблонов, предназначенных для обеспечения доступности, отзывчивости и точности API. Однако реализация устойчивости API на уровне API Gateway, а не в отдельных сервисах или других частях системы, предлагает несколько стратегических преимуществ.
1. Централизованное управление: API Gateway служит центральной точкой входа для всех запросов API, предоставляя уникальную возможность управлять и применять шаблоны устойчивости для всех сервисов в единой манере. Эта централизация упрощает реализацию и поддержку функций устойчивости.
2. Согласованность: Обрабатывая устойчивость на уровне API Gateway, вы обеспечиваете единый подход к обработке сбоев, ограничению скорости, тайм-аутам и другим стратегиям устойчивости для всех сервисов. Эта согласованность важна для поддержания надежного и предсказуемого поведения системы.
3. Снижение сложности: Реализация функций устойчивости в каждом микросервисе может привести к дублированию усилий и увеличению сложности. API Gateway абстрагирует эти проблемы, позволяя разработчикам сервисов сосредоточиться на бизнес-логике, а не на обработке устойчивости.
4. Улучшенное использование ресурсов: API Gateway может эффективно управлять ресурсами и распределять трафик, обеспечивая, чтобы ни один сервис не был перегружен. Этот балансировщик нагрузки способствует общей устойчивости системы.
5. Упрощенный мониторинг и логирование: Наличие единой точки, через которую проходит весь трафик API, упрощает мониторинг состояния ваших сервисов и логирование любых проблем. Этот централизованный вид бесценен для быстрого выявления и реагирования на проблемы.
6. Упрощенная безопасность: Меры безопасности, такие как аутентификация, авторизация и шифрование, могут быть последовательно применены на уровне API Gateway, обеспечивая защиту всех сервисов без необходимости дублирования конфигураций.
7. Повышенная производительность: API Gateway может реализовать кэширование и агрегацию ответов, уменьшая количество вызовов к сервисам бэкенда и повышая общую производительность системы.
8. Грациозная деградация: В случае сбоя сервиса API Gateway может перенаправить трафик или предоставить резервные ответы, обеспечивая, чтобы система деградировала грациозно и продолжала предоставлять функциональность.
9. Более быстрое восстановление: Централизованный характер API Gateway позволяет быстрее внедрять исправления и обновления, обеспечивая быстрое восстановление системы до полной функциональности после сбоя.
10. Упрощенное взаимодействие с клиентами: Клиентам нужно взаимодействовать только с API Gateway, который предоставляет согласованный и надежный интерфейс, абстрагируя сложность лежащих в основе микросервисов.
С точки зрения разработки, подход API Gateway также сокращает время реализации часто используемых шаблонов устойчивости. Давайте рассмотрим каждый шаблон на примере взаимодействия между сервисами в типичном приложении для конференций и поймем, как их включить.
Этот пост в основном сосредоточен на теоретической части и предоставляет ссылки на соответствующую документацию. Разработчики могут реализовать эти шаблоны, проверив каждую ссылку и пройдя предоставленные руководства. С APISIX можно настроить эти шаблоны проектирования с помощью Admin API, статического YAML-файла или APISIX Dashboard.
1. Ограничение скорости
Как следует из названия, ограничение скорости контролирует количество запросов, которые клиент может сделать за определенный период времени. APISIX предлагает плагин limit-req для настройки ограничения скорости. Этот плагин позволяет вам определять правила на основе свойств отдельных запросов (слишком много от одного пользователя, клиентского приложения или местоположения) для ограничения запросов, обеспечивая, чтобы ваш API не был перегружен слишком большим количеством запросов.
Политика ограничения скорости также может использоваться для ограничения доступа для неавторизованных пользователей. Проверьте руководство, чтобы узнать, как использовать плагин для ограничения скорости.
2. Повторная попытка
Шаблон повторной попытки предполагает автоматическое повторение запроса API, если он завершился неудачей. С APISIX вы можете настроить механизм повторной попытки для Upstream объекта, чтобы указать количество повторных попыток и условия, при которых следует выполнить повторную попытку.
Настроив upstream с параметрами повторной попытки, APISIX отправляет автоматические повторные запросы к сервису Attendee, если предыдущий запрос завершился тайм-аутом или неудачей из-за проблемы с сетью.
3. Тайм-аут
Установка тайм-аута гарантирует, что запрос не будет висеть бесконечно, если сервис бэкенда не отвечает. APISIX позволяет вам настроить тайм-ауты для ваших API в той же конфигурации Upstream объекта, обеспечивая, чтобы запросы завершались, если они занимают слишком много времени для ответа.
В случае, если сервис Attendee отвечает медленно, APISIX может применить шаблон fail-fast и быстро ответить на запрос клиентского приложения, чтобы улучшить отзывчивость всей системы.
4. Резервный вариант
Шаблон резервного варианта предоставляет ответ по умолчанию, когда сервис недоступен. APISIX позволяет вам определить приоритеты upstream, когда основной эндпоинт не работает, API Gateway может перенаправить трафик на вторичный сервис или вернуть предопределенный ответ с помощью плагина response-rewrite в случае сбоев сервиса, таких как HTTP 500.
Или вы можете использовать плагин proxy-cache для кэширования ответов и их предоставления, когда бэкенд недоступен. Например, мобильное приложение показывает кэшированный список участников конференции, когда сервис Attendee недоступен.
5. Кэширование
Кэширование ответов может значительно снизить нагрузку на ваши сервисы бэкенда. APISIX предлагает плагин proxy-cache, который позволяет кэшировать ответы и предоставлять их непосредственно из API Gateway, уменьшая задержку и повышая производительность.
Проверьте руководство по кэшированию ответов API, чтобы узнать, как использовать плагин proxy-cache.
6. Избыточность
Каждый API Gateway предоставляет общую функцию, такую как балансировка нагрузки, которая распределяет входящие запросы API между несколькими сервисами бэкенда (узлами или экземплярами). Наличие избыточных экземпляров делает систему более устойчивой к нерегулярным событиям. APISIX поддерживает различные алгоритмы балансировки нагрузки, такие как round-robin, least connections и consistent hashing.
В случае сервиса Attendee вы можете запустить два экземпляра, и если сервер A выйдет из строя, запросы могут быть обработаны вторым сервером.
7. Проверки состояния
Проверка состояния — это механизм, который определяет, являются ли сервисы upstream здоровыми или нездоровыми на основе их отзывчивости. APISIX определяет, доступен ли сервис, используя активные проверки состояния upstream. С включенными проверками состояния APISIX будет перенаправлять запросы только на сервисы upstream, которые считаются здоровыми, и не будет перенаправлять запросы на сервисы, которые считаются нездоровыми.
Для периодической проверки состояния API APISIX нужен HTTP-путь к эндпоинту состояния сервиса upstream. Поэтому сначала вам нужно добавить эндпоинт /health для сервиса Attendee.
8. Прерыватель цепи
Шаблон прерывателя цепи предотвращает вызовы системы к сервису, который, вероятно, завершится неудачей, тем самым защищая систему от каскадных сбоев. APISIX предоставляет два варианта реализации функциональности прерывателя цепи: использование плагина api-breaker в конфигурации Route или включение пассивных проверок состояния upstream. Оба способа обрабатывают сбои и предотвращают постоянные попытки повторных запросов к сервисам upstream, если сервис завершается неудачей или работает медленно.
APISIX отслеживает количество недавних сбоев и использует эту информацию для принятия решения о том, разрешить ли выполнение операции или просто немедленно вернуть исключение.
9. Разделение на отсеки
Шаблон разделения на отсеки изолирует элементы внутри приложения, обеспечивая, чтобы при сбое или высокой нагрузке на одну часть системы другие части продолжали функционировать. Чтобы гарантировать, что высокая нагрузка или проблемы в операциях чтения из сервиса Attendee не влияют на доступность и производительность операций записи в сервис Attendee, вы можете реализовать шаблон разделения на отсеки с помощью APISIX.
Вы создаете отдельные эндпоинты маршрутов в API Gateway для двух узлов upstream, чтобы все запросы на запись перенаправлялись на Сервис A, а все запросы на чтение — на Сервис B.
10. Тестирование хаоса
Тестирование хаоса может помочь убедиться, что API устойчив в производственных средах. Используя его, вы можете оценить и укрепить устойчивость вашего приложения или микросервисов API к различным типам сбоев, повышая надежность. Этот метод позволяет преднамеренно вводить задержки и принудительно завершать запросы с указанными кодами ошибок, облегчая моделирование различных неблагоприятных сценариев, включая сбои сервисов, чрезмерную нагрузку на сервисы, значительные задержки в сети и сегментацию сети.
Плагин Fault Injection Plugin APISIX также предлагает тот же механизм для моделирования различных сценариев сбоев, таких как ошибки или задержки в сервисе Attendee, чтобы проверить, как клиентское приложение реагирует на них.
Заключение
В этом блоге мы рассмотрели 10 распространенных шаблонов проектирования устойчивости API и продемонстрировали, как их эффективно реализовать с помощью APISIX. Централизуя стратегии устойчивости на уровне API Gateway, организации могут достичь согласованного, упрощенного и эффективного управления трафиком API и обработки ошибок.