Вы работаете в крупной компании, которая строит систему на основе микросервисной архитектуры. Вам как DevOps-специалисту необходимо выдвинуть предложение по организации инфраструктуры для разработки и эксплуатации.
Предложите решение для обеспечения реализации API Gateway. Составьте сравнительную таблицу возможностей различных программных решений. На основе таблицы сделайте выбор решения.
Решение должно соответствовать следующим требованиям:
- маршрутизация запросов к нужному сервису на основе конфигурации,
- возможность проверки аутентификационной информации в запросах,
- обеспечение терминации HTTPS.
Обоснуйте свой выбор.
Для организации API Gateway в микросервисной архитектуре можно использовать несколько популярных решений. Я рассмотрел NGINX, Kong Gateway и Traefik, так как все они позволяют работать с входящими запросами и распределять их между сервисами.
| Решение | Маршрутизация запросов | Проверка аутентификации | HTTPS termination | Комментарий |
|---|---|---|---|---|
| NGINX | Да | Частично (через модули или внешние решения) | Да | Надежное и производительное решение, но больше подходит как reverse proxy, чем полноценный API Gateway |
| Kong Gateway | Да | Да | Да | Полноценный API Gateway с большим количеством готовых функций и плавгинов |
| Traefik | Да | Да | Да | Хорошо подходит для Docker и Kubernetes, удобен при контейнерной инфраструктуре |
Для данной задачи я бы выбрал Kong Gateway.
Kong полностью соответствует требованиям.
Он умеет маршрутизировать запросы к нужным сервисам на основе правил конфигурации. Например, запросы к /users можно направлять в один сервис, а к /orders — в другой.
Kong поддерживает встроенные механизмы аутентификации. Это удобно, потому что не нужно реализовывать проверку токенов или ключей доступа в каждом микросервисе отдельно — это можно централизованно делать на уровне API Gateway.
Kong поддерживает HTTPS termination, то есть принимает защищенное HTTPS-соединение от клиента, расшифровывает трафик и передает запросы внутренним сервисам. Это упрощает настройку самих микросервисов.
Также преимуществом Kong является то, что он изначально создавался именно как API Gateway для микросервисной архитектуры, а не как обычный веб-прокси. Поэтому в нем уже есть полезные дополнительные возможности, например:
- ограничение количества запросов (Rate Limiting);
- логирование запросов;
- управление доступом;
- расширение функциональности через плагины.
Составьте таблицу возможностей различных брокеров сообщений. На основе таблицы сделайте обоснованный выбор решения.
Решение должно соответствовать следующим требованиям:
- поддержка кластеризации для обеспечения надёжности,
- хранение сообщений на диске в процессе доставки,
- высокая скорость работы,
- поддержка различных форматов сообщений,
- разделение прав доступа к различным потокам сообщений,
- простота эксплуатации.
Обоснуйте свой выбор.
Для организации обмена сообщениями между микросервисами можно использовать разные брокеры сообщений. Я рассмотрел наиболее популярные решения: RabbitMQ, Apache Kafka, NATS и Redis Streams.
| Решение | Кластеризация | Хранение сообщений на диске | Скорость работы | Поддержка разных форматов | Разграничение прав доступа | Простота эксплуатации | Комментарий |
|---|---|---|---|---|---|---|---|
| RabbitMQ | Да | Да | Высокая | Да | Да | Высокая | Универсальное и удобное решение |
| Apache Kafka | Да | Да | Очень высокая | Да | Да | Средняя | Отлично подходит для больших нагрузок |
| NATS | Да | Частично (JetStream) | Очень высокая | Да | Да | Высокая | Очень быстрый, но менее универсальный |
| Redis Streams | Да | Да | Высокая | Да | Ограниченно | Высокая | Хорош для простых сценариев |
Для данной задачи я бы выбрал RabbitMQ.
Согласно условиям задания, брокер сообщений должен быть надежным, быстрым и удобным в эксплуатации.
Поддержка кластеризации
RabbitMQ поддерживает кластерный режим работы. Это позволяет развернуть несколько узлов, чтобы система продолжала работать даже при отказе одного из серверов.
Хранение сообщений на диске
RabbitMQ умеет сохранять сообщения на диск, если очередь настроена как durable, а сообщения отправляются как persistent. Это важно, потому что при сбоях сообщения не будут потеряны.
Высокая скорость работы
RabbitMQ обеспечивает высокую производительность и хорошо подходит для большинства корпоративных задач обмена сообщениями между микросервисами. Kafka может быть быстрее при очень больших объемах данных, но для типичной микросервисной системы RabbitMQ более чем достаточен.
Поддержка различных форматов сообщений
RabbitMQ не привязан к конкретному формату данных. Через него можно передавать JSON, XML, текстовые сообщения, бинарные данные и другие форматы.
Разделение прав доступа
RabbitMQ поддерживает пользователей, роли и разграничение доступа к очередям и exchange. Это позволяет ограничивать доступ разных сервисов только к тем потокам сообщений, которые им нужны.
Простота эксплуатации
По сравнению с Kafka, RabbitMQ проще в настройке и сопровождении. У него есть удобный web-интерфейс для администрирования, мониторинга очередей и управления пользователями, что делает его удобным для эксплуатации DevOps-командой.