Comments 5
Brainrot
Можете развить мысль, что вы имели ввиду?
Разбиение по слоям (анти-паттерн)
«Медленная разработка: Любое изменение требует полного регресса (везде ли всё поменяли) и согласования со всеми.»
«Масштабирование невозможно: При пиковой нагрузке на распродажах «падает» весь монолит, включая складской учёт т.к. передаётся слишком большой объём данных из-за разросшегося агрегата.»
«Когнитивная перегрузка: Новый разработчик должен понять все 50+ полей и методов, даже если работает только над каталогом.»
Абсолютно не согласен с этими утверждениями.
Команда из 10 человек может прекрасно развивать сложный монолит, тогда как для распределённой системы с той же логикой потребуются сотни людей. Разработка в монолите быстрее: только на согласование контрактов между сервисами уходят недели, плюс отладка взаимодействий.
Вместо одного лога и стектрейса — вам нужна распределённая трассировка по десяткам сервисов. Поиск причины сбоя превращается в детективное расследование.
Любой вызов теперь уязвим к таймаутам, сетевому лавинообразованию, проблемам DNS. Вы тратите больше времени на написание устойчивого к сбоям клиента, чем на бизнес-логику.
Независимое развёртывание — миф, если изменение API одного сервиса требует синхронного обновления трёх других. Версионирование API, устаревшие клиенты, graceful degradation — это отдельная инженерная дисциплина.
Масштабирование более чем возможно. Появились распределённые SQL-базы данных нового поколения, такие как YugabyteDB, CockroachDB, Google Spanner. Они предлагают строгую согласованность, горизонтальное масштабирование на уровне данных и распределённые ACID-транзакции — всё то, ради чего мы дробили монолит и отказывались от транзакционности.
В мире микросервисов разработчику необходимо понимать не меньше, но только он не может быстро посмотреть код, который происходит где-то там за границами сервиса
Микросервисы это не способ борьбы со сложностью, это про другое: разный технологический стек, независимые команды с разными циклами разработки и деплоя (при условии что контракты не меняются), жесткие нормативные или юридические требования, четко выделенные ресурсоёмкие специфичные задачи.
"Команда из 10 человек может прекрасно развивать сложный монолит, тогда как для распределённой системы с той же логикой потребуются сотни людей. Разработка в монолите быстрее: только на согласование контрактов между сервисами уходят недели, плюс отладка взаимодействий. " Здесь есть скрытое условие, на котором держится ваш аргумент: “Монолит + высокая инженерная дисциплина + стабильная команда + понятная доменная модель”. В идеальном мире я бы и сам никогда не выбрал сложные микросерисы.
"Вместо одного лога и стектрейса — вам нужна распределённая трассировка по десяткам сервисов. Поиск причины сбоя превращается в детективное расследование." Отчасти согласен, лучше, когда всё в одном месте и нет общей ответственности, но распределённая трассировка это скорее плата за порядок и я бы отнёс это к минусам МКС, не понятно к чему это вы написали. К тому же обычно все логи всех сервисов собраны в одну кибану и нет проблем взять traceId и пройтись по всем системам также как в монолите по модулям. Да настраивать Kibana достаточно ресурсозатратно, но это необходимо.
"Любой вызов теперь уязвим к таймаутам, сетевому лавинообразованию, проблемам DNS. Вы тратите больше времени на написание устойчивого к сбоям клиента, чем на бизнес-логику." - ну, нет Circuit Breaker размыкает цепочку, да, это плата за микросервисы, опять же не вижу, что вы опровергаете, цитируя меня, я не писал, что с сетью лучше работают микросервисы.
"Независимое развёртывание — миф, если изменение API одного сервиса требует синхронного обновления трёх других. Версионирование API, устаревшие клиенты, graceful degradation — это отдельная инженерная дисциплина." - Не понял посыла, я могу в Kubernetes из 3 под 1 оставить со старой весрией сервиса, 2 с новой. Да и вы сами говорите, что это дисциплина, следовательно её используют и применяют и зависит она от зрелости команды, а не от выбора монолит/мкс.
"Масштабирование более чем возможно. Появились распределённые SQL-базы данных нового поколения, такие как YugabyteDB, CockroachDB, Google Spanner. Они предлагают строгую согласованность, горизонтальное масштабирование на уровне данных и распределённые ACID-транзакции — всё то, ради чего мы дробили монолит и отказывались от транзакционности." - Это слишком широкое обобщение. Мы не дробили монолит “ради масштабирования данных” в большинстве кейсов.
Чаще причины: независимые релизы, скорость разработки, границы ответственности, разные нагрузки, отказоустойчивость отдельных модулей, организационные причины. От транзакционности в рамках сервиса тоже никто не отказывался, а между сервисами есть SAGA для консистентности, я бы сказал эти аргументы не к месту или не до конца раскрыты. Если есть кейсы, когда можно заменить SAGA на одну из этих технологий без минусов sharedDB или с минимальным количеством, прошу написать.
"В мире микросервисов разработчику необходимо понимать не меньше, но только он не может быстро посмотреть код, который происходит где-то там за границами сервиса " - Разграниченные права в gitlab, где хранятся все сервисы. Во всяком случае у нас. Может.
Связь паттернов микросервисной архитектуры