Что в первую очередь покупает переход от монолита к микросервисам?
- Зачем переходить на микросервисы?
- Какую проблему решают микросервисы?
Микросервисы решают организационную задачу — независимую разработку и выкатку многими командами, а не задачу производительности.
- Покупаем: независимый деплой, масштабирование по частям, изоляцию отказов, автономию команд
- Платим: сеть вместо вызова функции, нет общих транзакций, трассировка, эксплуатация
- Закон Конвея: архитектура повторяет структуру общения команд
А ещё Пока команда одна и маленькая — модульный монолит обычно выгоднее
Подробно
Технически распределённая система медленнее и менее надёжна, чем монолит той же функциональности: вызов внутри процесса стоит наносекунды и не падает, сетевой — миллисекунды и иногда падает. Значит, переходят ради другого.
Что покупаем:
- независимая выкатка — команда выпускает свой сервис, не согласуя релиз с остальными;
- независимое масштабирование — тяжёлый сервис получает больше экземпляров, остальные — нет;
- изоляция отказов — падение рекомендаций не роняет оформление заказа (если правильно построены таймауты и деградация);
- автономия команд — свой стек, свой темп, своя зона ответственности;
- закон Конвея работает в обе стороны: границы сервисов, совпадающие с границами команд, уменьшают координацию.
Чем платим: сетевые сбои и задержки, отсутствие распределённых транзакций (саги, outbox, согласованность в конечном счёте), версионирование контрактов, трассировка и централизованные логи, отдельная эксплуатация каждого сервиса, сложное локальное окружение и тестирование.
Вывод: переход оправдан, когда организация выросла и общий монолит мешает командам выпускать независимо. Без этой проблемы микросервисы — налог без выгоды.
Что хотят услышать
- Главная выгода — организационная: независимая разработка и выкатка.
- Конкретная цена распределённости.
- Закон Конвея.
- Когда переход не нужен.
Частые ошибки
- «Микросервисы — чтобы было быстрее».
- Не называть цену перехода.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Прирост производительности за счёт распределения нагрузки между сервисами
- ✗Упрощение работы с данными и транзакциями между частями системы
- ✗Снижение требований к мониторингу, логированию и эксплуатации
- ✓Независимость деплоя, масштабирования и владения командами
Что спросят дальше
- Как здесь работает закон Конвея?
- Когда микросервисы точно не нужны?
Разбор темы
- Монолит, микросервисы и границы сервисов
Когда микросервисы оправданы, а когда вредны; bounded context и DDD как способ резать систему; распределённый монолит и его признаки; база на сервис и организационная цена.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.