Урок 10.1. Архитектура для тестировщика

Описание сервисов

🔹 API Gateway 🚪

Что это?
API Gateway — это точка входа для всех запросов от пользователей и внешних систем. Он управляет маршрутизацией, авторизацией и безопасностью.

Почему используется?
✅ Централизованный контроль доступа.
✅ Балансировка нагрузки.
✅ Безопасность и управление API.

Пример работы:
👤 Пользователь отправляет запрос → API Gateway проверяет авторизацию → перенаправляет запрос в нужный микросервис.

🔹 Auth Service (Сервис авторизации) 🔑

Что это?
Проверяет права пользователя и определяет, можно ли ему выполнять определённые действия.

Почему используется?
✅ Обеспечивает безопасность.
✅ Поддерживает аутентификацию по JWT или OAuth.

Пример работы:
👤 API Gateway отправляет запрос в Auth Service → Auth Service проверяет токен → возвращает результат (успешно / ошибка 401).

🔹 Transaction Service (Сервис транзакций) 💰

Что это?
Отвечает за выполнение и обработку банковских операций (переводы, платежи, пополнение счета).

Почему используется?
✅ Гарантирует выполнение транзакций (ACID).
✅ Логирует операции для аудита.

Пример работы:
📨 API Gateway отправляет платежный запрос → Transaction Service проверяет баланс → записывает в базу → отправляет события в Kafka и RabbitMQ.

🔹 RabbitMQ (Очередь сообщений) 📩

Что это?
Обрабатывает асинхронные события и уведомления пользователей.

Почему используется?
✅ Гарантия доставки сообщений.

Пример работы:
🔁 Transaction Service отправляет уведомление → RabbitMQ передает его Notification Service → пользователь получает SMS/email.

🔹 Notification Service (Сервис уведомлений) 📢

Что это?
Отправляет пользователям сообщения о выполненных операциях.

Почему используется?
✅ Разгружает Transaction Service.
✅ Позволяет легко менять механизмы уведомлений (SMS, email, push).

Пример работы:
🔁 Notification Service получает сообщение от RabbitMQ → отправляет SMS/email пользователю.

🔹 Kafka (Платформа потоковой обработки) 🔄

Что это?
Используется для передачи данных в систему аналитики и логирования.

Почему используется?
✅ Поддерживает обработку большого количества событий.
✅ Устойчив к сбоям, благодаря репликации.

Пример работы:
🔁 Transaction Service отправляет данные о транзакции в Kafka → Kibana использует эти данные для визуализации логов.

🔹 Kibana (Мониторинг) 📊

Что это?
Система визуализации логов и аналитики.

Почему используется?
✅ Показывает графики и дашборды в реальном времени.
✅ Позволяет анализировать ошибки.

Пример работы:
📊 Kibana получает данные из Kafka → отображает их на дашборде.

🔹 PostgreSQL (Реляционная база данных) 🗄

Что это?
Основное хранилище данных о пользователях, счетах и транзакциях.

Почему используется?
✅ Поддерживает сложные SQL-запросы.
✅ Гарантирует целостность данных (ACID).

Пример работы:
💾 Transaction Service сохраняет транзакцию в PostgreSQL → данные доступны для отчетов.

🔹 Redis (Кэш) ⚡

Что это?
Используется для кеширования данных и быстрого доступа.

Почему используется?
✅ Обеспечивает мгновенный доступ к часто запрашиваемым данным.
✅ Снижает нагрузку на PostgreSQL.

Пример работы:
🔄 Запрос баланса сначала ищет данные в Redis → если их нет, идёт в PostgreSQL.

💡 Различия между Kafka и RabbitMQ 🤔

💡 Когда использовать?
🔹 Kafka → если нужно обрабатывать много данных и событий.
🔹 RabbitMQ → если важна гарантированная доставка сообщений.

💡 Различия между Redis и PostgreSQL 🧐

💡 Когда использовать?
🔹 Redis → когда важна быстрая обработка данных.
🔹 PostgreSQL → когда важна целостность и надёжность данных.

Как это всё работает

1️⃣ Ты (пользователь) делаешь запрос (например, «Отправить деньги»).

2️⃣ Этот запрос попадает в API Gateway, который разбирается, куда его перенаправить.

3️⃣ API Gateway передаёт запрос в Auth Service, чтобы тот проверил:
🔹 «У тебя есть право делать переводы?»
✅ Если проверка пройдена, идём дальше.

4️⃣ Запрос на перевод летит в Transaction Service.

5️⃣ Transaction Service:
🔹 Сохраняет транзакцию в PostgreSQL (чтобы ничего не потерялось).
🔹 Отправляет уведомление в RabbitMQ (чтобы ты получил сообщение).
🔹 Шлёт данные в Kafka (для аналитики).
🔹 Обновляет Redis (кеширует данные, чтобы быстрее загружать баланс).

6️⃣ Notification Service читает уведомление из RabbitMQ и отправляет тебе на телефон или email сообщение, что «Деньги ушли туда-то».

7️⃣ Kafka передаёт данные в Kibana и внешние аналитические системы, чтобы можно было смотреть отчёты, графики и логи.

8️⃣ Kibana – это как приборная панель, показывает всё, что происходит в твоём «цифровом банке», где и что логируется, были ли ошибки и т.д. 🚀

Примеры позитивных сценариев

1. Проверка платежной транзакции

Цель: Проверить, что деньги списываются, записываются в базу, отправляется уведомление, а также что логи корректно отображаются в Kibana.

🔹 Шаги тестирования:

Отправить запрос на перевод через Postman
Проверить, что транзакция записалась в PostgreSQL

Данные должны быть внесены в таблицу

Проверить, что уведомление отправлено в RabbitMQ:

Открыть RabbitMQ Management UI
Убедиться, что сообщение попало в очередь уведомлений.

Проверить, что Kafka получила событие:

Подключиться к Kafka UI
Найти сообщение о переводе.

Проверить логи в Kibana:

Открыть Kibana
Перейти в Discover и найти запись по transaction_id.
Убедиться, что ошибок нет, лог содержит нужные поля (user_id, amount, status).

Проверить, что пользователь получил SMS/email

✅ Ожидаемый результат:

Транзакция успешно проведена.
Уведомление отправлено.
В Kibana лог с правильными параметрами.

2. Проверка получения баланса

Цель: Убедиться, что данные кешируются в Redis, а при сбое Redis данные берутся из PostgreSQL.

🔹 Шаги тестирования:

Запросить баланс пользователя через API Gateway
Проверить, что данные загружены из Redis

Баланс должен быть в Redis.

Удалить кеш (как удалить, сможешь узнать по инструкциям на проекте) и проверить повторный запрос

Данные теперь должны быть загружены из PostgreSQL.

Проверить логи в Kibana:

Найти запись в Kibana → Discover по request_id.
Убедиться, что первый запрос получил данные из Redis, второй – из PostgreSQL.

✅ Ожидаемый результат:

Данные сначала приходят из Redis.
После удаления кеша – загружаются из PostgreSQL.
В Kibana логируется источник данных.

Примеры негативных сценариев

1. Ошибка авторизации (Auth Service)

Сценарий:

Пользователь отправляет запрос с неверным токеном или вообще без токена.
Допустим, пытается сделать перевод без указания или с просроченным токеном в заголовке.

Что должно произойти?

API Gateway перенаправляет запрос в Auth Service.
Auth Service не подтверждает права доступа.
Пользователь получает ошибку (например, 401 Unauthorized или 403 Forbidden).

Как искать и диагностировать ошибку?

Postman:

Отправить запрос без токена или с поддельным токеном.
Проверить HTTP-ответ (должен быть 401 или 403).

Kibana:

В разделе Discover отфильтровать логи по дате/ID запроса.
Посмотреть, что сервис Auth Service вернул ошибку авторизации.

Убедиться, что Gateway получил запрос и действительно отдал его на Auth Service, а не «потерял» где-то.

2. Недостаточно средств на счёте (Transaction Service)

Сценарий:

Пользователь пытается перевести сумму, которая превышает баланс счёта.

Что должно произойти?

Transaction Service при обработке обнаружит, что баланс меньше требуемой суммы.
Операция должна быть отклонена.
Пользователь получает ошибку (например, 400 Bad Request с сообщением "Insufficient Funds").

Как искать и диагностировать ошибку?

Postman:

Отправить запрос с суммой больше, чем доступный баланс.
Убедиться, что сервис вернул корректный код ошибки (400 или 422) и понятное сообщение.

PostgreSQL (DBeaver):

Проверить, что транзакция не появилась в таблице transactions или имеет статус FAILED.

Kibana:

Найти лог по transaction_id и убедиться, что там есть запись об ошибке «Insufficient funds».

3. Некорректные данные запроса (API Gateway / Transaction Service)

Сценарий:

Отправить запрос с неправильным форматом JSON, отсутствием обязательных полей (например, не указать amount или to_account), или с некорректным типом (вместо числа передать строку).

Что должно произойти?

API Gateway может отклонить запрос из-за невалидного тела (400 Bad Request).
Если прошёл до Transaction Service – тот должен вернуть ошибку при парсинге / валидации данных.

Как искать и диагностировать ошибку?

Postman:

Отправить специально искажённый JSON.
Проверить код ошибки (400 Bad Request или 422 Unprocessable Entity).

Kibana:

Поиск по request_id или transaction_id.
Увидеть лог о «JSON parse error» или «Validation error».

Может оказаться, что API Gateway не пропустил запрос — смотрим его логи.

🛠 Что важно проверять

✅ RabbitMQ → Сообщения не теряются в очереди.
✅ Kafka → События корректно попадают в аналитику и Kibana.
✅ PostgreSQL → Данные правильно сохраняются и не теряются.
✅ Redis → Кеш работает и обновляется при изменениях.
✅ Kibana → Логи логируются корректно, их можно просматривать и анализировать.

📌 Правильность запросов и ответов: отправил запрос на перевод → получил корректный результат.
📌 Безопасность: никто не может украсть данные или перевести деньги без разрешения (Auth Service).
📌 Целостность данных: все транзакции верно записываются в PostgreSQL.
📌 Уведомления: проверяешь, как работает RabbitMQ и Notification Service → приходит ли пользователю сообщение?
📌 Аналитика и логи: Kafka всё ли записывает? Kibana всё ли отображает?
📌 Кеш: Redis действительно ускоряет ответ? А если кеш упадёт, система продолжит работать через PostgreSQL?

🔥 Главная задача тестировщика — убедиться, что система работает стабильно, данные не теряются, а ошибки легко отслеживаются! 🚀