Microservices, k8s, observability | Quizlet

Что такое монолит? В чём плюсы и минусы монолита?

Монолит — это архитектурный подход, при котором всё приложение разрабатывается и деплоится как единая кодовая база.

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

- Простота разработки и отладки (всё в одном месте)

- Легче управлять транзакциями и целостностью данных

- Нет сетевых задержек между компонентами

- Проще начать проект и быстрее выйти на рынок

- Один процесс деплоя

Минусы монолита:

- Сложно масштабировать отдельные части системы

- Любое изменение требует пересборки и переразвертывания всего приложения

- Технологический стек фиксирован для всего проекта

- При падении одного модуля падает всё приложение

- С ростом кодовой базы усложняется поддержка

Частая ошибка: Считать монолит антипаттерном. Для многих проектов монолит — оптимальное решение.

Что такое микросервисы, в чём плюсы и минусы микросервисов?

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

Плюсы микросервисов:

- Независимое масштабирование каждого сервиса

- Возможность использовать разные технологии для разных сервисов

- Независимый деплой сервисов

- Изоляция сбоев (падение одного сервиса не валит всю систему)

- Проще организовать работу больших команд

Минусы микросервисов:

- Сложность распределённой системы (сеть, задержки, частичные отказы)

- Трудности с транзакциями между сервисами

- Необходимость в дополнительной инфраструктуре (service discovery, API gateway, monitoring)

- Дублирование кода и усилий

- Сложность отладки и трассировки

Практическое правило: Начинай с монолита, переходи на микросервисы при реальной необходимости.

Что такое модульный монолит, в чём его плюсы и минусы?

Модульный монолит — это архитектурный подход, при котором приложение остаётся единым деплой-юнитом, но внутри чётко разделено на изолированные модули с явными границами.

Плюсы модульного монолита:

- Простота деплоя как у монолита

- Чёткие границы между модулями как у микросервисов

- Возможность в будущем легко выделить модули в отдельные сервисы

- Нет сетевых задержек между модулями

- Единая транзакционность

Минусы модульного монолита:

- Требует дисциплины для поддержания границ между модулями

- Всё ещё невозможно масштабировать отдельные модули

- Один технологический стек для всех модулей

- При деплое обновляется всё приложение

Аналогия: Модульный монолит — как многокомнатная квартира с чёткими границами между комнатами, а обычный монолит — как студия без перегородок.

Что тебе больше нравится, монолит или микросервисы?

Это зависит от контекста проекта. Нет универсально правильного выбора.

Монолит предпочтительнее когда:

- Стартап или MVP (скорость выхода на рынок критична)

- Небольшая команда (до 10-15 разработчиков)

- Предметная область ещё не устоялась

- Нет требований к независимому масштабированию частей

Микросервисы оправданы когда:

- Большая команда (50+ разработчиков)

- Разные части системы имеют кардинально разные требования к нагрузке

- Нужна технологическая гибкость для разных компонентов

- Критична изоляция сбоев

Практический совет: Начинай с модульного монолита. Это даст гибкость перейти на микросервисы, когда (и если) это потребуется.

Частая ошибка: Выбирать микросервисы из-за хайпа, а не из реальной необходимости.

Почему монолит тяжело скейлить?

Главная проблема скейлинга монолита — большинство монолитов написаны плохо.

Почему плохо написанные монолиты сложно скейлить:

- Думают, что они единственные в системе

- Долго стартуют и потребляют много памяти

- Используют локальные блокировки (семафоры) вместо распределённых

- Держат данные в памяти как кэш перед записью в БД

- Не рассчитаны на работу в нескольких экземплярах

Если монолит написан хорошо, его можно скейлить. Но остаётся проблема:

- Разным частям монолита нужны разные ресурсы

- Графике нужны GPU

- Вычислениям нужны CPU

- Отправке уведомлений нужна пропускная способность сети

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

Вывод: Проблема не в самом монолите, а в том, что сложно масштабировать специфические части с нетипичными требованиями к ресурсам.

Как тестировать микросервисы? Как локально запускать сервисы для тестов? Что делать с зависимостями сервисов? А если сервис зависел от других сервисов?

Тестирование микросервисов требует особого подхода к управлению зависимостями.

Способы локального запуска:

- Docker Compose — запускаешь все нужные сервисы локально в контейнерах

- Подключение к dev окружению — твой сервис локально, а зависимости на dev сервере

- WireMock — мокируешь HTTP ответы от других сервисов

Работа с зависимостями:

- Для быстрых тестов — используй моки (WireMock, заглушки в коде)

- Для интеграционных тестов — Docker Compose с минимальным набором сервисов

- Для полноценной проверки — деплой на dev/stage окружение

Если сервис зависит от других сервисов:

- Определи минимальный набор зависимостей для локальной работы

- Используй контракты API, чтобы мокировать правильные ответы

- Держи docker-compose.yml с настроенными зависимостями в репозитории

Практический совет: Не пытайся запустить всю систему локально. Работай с минимальным набором зависимостей и используй dev окружение для полноценного тестирования.

Как организовано хранение данных в микросервисах? Нормально ли, чтобы все микросервисы читали и писали данные из одних и тех же таблиц? Нормально ли, чтобы каждый сервис писал только в свои таблицы, а читал из любых? Нормально ли, чтобы микросервис читал и писал только в свои таблицы, но у всех микросервисов таблицы были бы в одной БД?

При переходе на микросервисы хранение данных меняется постепенно.

На старте миграции:

- Абсолютно нормально, если все сервисы ходят в одну БД

- Это временное решение, которое упрощает начало перехода

Целевое состояние:

- Каждый сервис владеет своими таблицами

- Сервис читает и пишет только в свои таблицы

- Данные — это деталь реализации сервиса, не часть API

- За данными другого сервиса ходим только через его API

Почему нельзя читать чужие таблицы:

- Если структура БД изменится, сломаются все клиенты

- Создаётся скрытая связанность между сервисами

- Невозможно независимо развивать сервисы

Компромиссное решение:

- Все таблицы в одной БД, но каждая принадлежит только одному сервису

- Только владелец таблицы может её читать и писать

- При масштабировании может стать проблемой, но для начала это нормально

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

Расскажи, как распиливать монолит на микросервисы. Как при миграции сделать так, чтобы данные остались согласованными?

Распиливание монолита происходит постепенно через Strangler Fig Pattern — новая система постепенно "душит" старую.

Процесс миграции:

1. Выделяешь границы будущего сервиса в монолите

2. Создаёшь новый микросервис рядом с монолитом

3. Начинаешь писать данные в оба места — и в монолит, и в микросервис

4. Читаешь пока из монолита

5. Запускаешь background job для миграции исторических данных

6. После миграции переключаешь чтение на микросервис

7. Убираешь запись в монолит

8. Удаляешь старый код из монолита

Обеспечение согласованности:

- Dual writes — пишем в оба места одновременно

- Background job мигрирует старые данные из монолита в микросервис

- Reconciliation job проверяет, что данные синхронизированы

- Постепенное переключение трафика с мониторингом ошибок

Важно:

- Не пытайся мигрировать всё сразу

- Начни с наименее критичной функциональности

- Всегда имей план отката

- Мониторь расхождения в данных

Как сделать транзакции в микросервисах? Расскажи про распределённые транзакции

В микросервисах нет классических ACID транзакций между сервисами. Используются паттерны для eventual consistency.

Saga Pattern:

- Цепочка локальных транзакций в каждом сервисе

- При ошибке запускаются компенсирующие транзакции

- Пример: Заказ → Резервирование товара → Оплата → Доставка

- Если оплата не прошла → отменяем резервирование

Two-Phase Commit (2PC):

- Сначала все участники подготавливаются (prepare)

- Потом все одновременно фиксируют изменения (commit)

- Блокирующий протокол, редко используется из-за проблем с производительностью

Outbox Pattern:

- В той же транзакции с бизнес-данными сохраняем событие в таблицу outbox

- Отдельный процесс читает outbox и отправляет события

- Гарантирует, что событие будет отправлено, если транзакция успешна

Практический подход:

- Проектируй систему так, чтобы eventual consistency была достаточна

- Используй Saga для бизнес-процессов

- Outbox для гарантированной доставки событий

Одному сервису нужны данные другого, как их получить? А если много данных надо?

Получение данных между сервисами зависит от объёма и частоты обращений.

Начинаем с простого:

- Синхронный HTTP/gRPC запрос для получения данных

- Подходит для небольших объёмов и редких запросов

Если данных много или запросы частые:

- Кэширование ответов на своей стороне

- Помогает снизить нагрузку, но данные могут устареть

Если данные нужны постоянно и обновляются:

- Создаём локальную копию данных в своём сервисе

- Подписываемся на события изменений от сервиса-владельца

- Background job делает начальную миграцию всех нужных данных

- События поддерживают копию в актуальном состоянии

Change Data Capture (CDC):

- Автоматически отслеживает изменения в БД

- Публикует события об изменениях

- Другие сервисы подписываются и обновляют свои копии

Важно: Дублирование данных в микросервисах — это нормально. Лучше иметь локальную копию в нужном формате, чем постоянно дёргать другой сервис.

Что такое dev, stage, prod окружения? Чем они отличаются?

Окружения — это отдельные изолированные среды для запуска приложения на разных этапах разработки.

Dev (Development):

- Для активной разработки

- Часто ломается, это нормально

- Тестовые данные

- Может быть нестабильным

- Доступ у всех разработчиков

Stage (Staging):

- Копия production окружения

- Для финального тестирования перед релизом

- Данные максимально похожи на prod

- Стабильное, изменения только через процесс

- Доступ у QA и части разработчиков

Prod (Production):

- Боевое окружение с реальными пользователями

- Реальные данные

- Максимальная стабильность

- Изменения только через строгий процесс

- Ограниченный доступ

Ключевое отличие — уровень стабильности и критичности. В dev можно экспериментировать, в prod любая ошибка влияет на реальных пользователей.

Что такое хайлоад для тебя? Это только количество запросов? Если запросы простые, то это хайлоад?

Хайлоад — это не абсолютные числа, а система под нагрузкой, близкой к пределу её возможностей.

Факторы хайлоада:

- RPS (requests per second) — но не единственный показатель

- Объём обрабатываемых данных

- Сложность вычислений

- Требования к задержкам (latency)

- Количество одновременных соединений

- Интенсивность I/O операций

Примеры разных типов хайлоада:

- 1M простых запросов чтения из кэша

- 100 запросов с обработкой видео

- 10K конкурентных WebSocket соединений

- Обработка 1TB данных в реальном времени

Ключевые метрики:

- CPU utilization

- Memory usage

- Network I/O

- Disk I/O

- Queue depth

- Response time percentiles (p50, p95, p99)

Практическое определение: Хайлоад начинается там, где вертикальное масштабирование перестаёт помогать.

Расскажи про observability. Что такое (структурные) логи, метрики, распределённые трейсы?

Observability — способность понимать, что происходит внутри системы, глядя на её выходные данные.

Структурированные логи:

- Логи, где сообщение и данные хранятся отдельно

- Вместо "User 123 logged in" → message: "User logged in", userId: 123

- Легко фильтровать и искать по параметрам

- Можно строить дашборды по данным из логов

Метрики:

- Числовые показатели работы системы

- Примеры: количество запросов, время ответа, использование CPU

- Агрегируются и показываются на графиках

- Помогают понять тренды и найти аномалии

Распределённые трейсы:

- Отслеживание пути запроса через все микросервисы

- Показывают, сколько времени заняла каждая операция

- Помогают найти bottlenecks в системе

- Видно полную картину обработки запроса

Как они работают вместе:

- Метрики показывают, что есть проблема

- Трейсы показывают, где именно проблема

- Логи показывают, почему возникла проблема

Как для observability связывать запросы в разные сервисы (через http, gRPC, брокеры) в одну цепочку?

Связывание запросов происходит через передачу специальных идентификаторов между сервисами.

Основные идентификаторы:

- Trace ID — уникальный ID для всей цепочки запросов

- Span ID — ID конкретной операции

- Parent Span ID — связь с родительской операцией

Как передаются:

- HTTP — через заголовки запроса

- gRPC — через метаданные

- Message Brokers — через заголовки сообщений

Как это работает:

1. Первый сервис генерирует Trace ID

2. При вызове другого сервиса передаёт его в заголовках

3. Второй сервис извлекает Trace ID и использует его

4. Все логи и метрики помечаются этим Trace ID

5. По Trace ID можно найти все связанные операции

Практический пример:

- Пользователь создаёт заказ

- API Gateway генерирует Trace ID: "abc123"

- Order Service получает заголовок с "abc123"

- Payment Service тоже получает "abc123"

- В системе мониторинга по "abc123" видна вся цепочка

Зачем нужна Grafana? Расскажи про типы метрик, приведи примеры кастомных метрик. Какие бывают графики?

Grafana — инструмент для визуализации метрик. Берёт данные из разных источников и показывает красивые графики.

Основные типы метрик:

- Counter — только растёт (количество запросов, ошибок)

- Gauge — может расти и падать (CPU usage, активные соединения)

- Histogram — распределение значений (время ответа по percentiles)

Примеры кастомных бизнес-метрик:

- Количество созданных заказов

- Сумма продаж за час

- Количество активных пользователей

- Процент отменённых заказов

- Среднее время обработки заявки

Примеры технических метрик:

- Размер очереди сообщений

- Количество горячих потоков

- Процент попаданий в кэш

- Задержка репликации БД

Типы визуализаций:

- График временного ряда — как менялось значение

- Одиночное число — текущее значение метрики

- Тепловая карта — распределение значений

- Таблица — список с данными

- Круговая диаграмма — распределение по категориям

Зачем это нужно: На одном дашборде видишь здоровье всей системы и можешь быстро найти проблемы.

Расскажи про алерты. Как они работают? На что реагировать, куда их отправлять?

Алерты — автоматические уведомления, когда что-то идёт не так в системе.

Как работают:

1. Задаёшь правило (например: "ошибок больше 1% в минуту")

2. Система проверяет правило каждые N секунд

3. Если условие выполнилось — создаётся алерт

4. Алерт отправляется в настроенные каналы

На что стоит алертить:

- Сервис недоступен

- Много ошибок (error rate > threshold)

- Медленные ответы (latency > threshold)

- Заканчивается место на диске

- Высокая нагрузка на CPU/память

- Бизнес-метрики (0 заказов за час — что-то сломалось)

Куда отправлять:

- Критичные проблемы — звонок/SMS дежурному

- Важные — Slack/Teams канал команды

- Информационные — email или тикет в Jira

- В нерабочее время — только критичные дежурному

Важные правила:

- Не создавай слишком много алертов — их перестанут замечать

- Каждый алерт должен требовать действия

- К алерту должна быть инструкция, что делать

Что такое k8s? Какие компоненты знаешь? Что такое Service, Deployment, Pod, в чём между ними разница?

Kubernetes (k8s) — система для управления контейнерами. Автоматически запускает, масштабирует и следит за приложениями в контейнерах.

Зачем нужен Kubernetes:

- Автоматически перезапускает упавшие контейнеры

- Распределяет нагрузку между серверами

- Легко масштабировать приложения

- Обновляет приложения без простоя

Основные компоненты для разработчика:

Pod:

- Самая маленькая единица в k8s

- Обычно один контейнер (твоё приложение)

- Временный — может умереть и переехать на другой сервер

- Не создаём Pods напрямую

Deployment:

- Описание того, как запускать твоё приложение

- Говоришь "хочу 3 копии моего приложения"

- Следит, чтобы всегда работало нужное количество

- Умеет обновлять приложение без простоя

Service:

- Постоянный адрес для доступа к твоим Pods

- Pods могут умирать и создаваться — Service остаётся

- Распределяет запросы между всеми живыми Pods

- Другие приложения обращаются к твоему через Service

Простая аналогия: Pod — работник, Deployment — менеджер который следит за работниками, Service — ресепшн который направляет клиентов к свободным работникам.

Что в k8s происходит при деплое? Почему он происходит без даунтайма?

При деплое в Kubernetes происходит постепенная замена старой версии на новую (Rolling Update).

Как происходит обновление:

1. Есть 3 пода со старой версией, все работают

2. K8s создаёт 1 под с новой версией

3. Проверяет, что новый под запустился и готов (healthcheck)

4. Направляет часть трафика на новый под

5. Убивает 1 старый под

6. Повторяет пока все поды не обновятся

Почему нет простоя:

- Всегда есть работающие поды (старые или новые)

- Новый под начинает получать трафик только когда готов

- Старый под прекращает получать новый трафик, но доделывает текущие запросы

- Если новая версия не работает — откатываемся на старую

ReplicaSet:

- Следит за нужным количеством подов

- При обновлении создаётся новый ReplicaSet

- Старый ReplicaSet постепенно уменьшается до 0

- При откате просто возвращаем поды старому ReplicaSet

Graceful Shutdown:

- Под получает сигнал "пора умирать"

- Перестаёт принимать новые запросы

- Доделывает текущие запросы

- Только потом умирает

Как в k8s работает DNS?

DNS в Kubernetes — это система, которая позволяет сервисам находить друг друга по именам, а не по IP адресам.

Зачем нужен DNS:

- IP адреса подов постоянно меняются

- Запоминать IP неудобно и ненадёжно

- По имени обращаться проще и понятнее

Как работает:

- Каждый Service автоматически получает DNS имя

- Формат: имя-сервиса.namespace

- Можно обращаться просто по имени внутри одного namespace

Примеры:

- user-service — если обращаешься из того же namespace

- user-service.production — из другого namespace

- database.default — база данных в default namespace

Что происходит при обращении:

1. Твой под спрашивает "где user-service?"

2. DNS отвечает IP адресом Service

3. Service направляет запрос на один из живых подов

4. Всё происходит автоматически

Практический пример:

Вместо http://10.0.0.15:8080 пишешь http://user-service:8080

Если user-service переедет — твой код продолжит работать.

Что такое healthcheck в k8s? Что такое live, ready, startup probe?

Healthcheck — это проверки, которые k8s делает, чтобы понять, жив ли твой под и готов ли он принимать запросы.

Liveness Probe (проверка "жив ли под"):

- K8s периодически спрашивает "ты жив?"

- Обычно HTTP запрос на /health

- Если под не отвечает или отвечает ошибкой — k8s его перезапускает

- Защищает от зависших приложений

Readiness Probe (проверка "готов ли принимать трафик"):

- K8s спрашивает "ты готов работать?"

- Например, проверяет подключение к БД

- Если не готов — k8s не направляет на него запросы

- Но не перезапускает (может само починится)

Startup Probe (проверка при старте):

- Для приложений, которые долго стартуют

- Даёт время на инициализацию

- Пока startup probe не пройдёт — другие проверки не работают

- Предотвращает ненужные рестарты медленных приложений

Как настраивается (обычно HTTP GET):

- URL для проверки (/health, /ready)

- Как часто проверять

- Сколько неудач до действия

- Timeout запроса

Пример: Твоё приложение при старте загружает большой кэш 2 минуты. Без startup probe k8s решит, что оно зависло и перезапустит. С probe — подождёт.

Что такое Helm? Зачем нужны package managers для k8s?

Helm — это пакетный менеджер для Kubernetes, как npm для JavaScript или pip для Python.

Проблема, которую решает Helm:

- Для запуска приложения в k8s нужно много YAML файлов

- Deployment, Service, ConfigMap, Secrets и т.д.

- Для разных окружений (dev/prod) нужны разные настройки

- Вручную управлять версиями и изменениями сложно

Что даёт Helm:

- Упаковывает все YAML файлы в один пакет (Chart)

- Позволяет устанавливать приложение одной командой

- Параметризация через переменные

- Версионирование и откаты

- Переиспользование готовых решений

Как работает:

1. Chart — это папка с шаблонами YAML файлов

2. Values.yaml — файл с переменными (порты, образы, реплики)

3. helm install — подставляет переменные и устанавливает

4. helm upgrade — обновляет до новой версии

5. helm rollback — откатывает если что-то пошло не так

Пример использования:

- Нужно установить PostgreSQL в k8s

- Вместо написания всех YAML файлов

- helm install postgresql bitnami/postgresql

- Получаешь работающую БД с мониторингом и бэкапами

Важно: Не все используют Helm. Для простых приложений может быть избыточен.

Как управлять секретами в микросервисах? Что такое Secret Management?

Secret Management — это безопасное хранение и управление чувствительными данными приложений.

Какие секреты нужны приложениям:

- Connection strings к базам данных

- Подключения к кэшам (Redis, Memcached)

- API ключи внешних сервисов

- Адреса других микросервисов

- Сертификаты и пароли

Проблема с окружениями:

- Один код запускается на dev, stage, prod

- На каждом окружении свои БД, свои пароли

- Нельзя захардкодить в коде

- Нельзя закоммитить в git

Решение — Secret Management системы:

- Централизованное хранилище для всех секретов

- Шифрование данных

- Контроль доступа (кто может читать какие секреты)

- Аудит (кто и когда обращался)

Популярные системы:

- Kubernetes Secrets — встроен в k8s

- AWS Secrets Manager — для AWS

- Azure Key Vault — для Azure

- Google Secret Manager — для GCP

Как работает:

1. Секреты загружаются в защищённое хранилище

2. Приложение при старте запрашивает нужные секреты

3. Получает их и использует для подключения к БД и сервисам

4. В коде нет паролей, только ссылки на секреты

Что такое blue-green deployment, canary deployment, feature flags?

Это стратегии безопасного выката новых версий, чтобы можно было быстро откатиться при проблемах.

Blue-Green Deployment:

- Две одинаковые среды: Blue (текущая) и Green (новая)

- Обновляешь Green среду

- Тестируешь, что всё работает

- Переключаешь весь трафик с Blue на Green

- Если проблемы — мгновенно переключаешь обратно

- Нужно в 2 раза больше ресурсов

Canary Deployment:

- Выкатываешь новую версию на малую часть пользователей (5-10%)

- Смотришь метрики, сравниваешь с основной версией

- Если всё хорошо — увеличиваешь процент

- Если плохо — откатываешь только канарейку

- Меньше риска, чем сразу на всех

Feature Flags:

- Новая функциональность в коде, но выключена флагом

- Деплоишь код со всеми

- Включаешь функцию только для тестовой группы

- Можешь включать/выключать без деплоя

- Удобно для A/B тестов

Когда что использовать:

- Blue-Green — когда нужна возможность мгновенного отката

- Canary — когда хочешь минимизировать риски

- Feature Flags — для управления функциональностью

Что такое SLA?

SLA (Service Level Agreement) — договорённость о качестве предоставляемого сервиса с конкретными измеримыми показателями.

Ключевые компоненты SLA:

- SLI (Service Level Indicators) — метрики (latency, error rate)

- SLO (Service Level Objectives) — целевые значения (99.9% uptime)

- Последствия нарушения — компенсации, штрафы

Типичные SLA метрики:

- Availability (99.9% = 43.8 минут downtime в месяц)

- Response time (95% запросов < 200ms)

- Throughput (обработка 1000 RPS)

- Error rate (< 0.1% ошибок)

Error Budget:

- Допустимое время/количество сбоев

- 99.9% SLA = 0.1% error budget

- Используется для балансировки между скоростью и стабильностью

Внутренние vs Внешние:

- Внешние — контракт с клиентами

- Внутренние — договорённости между командами

Частая ошибка: Обещать больше, чем можешь обеспечить. Лучше 99.5% и выполнять, чем 99.99% и нарушать.

Расскажи про алгоритмы балансировщика нагрузки, какие знаешь?

Балансировщик нагрузки распределяет входящие запросы между несколькими репликами твоего сервиса.

Зачем нужен:

- У тебя запущено 5 копий микросервиса

- Нужно распределить запросы между ними

- Если одна копия упала — направлять на живые

- Равномерно нагружать все копии

Основные алгоритмы:

Round Robin (по кругу):

- 1й запрос → сервер 1

- 2й запрос → сервер 2

- 3й запрос → сервер 3

- 4й запрос → снова сервер 1

- Простой, но не учитывает нагрузку серверов

Random (случайный):

- Каждый запрос идёт на случайный сервер

- При большом количестве запросов распределение равномерное

- Очень простой в реализации

Least Connections (минимум соединений):

- Новый запрос идёт на сервер с минимумом активных соединений

- Хорош для long-lived connections (WebSocket)

- Учитывает реальную нагрузку

Weighted (с весами):

- Мощному серверу даёшь вес 3

- Слабому серверу даёшь вес 1

- Мощный получит в 3 раза больше запросов

IP Hash:

- Запросы с одного IP всегда идут на один сервер

- Нужно для сохранения сессии без sticky sessions

- Проблемы при добавлении/удалении серверов

Что такое API Gateway? Зачем он нужен?

API Gateway — это входные ворота в твою систему микросервисов. Все запросы от клиентов идут через него.

Что делает API Gateway:

- Принимает запросы от клиентов

- Решает, какому микросервису передать запрос

- Может блокировать часть запросов (например, без авторизации)

- Защищает от DDoS атак (rate limiting)

- Кэширует частые запросы

Зачем нужен:

- Клиенты не знают про внутреннюю структуру микросервисов

- Единая точка для авторизации и аутентификации

- Можно менять микросервисы, не трогая клиентов

- Собирает логи и метрики всех запросов

Что может делать:

- Проверка токенов авторизации

- Ограничение количества запросов (100 в минуту)

- Трансформация запросов (добавить заголовки)

- Объединение ответов от нескольких сервисов

- Retry при ошибках

Простая аналогия:

API Gateway — как охрана на входе в бизнес-центр. Проверяет документы, знает куда направить посетителя, не пускает подозрительных, ведёт журнал всех визитов.

Популярные решения: Kong, Traefik, NGINX, AWS API Gateway

Что такое Backend For Frontend (BFF)? Зачем он нужен?

BFF — это специальный backend-сервис, созданный для конкретного типа клиента (мобильное приложение, веб-сайт).

Проблема, которую решает:

- Мобильному приложению нужны одни данные в одном формате

- Веб-сайту — другие данные в другом формате

- Делать универсальное API неудобно — overfetching или underfetching

Что делает BFF:

- Ходит в нужные микросервисы за данными

- Собирает именно то, что нужно конкретному клиенту

- Форматирует данные под клиента

- Возвращает готовый ответ

Примеры:

- Mobile BFF: для главной страницы собирает данные из 5 сервисов, возвращает лёгкий JSON

- Web BFF: для той же страницы собирает больше данных из 8 сервисов, включая рекомендации

- Admin BFF: собирает детальную статистику из множества сервисов

Важные особенности:

- В BFF обычно нет своей базы данных

- Это слой агрегации и трансформации

- Каждый BFF развивается вместе со своим клиентом

- Позволяет оптимизировать именно под нужды клиента

Отличие от API Gateway:

- Gateway — инфраструктурные задачи (авторизация, rate limiting)

- BFF — бизнес-логика сборки данных для клиента

Что такое Service Discovery? Как сервисы находят друг друга?

Service Discovery — механизм, который помогает микросервисам находить друг друга в динамической среде.

Проблема:

- У тебя 10 копий user-service

- Они могут запускаться на разных серверах

- IP адреса меняются при перезапуске

- Как order-service найдёт user-service?

Два подхода к Service Discovery:

Client-side (на стороне клиента):

- Клиент сам спрашивает "где все копии user-service?"

- Получает список адресов

- Сам выбирает, к какой копии обратиться

- Плюс: гибкость, минус: сложная логика в клиенте

Server-side (на стороне сервера):

- Клиент обращается к load balancer по имени

- Load balancer знает, где все копии

- Сам выбирает копию и перенаправляет запрос

- Плюс: простота для клиента, минус: extra hop

Как это работает в Kubernetes:

- Каждый Service получает DNS имя

- Pod обращается по имени (user-service)

- Kubernetes знает все поды этого сервиса

- Автоматически направляет на живой под

Простая аналогия:

Как найти нужного человека в большой компании — можно самому искать по всем кабинетам (client-side) или спросить на ресепшн (server-side).