Зачем микросервисам нужен API Gateway

Что такое микросервисы

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

В целом, архитектура систем эволюционировала от монолитной архитектуры к архитектуре SOA и далее к микросервисной архитектуре. Конкретные этапы развития, а также преимущества и недостатки каждой архитектуры представлены в таблице ниже.

Тип архитектуры	Описание	Преимущества	Недостатки
Монолитная архитектура приложения	Весь функциональный код упакован в один сервис.	1. Простая архитектура с низкими затратами на разработку и обслуживание проекта.	Связывание всех модулей вместе полезно для разработки и поддержки небольших проектов, но может создавать проблемы для крупных проектов, включая 1. Модули в проекте слишком тесно связаны, и проблема с производительностью одного модуля может привести к недоступности всего проекта; 2. Проекту требуется лучшая масштабируемость.
Архитектура SOA	Термин означает "сервис-ориентированная архитектура", которая обычно включает несколько сервисов. Сервис обычно существует независимо в процессе операционной системы, а взаимодействие между сервисами достигается через зависимости или механизмы связи, В конечном итоге, это предоставляет набор функций.	1. Интеграция систем: С системной точки зрения, она решает проблемы связи между корпоративными системами, преобразуя их ранее неупорядоченные и неструктурированные сетевые соединения в управляемую и структурированную звездообразную конфигурацию. 2. Сервис-ориентированная система: С функциональной точки зрения, она абстрагирует бизнес-логику в повторно используемые и комбинируемые сервисы и использует оркестрацию сервисов для быстрого восстановления бизнес-процессов. 3. Бизнес-ориентированные сервисы: С точки зрения предприятия, она абстрагирует функции предприятия в повторно используемые и комбинируемые сервисы.	1. Централизация сервисов создает зависимости между сервисами, и сбой одного сервиса может вызвать каскадный сбой других сервисов. 2. Зависимости и отношения вызова между сервисами сложны, что затрудняет тестирование и развертывание.
Микросервисная архитектура	Микросервисы — это развитие SOA. Один из ключевых акцентов микросервисной архитектуры — "необходимость полностью компонентизировать и сервизировать бизнес", Исходная единая бизнес-система будет разделена на несколько частей, которые могут разрабатываться, проектироваться и развертываться независимо. Эти части будут работать как небольшие независимые приложения. Каждое приложение будет взаимодействовать и общаться с другими для достижения интеграции и интерактивности, что и составляет суть микросервисной архитектуры.	1. Децентрализация; 2. Компонентизация через сервисы; 3. Разделение сервисов и команд разработки на основе бизнес-возможностей; 4. Автоматизация инфраструктуры (DevOps, автоматизированное развертывание).	1. Высокая стоимость разработки; 2. Проблемы с отказоустойчивостью сервисов; 3. Проблемы с согласованностью данных; 4. Включают распределенные транзакции.

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

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

Что такое API-шлюз?

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

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

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

Зачем микросервисам нужен API-шлюз?

Как показано на диаграмме выше, API-шлюз служит промежуточным слоем между клиентом и микросервисами. Он может предоставлять микросервисы внешнему миру по единому адресу и направлять трафик на правильные узлы сервисов внутри внутреннего кластера на основе соответствующих правил.

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

Вызовы, с которыми сталкиваются микросервисы

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

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

Решения

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

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

Мониторинг и оповещение/Анализ трассировки:

Как посредник между клиентом и сервером, API-шлюз является отличным носителем для мониторинга микросервисов.

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

Ограничение скорости, изоляция и разрыв цепи:

По мере увеличения масштабов интернет-бизнеса увеличивается и параллелизм систем. Множество сервисов часто вызывают друг друга, и ключевое звено может вызывать до десяти сервисов. Если время отклика (RT) определенного сервиса резко возрастает, а вышестоящие сервисы продолжают запрашивать, возникнет порочный круг. Чем больше вышестоящих сервисов ожидают результатов, тем больше вышестоящих сервисов будет заблокировано, и весь процесс в конечном итоге станет непригодным для использования, что приведет к лавине сервисов.

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

Выбор основных шлюзов

В микросервисах доступно множество реализаций открытых шлюзов, включая NGINX, Kong, Apache APISIX и Envoy. Для технологического стека Java есть такие варианты, как Netflix Zuul, Spring Cloud Gateway, Soul и другие. Но вы можете задаться вопросом: "Почему стоит выбрать Apache APISIX вместо NGINX и Kong?"

Вот краткое сравнение.

Шлюз	Проблемы	Преимущества
NGINX	1. Для вступления изменений в силу требуется перезагрузка конфигурации, что не может идти в ногу с прогрессом облачных технологий.	1. Устаревшие приложения; 2. Стабильный, надежный и проверенный временем; 3. Высокая производительность
Apache APISIX	1. Документация недостаточно богата или ясна и требует улучшения.	1. Проект высшего уровня Apache Foundation; 2. Техническая архитектура больше соответствует принципам облачных технологий; 3. Отличная производительность; 4. Богатая экосистема; 5. Помимо поддержки плагинов на Lua, также поддерживает плагины на Java, Go, Python, Node и других языках.
Kong	1. Использование по умолчанию баз данных PostgreSQL или Cassandra делает всю архитектуру очень громоздкой и может вызывать проблемы с высокой доступностью; 2. Маршрутизация использует алгоритм поиска с обходом, что может привести к значительному снижению производительности при наличии более тысячи маршрутов в шлюзе; 3. Некоторые важные функции требуют оплаты;	1. Пионер среди открытых API-шлюзов с большой пользовательской базой; 2. Производительность удовлетворяет потребности большинства пользователей; 3. Богатая экосистема; 4. Поддерживает разработку плагинов на Lua и Go;
Envoy	1. Разработан на C++, что затрудняет вторичную разработку; 2. Помимо разработки фильтров на C++, также поддерживает WASM и Lua.	1. Проект CNCF, более подходящий для сценариев сервисной сетки и поддерживающий развертывание многоязычных архитектур;
Spring Cloud Gateway	1. Хотя сообщество Spring зрелое, ресурсов для Gateway недостаточно.	1. Шлюз предоставляет множество готовых функций, которые можно использовать через конфигурацию SpringBoot или ручное кодирование; 2. Spring-фреймворк обладает высокой расширяемостью, простой конфигурацией и хорошей поддерживаемостью; 3. Сообщество Spring зрелое; 4. Простота использования; 5. Удобство для технологического стека Java.

Итог

По мере развития интернет-мира предприятия быстро эволюционируют, что приводит к постоянным изменениям в архитектуре систем. Микросервисная архитектура широко применяется многими компаниями.

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

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