Comments 21
Еще надо не забывать, что стоимость использования микросервисов сильно выше, чем стоимость использования монолита. Это и про ресурсы (больше дисков, ЦПУ, ОЗУ, сети - которая тоже бывает дорогой, что многим неочевидно), и про команду (в монолите даже выделенный админ не всегда нужен, микросервисные команды целиком и полностью зависят от SRE/DevOps/Platform инженеров).
Сейчас архитектурные решения принимаются через механизм ADR, за который обычно отвечает системный архитектор, работающий со всеми автономными микросервисными командами.
Хорошая сжатая статья. Показалось, автор не разбирается в современном observability, про OpenTelemetry ни слова.
А зачем вы собрались переходить на микросервисы? Очень редко кто может внятно ответить.
Или это очередная теория без реального проекта?
Статья нейросетевая, тут не о чем говорить.
Потому что наш бизнес и платформа достигла такого масштаба, что продолжать на монолите будет слишком сложно и неэффективно.
То есть не можете ответить
то есть я ответил
Представляю как вы выпятили губу и сдвинули брови когда писали ответ. Для солидности и гордости за ваш бизнес и платформу.
Это не обоснование.
Это ответ (и то, что ты его не понял - это не проблема автора :-D)
Например, команда ДоДо приняла решение переходить на микросервисы, когда их IT система не могла регистрировать больше N заказов в единицу времени - сервер не справлялся с нагрузкой.
Вертикальное масштабирование сервера могло временно решить проблему, но, с учетом роста их бизнеса, это был путь в никуда...
Статья хорошая, спасибо!
Микросервисы как средство масштабирования нагрузки? Нет. Это не верно.
Такое может сработать только для CPU bounded задач, куда Додо никак не попадает.
Горизонтальное масштабирование нужно для БД через шардирование. Но не для app server.
Но они, конечно, прострелили себе ногу модным револьвером.
Точнее так: я не против отделить БД каждого домена в отдельности. Это повысит быстродействие на междоменном взаимодействии за счёт отказа от локов. Доменов у бизнеса не так и много бывает.
Но когда домены бьют дальше, десятки микросервисов на домен, это уже не приводит к росту скорости.
DDD этого не рекомендует.
Эванс и Вернон: bounded context ≠ микросервис. Контекст может быть монолитом, может быть несколькими сервисами, может быть частью большого сервиса.
Откуда путаница:
Микросервисная волна 2014-2016 использовала термины DDD для обоснования "Каждый агрегат = микросервис" - это искажение, не DDD.
Консалтеры продавали микросервисы под соусом DDD
Что DDD действительно говорит:
Разделяй по границам контекстов (бизнес-границы)
Внутри контекста - высокая связность
Между контекстами - слабая связанность
Вернон в "Implementing DDD" прямо предостерегает от излишнего дробления. Рекомендует начинать с модульного монолита.
Всё равно никто уже не прочитает, но оставлю себе на память.
Транзакции должны быть дешёвыми. Дорогие разбивай.
Правило большого пальца:
1. В транзакции — только изменения в БД.
- Никаких HTTP-вызовов, email, логирования в файл.
2. Транзакция должна быть короче 100 мс.
- Если дольше — разбивай.
3. Одна транзакция — один агрегат.
- Меняешь два? Значит, один из них — не агрегат, или нужно событие.
4. Если есть сомнения — разбивай.
- Дешёвые транзакции + события = безопасность и масштабируемость
а причем здесь вертикальное масштабирование? монолитные приложения можно также легко горизонтально масштабировать.
Реально хорошая работа.
Есть ещё пара вещей, о которых стоило бы упомянуть на мой взгляд.
Совмещение бэклогов для end2end задач. Если надробить монолит без учёта регулярной совместной разработки функций, можно сильно проиграть по time-to-market
Бухгалтерский и управленческий учёт таки требуют ACID. Без него слишком больно
Микросервисы обещают решение. Гибкость. Масштабируемость. Независимые команды. Быстрые релизы. Звучит идеально.
Разумеется идеально, если не упоминать что на этом все плюсы микросервисов заканчиваются а все остальное превращается в сплошные минусы.
Микросервисы - это по сути жертва, на которую идут потому как по другому в сложившихся обстоятельствах никак, а не какое-то идеальное решение.
Да, есть полно более простых и эффективных решений. Микросервисы это последнее средство, которое нужно рассматривать если остальные уже себя исчерпали.
И не устаю повторять любителям микросервисов: не льстите себе, вы не Гугл.
нет! Микросервисы это просто название, это почти как счастье. Знаете как там было в давние времена: Что такое счастье — это каждый понимал по-своему. Но все вместе люди знали и понимали, что надо честно жить, много трудиться и крепко любить и беречь эту огромную счастливую землю, которая зовется ...
как говорится подставьте нужные вам слова.
Вроде и по делу, но ничего нового...
Для себя определил главный плюс микросервисов - изоляция говнокода. Меньше кода - легче рефачить.
С монолита на микросервисы: проблемы, решения, практические рекомендации