База для QA
К списку уроков
Блок 2 · Клиент-серверная архитектура

Урок 6. Монолит vs Микросервисы

Архитектура современных приложений

Темы урока

Монолит (плюсы/минусы), микросервисы, синхронное/асинхронное взаимодействие, Kafka базово, баги в микросервисах

Видео урока

Пройти тест по уроку

Конспект урока

Главное за урок

Монолит или микросервисы — это инструмент, а не медаль. Shopify и Stack Overflow работают на монолите. Netflix и Uber — на микросервисах. Выбор определяет размер команды, продукт и скорость роста.

В микросервисах «у меня работает» — это правда: баг живёт на стыке. Каждый сервис может быть исправным, но вместе они дадут неверный результат. QA думает не «что сломалось», а «где потерялся запрос».

Асинхронное взаимодействие через брокер меняет подход к тестированию. Нельзя сразу после действия ожидать мгновенного результата — нужно дать системе время обработать сообщение.

Монолит: всё в одном

Весь код — каталог, корзина, оплата, уведомления — живёт в единой кодовой базе. Разрабатывается, тестируется и деплоится как неделимый блок.

Плюсы монолита:

  • Простота разработки и деплоя на старте.
  • Один стек, один проект, единое окружение.
  • Легко дебажить: всё в одном месте.

Минусы с ростом:

  • Один маленький фикс — нужно пересобрать и перетестировать всё.
  • Баг в модуле каталога может положить страницу оплаты.
  • Нельзя масштабировать только нагруженную часть.

Трёхуровневая архитектура (Presentation / Logic / Data) — это структурированный монолит. Код стал чище, но деплой остался единым.

Микросервисы: каждая функция — отдельный сервис

Каждая бизнес-функция — отдельный маленький сервис со своим кодом, базой данных и командой.

Что делает сервис по-настоящему независимым:

  • Своя база данных или схема — нельзя сделать JOIN к чужой таблице.
  • Свой стек: один сервис на Go, другой на Python — это нормально.
  • Свой цикл деплоя: фикс в каталоге не блокирует релиз оплаты.

Преимущества на практике:

  • Упал сервис уведомлений — заказы продолжают приниматься.
  • Нагрузка выросла на оплату — масштабируем только её.
  • Изменили каталог — деплоим и тестируем только каталог.

Синхронное vs асинхронное взаимодействие

Тип Как работает Протоколы Пример
Синхронное Сервис А ждёт ответа сервиса Б HTTP/REST, gRPC Проверка наличия пиццы перед заказом
Асинхронное Отправил — не ждёт, продолжает работу Kafka, RabbitMQ Уведомление об оформлении заказа

API Gateway — единая точка входа: пользователь стучится в один шлюз, а тот маршрутизирует запросы к нужным сервисам. Для QA: одна точка для тестирования, централизованные логи и авторизация.

Брокеры сообщений: RabbitMQ и Kafka

RabbitMQ — классическая очередь

  • Exchange маршрутизирует сообщение в нужную Queue.
  • Consumer читает — сообщение удаляется после обработки.
  • QA проверяет: сообщение доставлено, Consumer упал → сообщение вернулось в очередь или потерялось? Дублирование при повторной доставке?

Kafka — журнал событий

  • Топик хранит события заданное время, не удаляет после прочтения.
  • Несколько Consumer Group читают независимо.
  • Порядок гарантирован внутри Partition.
  • QA проверяет: Lag (отставание Consumer), перечитку по offset, что при откате пользователь не видит устаревшие данные.
Kafka RabbitMQ
Хранение Журнал, сообщения не удаляются Удаляется после прочтения
Перечитать Да, через offset Нет
Нагрузка Миллионы событий/сек Меньше, но гибче маршрутизация
Для QA Легко воспроизвести, есть история Труднее проверить, что именно пришло

Три типа багов, которых нет в монолите

  1. Баг на стыке — каждый сервис работает корректно, но вместе дают неверный результат.
  2. Потерянное сообщение — событие ушло в брокер, но до получателя не дошло, и никто не заметил.
  3. Гонка состояний — два сервиса обновили один объект одновременно, победил последний, а не правый.

Чек-лист QA для асинхронных флоу

  1. Проверить промежуточные статусы: «в обработке», «ожидает отправки», «в очереди».
  2. Дать системе время — не ждать мгновенного результата после действия.
  3. Симулировать недоступность Consumer: сообщение пришло позже, когда сервис вернулся?
  4. Проверить дублирование: что будет, если одно событие придёт в брокер дважды?
  5. Проверить Lag: если Consumer отстаёт — видит ли пользователь устаревшие данные?

Ключевые тезисы для теста

  • Монолит — единый деплой, единая кодовая база; с ростом превращается в узкое место.
  • Микросервисы — каждый сервис со своей БД, стеком и командой; деплоятся независимо.
  • Синхронное взаимодействие — клиент ждёт ответа (HTTP/gRPC). Асинхронное — отправил и забыл, брокер сам доставит.
  • RabbitMQ удаляет сообщение после прочтения. Kafka хранит журнал и позволяет перечитать.
  • В микросервисах баг часто живёт на стыке — каждый сервис «у меня работает», а вместе они дают сбой.
  • Три новых класса багов: стык, потеря сообщения, гонка состояний.
  • QA в асинхронной системе всегда проверяет промежуточные статусы и дублирование.

Полезные ссылки