Типичные проблемы — распределенный монолит, чрезмерная дробность сервисов, нарушение владения данными, незащищенные цепочки вызовов и слабая наблюдаемость. Общий физический сервер СУБД сам по себе не антипаттерн: важны границы данных и независимость изменений. Синхронное и асинхронное взаимодействие выбирают по требованиям, а не по универсальному запрету.
Какие существуют антипаттерны микросервисной архитектуры?
Признаки избыточной связанности микросервисов: совместные релизы, размытое владение данными, хрупкие цепочки вызовов и недостаточная готовность к эксплуатации.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Антипаттерн — не любое отклонение от популярной схемы, а решение, которое создает устойчивые проблемы в данном контексте. В микросервисах особенно опасно получить расходы распределенной системы без нужной независимости компонентов.
Основные примеры:
- Распределенный монолит: изменение одного сервиса требует согласованных изменений и совместного выпуска многих других.
- Чрезмерная дробность: простое бизнес-действие проходит через множество сервисов, а сетевые вызовы и координация дороже полученной самостоятельности.
- Размытое владение данными: сервисы напрямую меняют чужие таблицы или зависят от внутренней схемы соседей, обходя согласованные контракты.
- Хрупкие синхронные цепочки: нет ограничений времени, контроля повторов и изоляции отказов; сбой одного участника распространяется дальше.
- Недостаточная наблюдаемость: нельзя связать запросы между сервисами, оценить задержки и определить владельца инцидента.
- Невоспроизводимые релизы: ручные изменения, отсутствие проверок совместимости, понятного отката и автоматизированной доставки.
Общая физическая СУБД не обязательно нарушает архитектуру. Сервисы могут разделять инфраструктуру, сохраняя четкие права, владельцев и границы схем. Риск появляется там, где независимость изменений подменяется скрытой связанностью через данные.
Синхронное взаимодействие также не является ошибкой само по себе. Асинхронность полезна для определенных сценариев, но добавляет задержки согласования, повторы сообщений и сложность диагностики. Ее нужно выбирать исходя из требований, а не применять повсеместно.
При разборе архитектуры спросите: какую самостоятельную бизнес-возможность представляет сервис, кто владеет его данными и можно ли безопасно изменить или выпустить его отдельно? Если ответы постоянно требуют координации всех участников, стоит пересмотреть границы и обоснованность разделения.