Тут рассказал про основные паттерны МСА, а сейчас – про вопросы по этой теме, которые мне задавали на собесе
Что такое BFF?
Тут важно понимать, что такое API Gateway и зачем он в системе. BFF – Backend for Frontend (Бэкенды для Фронтендов) – подход, при котором используется несколько API Gateway под разные платформы (мобильные девайсы, десктоп, веб) или роли (клиент, курьер, ресторан). BFF используется, например, в Uber.
Это снижает нагрузку, разграничивает API и позволяет отдать разные Gateway на поддержку разных команд. Но если в системе роли плюс-минус похожи, а функциональность платформ одинаковая, в шаблоне нет смысла
Задача – разделить монолит на микросервисы. Что будешь делать?
В ответе говорим про два шаблона из группы «Паттерны декомпозиции» – Strangler или Anti-Corruption Layer. Аналитику сначала нужно изучить функциональность, а затем спроектировать будущие сервисы на основе этих паттернов
О чем паттерн CQRS?
О нем я не писал, но на собеседовании меня однажды спросили. CQRS (Command Query Responsibility Segregation) – паттерн, разделяющий операции чтения (запросы, queries) и записи (commands). При этом под чтение и запись создаются разные модели данных.
Шаблон применяется, когда в системе есть дисбаланс по операциям (например, чтение чаще чем запись), и он помогает масштабировать систему. Не стоит применять, если у вас простое CRUD-приложение или нет требований к масштабируемости
Как решается проблема согласованности данных в микросервисах?
Когда в одной операции задействовано несколько микросервисов, и один может не обновить/записать данные – возникает несогласованность
Тут на помощь придет паттерн Saga – бизнес-транзакция разбивается на цепочку локальных транзакций. Если хотя бы одна не выполнится – запускаются компенсирующие транзакции (откат). Подробнее разберем в следующем посте
Как определяются границы микросервисов? / С чего начать проектирование?
Обращаемся к группе «Паттерны проектирования». Каждый сервис должен отвечать за отдельную бизнес-область (домен, сущность): базу данных, бизнес-логику и API мы проектируем в пределах этой области.
Тут может возникнуть проблема с «Божественными классами», когда одна сущность включает несколько других – в этом случае ее нужно декомпозировать
Как организовать мониторинг и логирование микросервисов?
Тут поможет шаблон «Агрегация логов» – то есть централизованный сбор логов со всех сервисов для возможности мониторинга
Конечно, каждый сервис может локально собирать логи, но так их будет сложнее анализировать, а рано или поздно их объем повлияет на производительность сервиса
Как повысить отказоустойчивость микросервиса?
Еще один неочевидный паттерн для СА – «Предохранитель» (Circuit Breaker). Шаблон основан на отслеживании количества неудачных запросов к сервису
Если мы отправили 50 запросов сервису, а он не ответил, то Circuit Breaker временно блокирует вызовы к нему, переключаясь на fallback-логику (например, кэш или заглушу). За это время сервис восстановится и продолжит свою работу
➡ Итог
Перед собеседованием на проект, где есть МСА, нужно повторить:
🔹 API Gateway vs BFF
🔹 Saga
🔹 Strangler vs Anti-Corruption Layer
🔹 Паттерны проектирования
🔹 (вряд ли попадется, но вдруг) Circuit Breaker, CQRS
—————
⬇ Сохраняйте эти вопросы – пригодятся на собеседовании. В следующем посте расскажу простыми словами про самый важный паттерн микросервисной архитектуры
#полезное_системный_анализ