Skip to content

README.md

Latest commit

 

History

History
103 lines (77 loc) · 11.2 KB

README.md

File metadata and controls

103 lines (77 loc) · 11.2 KB

Домашнее задание к занятию "Микросервисы: принципы" - Молоствов Андрей

Задание 1

Сравнение решений для API Gateway

1. Kong Gateway (Open Source)

  • Маршрутизация: Да, на основе конфигурации (Admin API или декларативные файлы).
  • Аутентификация: Отлично. Богатая экосистема плагинов: JWT, OAuth2, Key-Auth, LDAP и др.
  • HTTPS: Поддерживается терминация HTTPS.
  • Особенности: Построен на NGINX, требует БД (или DB-less режим), огромная библиотека плагинов.

2. NGINX (Open Source)

  • Маршрутизация: Да, через конфигурационные файлы (.conf, блоки localhost).
  • Аутентификация: Слабо. Базовая HTTP-аутентификация; для JWT/OAuth2 нужна компиляция модулей или сложные скрипты.
  • HTTPS: Эталонная реализация, лучшая в классе.
  • Особенности: Высочайшая производительность, но требует ручного написания конфигов и reload при изменениях.

3. Traefik

  • Маршрутизация: Да, отличная интеграция с Docker, Kubernetes, Swarm.
  • Аутентификация: Хорошо. Встроенные middleware (Basic, Digest, JWT, ForwardAuth).
  • HTTPS: Да, автоматическое получение сертификатов Let's Encrypt.
  • Особенности: Низкий порог входа в контейнерных средах, динамическая конфигурация.

4. Yandex API Gateway (SaaS)

  • Маршрутизация: Да, на основе спецификации OpenAPI.
  • Аутентификация: Да, интеграция с Yandex IAM и Cloud Functions.
  • HTTPS: Да (полностью управляется платформой).
  • Особенности: Serverless-решение, не требует администрирования, масштабируется автоматически, но привязывает к провайдеру.

Обоснование выбора (API Gateway)

На основе сравнительного анализа в качестве основного решения предлагается использовать Kong Gateway (Open Source).

Почему Kong Gateway?

  1. Полное соответствие требованиям: Kong из коробки решает все три поставленные задачи:

    • Гибкая маршрутизация запросов на основе конфигурации (через Admin API или декларативные файлы).
    • Мощная система аутентификации (JWT, OAuth2, Key-Auth, Basic Auth и другие плагины).
    • Поддержка терминации HTTPS с управлением SSL-сертификатами.

  2. Богатая экосистема: В отличие от чистого NGINX, Kong предлагает библиотеку из более чем 100 готовых плагинов. Это позволяет добавлять функциональность (аутентификацию, rate limiting, трансформацию запросов) без написания сложного кода и перекомпиляции модулей.

  3. Баланс функциональности и сложности: Kong проще в эксплуатации, чем "чистый" NGINX с самописными скриптами, но при этом не привязывает к конкретному облачному провайдеру (в отличие от Yandex API Gateway).

Почему не другие варианты?

  • NGINX: Хотя NGINX превосходно справляется с маршрутизацией и HTTPS, его возможности аутентификации "из коробки" минимальны. Реализация JWT или OAuth2 потребовала бы сложной доработки (компиляция сторонних модулей или написание скриптов на Lua), что усложняет поддержку системы.
  • Traefik: Отличное решение для контейнерных сред (Kubernetes, Docker Swarm). Однако Kong предлагает более богатую экосистему именно для управления API (тонкая настройка политик безопасности, трансформация трафика, аналитика) и чаще выбирается, когда требуется не просто прокси-сервер, а полноценный API Gateway.
  • Yandex API Gateway (SaaS): Это хороший managed-вариант, если инфраструктура полностью развернута в Yandex.Cloud. Однако он привязывает архитектуру к конкретному провайдеру (vendor lock-in), тогда как Kong — платформонезависимое решение, которое можно развернуть где угодно: в любом облаке или on-premises.

Задание 2

Сравнение решений для брокера сообщений

1. RabbitMQ

  • Кластеризация и надежность: Да (кластеризация, очереди с зеркалированием / Quorum queues).
  • Хранение на диске: Да (персистентные сообщения, запись на диск до подтверждения).
  • Скорость работы: Высокая (миллисекунды, до десятков тысяч сообщений в секунду).
  • Форматы сообщений: Любые (бинарный массив данных).
  • Разделение прав: Да (пользователи, vhosts, ACL).
  • Простота эксплуатации: Очень высокая (интуитивный веб-интерфейс, понятная документация, легко настраивать).

2. Apache Kafka

  • Кластеризация и надежность: Эталонная (репликация партиций, строгая согласованность).
  • Хранение на диске: Да (основной режим работы, хранение с retention-политиками).
  • Скорость работы: Очень высокая (миллионы сообщений/сек).
  • Форматы сообщений: Любые (поддержка Avro, Protobuf через Schema Registry).
  • Разделение прав: Да (SSL, SASL, ACL для топиков).
  • Простота эксплуатации: Средняя (требует понимания партиционирования, ZooKeeper/KRaft, сложный мониторинг).

3. ActiveMQ (Artemis)

  • Кластеризация и надежность: Да (кластеризация, репликация).
  • Хранение на диске: Да.
  • Скорость работы: Средняя/Высокая.
  • Форматы сообщений: Любые (поддержка JMS).
  • Разделение прав: Да (JAAS, ACL).
  • Простота эксплуатации: Высокая (консоль, JMX).

4. NATS (с JetStream)

  • Кластеризация и надежность: Да (NATS JetStream, кластеризация, репликация).
  • Хранение на диске: Да (только в режиме JetStream).
  • Скорость работы: Экстремальная.
  • Форматы сообщений: Любые.
  • Разделение прав: Да (пользователи, разрешения на pub/sub).
  • Простота эксплуатации: Высокая (легковесный, простой запуск).

Обоснование выбора (Брокер сообщений)

На основе сравнительного анализа в качестве основного решения предлагается использовать RabbitMQ.

Почему RabbitMQ?

  1. Баланс скорости и надежности: RabbitMQ обеспечивает высокую скорость работы (достаточную для подавляющего большинства микросервисных архитектур) и гарантирует сохранность сообщений благодаря записи на диск и кластеризации (Quorum queues).
  2. Гибкость форматов: Брокер не накладывает ограничений на форматы — можно передавать JSON, XML, Protobuf, Avro и любые бинарные данные.
  3. Безопасность из коробки: Поддерживает гибкое разделение прав доступа через пользователей и виртуальные хосты (vhosts).
  4. Простота эксплуатации: Это ключевое преимущество. RabbitMQ имеет лучший в своем классе веб-интерфейс для мониторинга, отладки и управления очередями, что критически важно для команд, эксплуатирующих систему.

Почему не другие варианты?

  • Apache Kafka: Это индустриальный стандарт для потоковой обработки данных и сбора логов. Однако он избыточен и сложен в эксплуатации для типовых задач микросервисной коммуникации (простые очереди задач, RPC). Требование "высокая скорость" у RabbitMQ выполняется с запасом для стандартных сценариев, а эксплуатация Kafka значительно сложнее (управление партициями, офсетами, ZooKeeper/KRaft).
  • ActiveMQ: Уступает RabbitMQ по скорости и удобству современного мониторинга.
  • NATS: В режиме JetStream обеспечивает высокую скорость и надежность, но экосистема RabbitMQ более зрелая, а сообщество — шире, что облегчает поиск решений типовых проблем и интеграцию.