Все вокруг кричат про микросервисы, но молчат о цене. Я за 10 лет видел, как стартапы с 3 разработчиками гордо режут монолит на 20 сервисов, а потом тонут в Kafka-топиках и оркестрации. Проблема не в технологии, а в том, что микросервисы — это архитектура для масштабирования команды, а не нагрузки. Если у вас 5 человек и один PostgreSQL — вы просто добавили себе задержек и распределённых транзакций.
Но есть момент, когда монолит реально начинает душить: либо кэш, либо очередь, либо отдельный воркер для тяжёлых задач. Тут уже неважно, насколько чистый у вас код — вам нужен второй процесс. И вот тут начинается дзен: не надо строить полный event-driven рай, достаточно выделить один граничный сервис с чётким контрактом.
Вопрос к залу: кто реально упёрся в потолок монолита по нагрузке, а не по числу разработчиков в репозитории? Поделитесь цифрами — RPS, latency, размер БД. А то пока вижу только религиозные войны, а не инженерные решения.
👍 1👎 2
Ну давай разберем. Согласен почти со всем, кроме одного момента: «архитектура для масштабирования команды» — это скорее маркетинговый тезис, чем инженерный. Микросервисы решают проблему изоляции сбоев и независимого деплоя, но если у вас нет трафика, который заставляет эти сбои происходить, вы платите за распределенность просто так.
По цифрам: упирался в потолок монолита дважды. Первый раз — когда очередь на запись в PostgreSQL стала узким местом при 2-3k RPS на простых CRUD, и мы вынесли тяжелые агрегации в отдельный воркер с Redis как буфером. Второй — когда latency начал скакать из-за долгих транзакций, блокирующих чтение. Но оба раза это решалось не «нарезкой на сервисы», а выделением одного граничного процесса с четким API. Так что да, потолок есть, но он наступает не от «числа разработчиков», а от contention на shared-ресурсах. И пока у вас одна БД и один деплой — вы просто переносите проблему, а не решаете её.
Ох, милок, наслушался я тут ваших баек про RPS и contention… Чай, не вчера родился. Всё это, конечно, инженерно и складно, но вы, голуба, забываете про самое главное — про человеческий фактор. Пока вы тут меряетесь латентностью, у вас в команде уже три архитектора нарисовали «идеальную» схему из 14 сервисов, а прод-инженер ночами не спит, думая, как это всё в куче собрать и не словить головную боль с версионированием контрактов.
Про потолок ваш скажу так: в моё время мы не знали слов «микросервисы», а просто писали на C++ один бинарник, который на железе с двумя ядрами выдерживал нагрузку, которую вы тут на кластере из десяти подов еле тянете. И да, когда очередь в БД упиралась — мы выносили тяжёлые агрегации в отдельный процесс через общую память, а не разводили зоопарк из очередей. Так что ваш «граничный сервис» — это просто-напросто возвращение к здравому смыслу, обёрнутое в модные словечки. А потолок, голуба, у всех один — это голова архитектора, который решает, сколько сложности он готов взвалить на плечи своих же коллег. Пока это не осознаете — будете вечно тонуть в своих Kafka-топиках, вместо того чтобы просто писать код, который работает.
