Я PHP-разработчик с восьмилетним коммерческим опытом. Долгое время я не видел смысла в микросервисах — пока не перешёл на Python и не столкнулся с его архитектурными особенностями.
С чего всё началось?
В коммерческой разработке я уже восемь лет. Для меня язык программирования — это инструмент и не более. И переход с PHP на Python не вызвал трудностей. Мои знания ООП и алгоритмов обеспечили необходимую базу для коммерческой разработки.
Однако в первые месяцы я не понимал внутренних механизмов Python. Я писал код, руководствуясь общими принципами программирования.
Внезапная проблема
Однажды я заметил, что мой сервис зависает при загрузке файла в S3. Оказалось, что причина в синхронной библиотеке Python. Это удивило меня как PHP-разработчика. Ведь в PHP каждый запрос пользователя запускает отдельный экземпляр приложения. Код выполняется последовательно, и приложение возвращает ответ. Это делает PHP-приложения медленными, но надёжными: один запрос равен одному потоку.
В Python всё иначе. Программа разделяет один поток на всех пользователей. Если кто-то тормозит систему, то и у остальных всё останавливается. Таким образом, из-за одного сложного запроса сотни других пользователей могут наблюдать бесконечную загрузку.
И многие библиотеки Python, особенно HTTP, изначально синхронные. Это создаёт проблему при работе с внешними API и загрузками файлов в облако, что может повлиять на всё приложение. Именно это произошло и у меня.
Время для серьёзного разговора
Меня заинтересовала проблема, и я обсудил её с чатом GPT. Он объяснил всё, что я описал выше. Затем я поговорил с нашим Python-разработчиком. Он тоже подтвердил, что у Python есть своя куча недостатков.
И вот тогда я понял, почему микросервисы стали так популярны одновременно с Python.
В приложении, работающем в одном потоке, всегда есть риск "зависания" из-за любой проблемы. Такое приложение лучше использовать как мостик между реальным бэкендом и API.
Здесь на сцену выходят gRPC и микросервисы. Они позволяют разделить код и создать отдельные потоки для конкретных задач. Таким образом, если зависает сервис отправки данных в облако, клиенты этого не замечают. Приложение продолжает работать, ведь зависает только один из множества микросервисов.
Так в чём же проблема?
Казалось бы, всё хорошо: проблема решена, мы сократили зависимость от одного потока, уменьшили риски зависания.
Но есть один нюанс. Микросервисы — это своего рода костыль в мире однопоточных архитектур. Их часто считают крутыми из-за масштабируемости и командной гибкости. Однако это далеко не всегда правда.
Популярность микросервисов заставила монолитные решения отойти на задний план. А ведь монолиты требуют дешевых серверов, они проще в развертывании и разработке, часто они более практичны.
Сегодня молодые компании вынуждены тратить больше средств и времени на разработку и поддержку микросервисов. Всё ради модных технологий. И довольные программисты, без опыта в создании архитектуры приложений, начинают писать свои сервисы. Они множат их, пишут в функциональном стиле. А потом рассказывают на свои конференция с ванильным рафом в руке какие они молодцы. Мрак, не?
Микросервисы — это бич нашего времени
Их нужно использовать, когда у вас действительно большая команда, работающая над одним проектом, или если вы пишете на Python и вам нужны ресурсы. Но даже тогда, возможно, стоит научиться пользоваться Git, прежде чем идти путём микросервисов.
Когда же действительно оправдано использовать микросервисы? Когда вынесение кода в отдельный сервис упрощает жизнь всей команде. Когда затраты на разработку меньше, чем создание мини-проекта с нуля.
Микросервисы — это важно. Но внедряйте их разумно. Используйте их там, где они уместны. Истинная мудрость в том, чтобы выбирать инструменты с умом. Разработчику важно знать про ООП, паттерны и в целом понимать, что он делает и зачем. В итоге именно это выделяет вас как продуманного и способного разработчика.
UPD 1
Перед вами не решение проблемы и не подробная статья с примерами. Перед вами статья категории "Мнение". В этой статье я выразил свою боль, которая началась с небольшого бага в S3 и закончилась пониманием, откуда взялся тренд на микросервисы в современном мире.
UPD 2
Комментарии люблю и уважаю, и в них есть дополнения к статье. К счастью, читатели показали мне, что структура статьи получилась сложной и акцент сильно теряется. Но статья уже написана, и, надеюсь, найдутся те, кто понимает мою боль, или те, для кого написанное станет пищей для ума и поводом обдумать свой подход к разработке в положительную сторону.
UPD 3
В статье очень много упрощений. Учитывайте это. И да, я знаю, что микросервисы появились давно и не из-за всяких питонов. Знаю, что при желании все можно запустить в многопотоке. Знаю, что крупные компании могут позволить себе большой и серьезный путь разработки со всеми хорошими практикам. И конечно же, знаю, что питон лишь один из языков бекенда. Но все ещё это один из наиболее популярных языков.
Статья не об исследовании конкретные технологий или деталях работы и истории микросервисов. Она о конкретной боли и пути к ее осознанию с кучей упрощений
Комментарии (116)
Boyl
09.10.2025 20:33А зачем упираться в питона или в пхп, вы правильно сказали инструмент! Так есть инструменты наверняка которые лучше подходят под ваши задачи, не зря в мире овер-дофига языков программирования и пока не нашли того на котором пишут все и вся!
dmtrbskkv Автор
09.10.2025 20:33Зачем мне рассказывать то чего я не знаю? Я рассказываю о тех инструментах с которыми я активно работаю уже определенное время. Плюс мои инструменты:
- Pyhton, который база современного интернета и рынка труда веб разработчиков
- PHP база для старого интернета
Кончено, есть ещё net проекты на шарпе и реальные микросервисы на GO и подобном. Но все это не самая частая практика
nikulin_krd
09.10.2025 20:33Но вы же буквально пишете о том чего не знаете)))
- Pyhton, который база современного интернета и рынка труда веб разработчиков
Повеселило особенно))) Прям база))
dmtrbskkv Автор
09.10.2025 20:33Ну видимо на рынок труда давно не заходили. Сейчас основной поток веб разработчиков - питонисты. Может и хочется вам верить в что-то иное. Но я говорю о том, что действительно происходит. Если будет возможность, крайне советую поискать разработчиков на веб проект. Очень удивитесь тому кого на рынке больше всего
MechanicZelenyy
09.10.2025 20:33Больше всего питонистов, потому что у гошников, джаваскрипетров и джавистов уже есть работа и им не надо её искать?
А если серьезно питон кончено входит в топ-10 языков для бэкенда, но он там один из, а не абсолютный лидер.
dx-77
09.10.2025 20:33Не обязательно городить микросервисы для того, чтобы загрузить файл на S3. Достаточно монолита. Достаточно даже синхронного монолита на Питоне.
dmtrbskkv Автор
09.10.2025 20:33Именно об этом я и пытаюсь сказать. Местами хватит монолита на чем угодно. Надо трезво оценивать необходимость микросервисов и не делать их просто потому что так модно
dx-77
09.10.2025 20:33Я бы даже сказал, что монолита почти всегда хватит) А проблема с S3, описанная в статье, вообще не проблема, так как она никак не зависит от бэкенда и его реализации, даже если он почему-то однопоточный и однопроцессный (хотя так никто не делает) И тормозить ничего не будет, если хоть немного почитать доку S3
dmtrbskkv Автор
09.10.2025 20:33Про S3 - это тригер моего расследования так сказать. Проблему то я решил быстро. Просто именно она дала мне пищу для размышления
Но если чисто про S3, там была проблема с boto3 клиентом. Aioboto3 решил все
dmtrbskkv Автор
09.10.2025 20:33Думаю самая главная проблема в структуре текста. Я давно не писал статьи и видимо не тот путь выбор в логике повествования. Из-за этого многие начинают акцентироваться не на том. Точнее я делаю акцент не на том изначально
nikulin_krd
09.10.2025 20:33Главная проблема в том, что взялись писать о том, в чем не разбираетесь, тем более пытаясь аппелировать к опыту, что является моветоном в общении
Andchir
09.10.2025 20:33В Python всё иначе. Программа разделяет один поток на всех пользователей. Если кто-то тормозит систему, то и у остальных всё останавливается. Таким образом, из-за одного сложного запроса сотни других пользователей могут наблюдать бесконечную загрузку.
Как Вы это определили? Можно узнать как Вы деплоите Ваши Python приложения на продакшн?
dmtrbskkv Автор
09.10.2025 20:33Потому что питон - это однопоточная штука. Если только не запускать его через костыли по типу gunicorn. И вся параллельность в нем фейковая, работающая по типу генераторов(очень-очень грубо говоря)
MechanicZelenyy
09.10.2025 20:33Основная ваша проблема что вы совершенно не понимаете смысл терминов, но при этом вы активно пытаетесь их использовать.
Python не однопоточный, он вполне себе многопоточный язык, но в котором есть GIL, а это уже само по себе разные вещи. Не говоря уже что там хватает асинхроных библиотек.
Во-вторых вы постоянно используете термина микросервисы, хотя их у вас нет. Микросервисы это определенная архитектура, а не запуск нескольких параллельных обработчиков запросов. У вас что если поднять монолит на двух серверах и поставить балансировщик нагрузки, то монолит превратиться в микросервис?
В-третьих, там есть параллельность через мультипроцессинг, да это не так удобно и хорошо как параллелизм в общем пространстве памяти, но что есть. Кстати сама по себе многопоточность без gil не гарантирует параллельности, это разные понятия.dmtrbskkv Автор
09.10.2025 20:33Я понимаю, что у одного термина может быть несколько смыслов, исходя из контекста
А проблема тут в статье одна - люди думают увидеть детальное исследование с примерами. Но тут огромное количество упрощений и обобщений. И судя по статистике, часть пользователей поняла это
nikulin_krd
09.10.2025 20:33Проблема в статье одна - ее написал человек, который не разбирается в вопросе
thethee
09.10.2025 20:33Кстати python 3.14 можно собрать без GIL и получить полный многопоток. Сам не тестил ещё, в тырнетах читал, но вроде как именно то что все давно просили - настоящий параллелизм на множественных ядрах в общем пространстве памяти. Пока не верю, в интернете могут врать, но хочется верить, хотя многие фреймворки ещё не будут готовы к такому, как минимум потому что это специально собирать питон таким надо, и нет релизнутого бинаря
MechanicZelenyy
09.10.2025 20:33Да, можно коллеги уже тестили.
В целом пока этом можно использовать если вы готовы писать проект с нуля, с либами которые заведомо не опираются на существование GIL.
Запускать на уже существующем проекте это конечно гарантированный способ поймать гонку состояний.
Andchir
09.10.2025 20:33Потому что питон - это однопоточная штука.
Не правда. Кстати, Вам нужно ознакомиться с понятием "конкурентность". Это не то же самое, что "многопоточность".
через костыли по типу gunicorn
Это всё равно что для PHP сказать - "через костыли по типу PHP-FPM". Gunicorn — это не костыль, а стандартный, профессиональный WSGI-сервер для production.
test4354545
09.10.2025 20:33пониманием, откуда взялся тренд на микросервисы в современном мире
нет, вы неправильно поняли причину возникновения тренда на микросервисы
dmtrbskkv Автор
09.10.2025 20:33А если мы говорим о повсеместном использовании? Исключая большие компании - они в целом во многом исключения из-за большого числа ресурсов и возможностей
test4354545
09.10.2025 20:33Вы серьезно думаете что небольшой комании легче создать отдельный микросервис чем запустить нужную блокирующую задачу в отдельном процессе/потоке?
dmtrbskkv Автор
09.10.2025 20:33Небольшой компании проще сделать монолит и не тратить время на микросервисы
test4354545
09.10.2025 20:33Вот именно! Поэтому ваш тейк про причины популярности микросервисов - ошибочен
nikulin_krd
09.10.2025 20:33С чего вдруг? Кто вам вбил эту дикую чушь про размеры компаний и микросервисы с монолитами?
panzerfaust
09.10.2025 20:33Да, да. На Пике им. Даннинга-Крюгера вообще всё "зло". Только в Долину лучше не спускаться. Особенно с таким шерпой, как Чятик.
WLMike
09.10.2025 20:33Я так и не понял, причем тут микросервисы. Вы не умеете писать на питоне, но приплели почему-то микросервисы
PS: Это прям эпично: Я PHP-разработчик с восьмилетним коммерческим опытом. А потом мы читаем статьи в которых авторы удивляются почему PHP во многих компаниях ред флаг и, что рынок труда полностью испорчен, и я не нужен со своим опытом 8 лет
akod67
09.10.2025 20:33И вот тогда я понял, почему микросервисы стали так популярны одновременно с Python.
Мда. Вселенский вывод. Микросервисы появились на фоне проблемы, которая к тому времени много где обострилась - сложность масштабирования монолитов + появление удобной инфраструктуры для масштабирования - облака с лямбдами и подобным, виртуалки, ансибл, докер и прочий CI. Питон серьёзно вообще мало кто воспринимал вплоть до взлёта MLов.
Nikudator
09.10.2025 20:33Ну вы б хотя бы спросили у ИИ, почему появились микросервисы. Питон тут явно не при чём...
dmtrbskkv Автор
09.10.2025 20:33Думаю это любой дурак знает. В статье я рассказал об актуальных тенденциях. Но большинство решило, что тут исследование, а не просто мнение с кучей упрощений. Про микросервисы в том числе
Думаю не зря на Хабре есть отдельный тип материала как мнение
tertiumnon
09.10.2025 20:33ИМХО, использовать питон для разработки - моветон, так же как например чистый JS (без TS).
iamkisly
09.10.2025 20:33В коммерческой разработке я уже восемь лет. Для меня язык программирования — это инструмент и не более.
Так не бывает. Даже у тех, кто в профессии исключительно за "длинным рублем", есть любимчики, синдром утенка и список просто субъективно некомфортных языков. Поэтому когда я читаю подобные фразы, я вижу просто желание с порога показать себя дофига профессионалом, и придать значимости.
nikulin_krd
09.10.2025 20:33Апелляция к опыту в 99% случаев является ред флагом, который показывает, что опыта как такового и нет. Что в принципе мы и видим в статье. Есть прекрасная фраза для таких случаев «Не стыдно быть бедным, стыдно быть дешевым»
ptr128
09.10.2025 20:33Бывает, несмотря на то, что есть субъективное восприятие. Недавно посчитал, что за этот год мне пришлось использовать больше десятка языков. И несмотря на то, что не все они мне по душе, ничего от меня не отвалилось. Не будете же Вы писать новый Sink для Confluent не на Java, расширение для PostgreSQL не на C, CLR функцию для MS SQL не на C# и т.п.?
eulampius
09.10.2025 20:33"...плашек на 5/8 нет... а трамвай пустить собираются..." (с) ИИ и ЕП. Во время чтения статьи отчего то часто вспоминалось )
Dhwtj
09.10.2025 20:33PHP-модель — это как бесконечный пул воркеров
gunicorn --workers 1000, где каждый воркер умирает после одного запроса. Надежно, но крайне неэффективно.
Микросервисы тут не при чём. Просто не надо переносить опыт пхп напрямую. Откуда вы взяли синхронные библиотеки, кстати?
olku
09.10.2025 20:33Да ладно вам, автор же просто стебется. Каждый пыхер знает что PHP однопоточнее некуда, асинхронный curl и fibers не в счёт, и вебе живёт только благодаря FPM. Зачем же так жестко карать за незнание, пусть ещё пишет, осваивает новое вне PHP.
SerafimArts
09.10.2025 20:33PHP однопоточнее некуда, асинхронный curl и fibers не в счёт
Ну даже учитывая то, что коммент - откровенная ирония и сарказм, и надо всё делить на 10, но всё равно потоки и асинхронность - это абсолютно разные вещи, которые можно соединить в одну концепцию только используя термин "green thread" (да и то, это абстракция над потоками, так что ничего не гарантируется).
Те же файберы в пыхе и есть грин треды, или стекфулл корутинки, которые не красят функции, но могут работать на одном треде (что скорее всего, в 99.9% случаях) без должной реализации.
ivankprod
09.10.2025 20:33А что плохого сразу (конечно имея для этого опыт) сделать на микросервисах, чтобы потом не тратить отдельно ресурсы на миграцию?
dmtrbskkv Автор
09.10.2025 20:33Там кто-то выше писал на тему того, что изначальные цели и виденье проекта может сильно отличаться от итогового продукта. Но вообще, да, можно и иногда очень нужно писать микросервисы
sidewinder1
09.10.2025 20:33Интересно ваше мнение про Service Oriented Architecture
Dhwtj
09.10.2025 20:33Микросервисы на минималках. Можно с shared db, можно зависимости через типизированные XML based soap. Всё это приводит к проблемам при большом количестве сервисов
AlexeySu
09.10.2025 20:33Не могу удержаться, чтобы не перефразировать автора)
Для меня топор - это всего лишь инструмент. Поэтому переход на молоток не вызвал у меня трудностей. Моя сила удара и поставленная рука сделала переход простым. Но потом я столкнулся с проблемой: оказалось, молоток плохо колет дрова!
ptr128
09.10.2025 20:33Даже не рассматривая обоснованность выбора Python для микросервисов, игнорируя Go, Java, C# или даже Rust или C/C++, проблема GIL, в принципе, решаема. Нерешаема проблема динамической типизации. Но это отдельный разговор.
dmtrbskkv Автор
09.10.2025 20:33Факт, я даже не знаю что это за языки. Пишу чисто языке программирования HTML, а в свободное время увлекаюсь епта скриптом для разметки
ronden
09.10.2025 20:33Микросервисы пошли от Гугла, с кубернатесом, го и gRPC. А питон с ними никак не связан. Он существовал задолго до этих технологий.
dmtrbskkv Автор
09.10.2025 20:33Да ну?
UPD 3
В статье очень много упрощений. Учитывайте это. И да, я знаю, что микросервисы появились давно и не из-за всяких питонов. Знаю, что при желании все можно запустить в многопотоке. Знаю, что крупные компании могут позволить себе большой и серьезный путь разработки со всеми хорошими практикам. И конечно же, знаю, что питон лишь один из языков бекенда. Но все ещё это один из наиболее популярных языков.
Krokochik
09.10.2025 20:33Вы распределили нагрузку между копиями одного и того же инстанса и объявили это микросервисной архитектурой...
На мыльно-точильно-дрочильном заводе работает маленький Пьер.
Намылит, наточит, надрочит, хохочет и думает: "Я инженер!"
dmtrbskkv Автор
09.10.2025 20:33Я нет, а вы? Кто-то в комментариях как и вы сделали балансировщик и назвал это микросервисом, странные вы
reim
09.10.2025 20:33Честно говоря, ничего не понял. Мысли статьи:
Не пишите микросервисы, потому что блокирующий ввод-вывод вас подвесит. (К слову, блокирующий ввод-вывод хорошо сочетается с потоками, а асинхронный живёт в одном, использовать блокирующий не по делу — это не знать азов.) Но скажите, как это вообще связано с микросервисами? Я не вижу никакой связи.
Научитесь пользоваться git, прежде чем писать микросервисы. Ну, git — штука полезная, конечно, стандарт сейчас. Но как он связан с архитектурами???
Микросервисы надо применять по назначению. Ну, всё на свете надо применять по назначению. Касторка помогает от запора, но не лечит зубную боль. С архитектурами так же. Где здесь ценное сообщение?
Чтобы делать микросервисы, нужна большая команда. Тезис загадочен. При чём тут размер команды?
В общем, озадачен прочитанным. Прямо хочется спросить, что именно автор понимает под словом "микросервис"?
Монолиты часто сложно развивать по частям и иногда масштабировать, но — опять же иногда — они намного удобнее и проще поддерживаются, чем система микросервисов, если приложение не очень велико. Микросервисы могут превратиться в ад, если у вас возникло множество плохо прослеживаемых зависимостей, и просадить производительность, если не учесть того, что взаимодействие с ними требует времени.
В общем, вещи, которые действительно хорошо отделяются, можно и нужно делать микросервисами (в системе, которая не совсем маленькая, конечно). Но не всё. Далеко не всё.
dmtrbskkv Автор
09.10.2025 20:33Никак, я не совсем об этом. Блокирующий ввод-вывод — это как мой личный триггер изучения вопроса
Он является более базовым знанием, которое позволяет управлять проектом если в команде несколько человек без необходимости резать на микросервисы и усложнять архитектуру
Оно тут и не должно быть, это статья типа "Мнение", а не исследование
Причинно-следственная связь у меня наборот. Если есть большая команда, то может понадобиться делать микросервисы
Микросервисы - это небольшие приложения, желательно максимально автономно работающие
А вот это как раз то о чем я писал и полностью согласен:
Монолиты часто сложно развивать по частям и иногда масштабировать, но — опять же иногда — они намного удобнее и проще поддерживаются, чем система микросервисов, если приложение не очень велико. Микросервисы могут превратиться в ад, если у вас возникло множество плохо прослеживаемых зависимостей, и просадить производительность, если не учесть того, что взаимодействие с ними требует времени.
Все что хорошо - хорошо. В остальное стандарт. Где здесь ценное сообщение?
В общем, вещи, которые действительно хорошо отделяются, можно и нужно делать микросервисами (в системе, которая не совсем маленькая, конечно). Но не всё. Далеко не всё.
nikulin_krd
09.10.2025 20:33Если никак не связаны, то зачем вы их вообще упомянули?
Повторюсь еще раз - микросервисы никак не связаны с размером команды или проекта, вот вообще никак.
Если это просто мнение, то зачем нужна была апелляция к опыту и весь тот бред что написан?
Опять 25... "Большая команда - микросервисы"... Стыдно должно быть такое утверждать
dmtrbskkv Автор
09.10.2025 20:33Потому что с этого началось
Хорошо, представим. Теоретики это тоже люди
Мнение основывается на опыте. Советую иногда использовать свой опыт
Не стыдно
xirustam
09.10.2025 20:33Читая статью вспомнил себя, когда только начал работать программистом, года в 22, наверное. До этого программинг был хобби, лет с 10, и считал себя уже шарящим в этом деле. Ох сколько же открытий предстояло мне сделать... Как же наивен я был...
Но мне повезло с тем, что я начинал с более низкоуровневых языков, типа, C++, Delphi, Assembler в конце концов, где ты просто вынужден был понимать как твои данные располагаются в оперативной памяти, и как доступ к ним из разных потоков мог просто в какаху замешать все твои данные - оттуда и пошли все эти синхронизации, блокировки, семафоры, мьютексты и т.п., а также всякие сборщики мусора. И все последующие новые языки и фреймворки я всегда пропускал через фильтр "а как это работает на базовом уровне?"
Автор, вы правильно всё делаете: изучайте, удивляйтесь, делайте открытия, только рановато вы вышли со своим мнением на такую аудиторию.
Проблема вашей статьи в том, что она, простите, бесполезна для кого бы то ни было, кроме лично вас. Новички ничего не поймут и не почерпнут. Бывалые сразу поймут вашу наивность и либо "зароют", либо попытаются "понять, простить, и отпустить".
Кстати, если хотите познать дзен программирования, вам нужно практиковать более "мощные" языки, типа C#, Java, а ещё лучше спуститься на уровень C/C++ и asm. Когда под отладчиком вы увидите по каким адресам в оперативной памяти лежат ваши данные, и увидите как пошагово эти данные меняются, тогда вы сможете сказать, что вы действительно понимаете как именно работает ваша программа на материальном уровне (ну, почти - ещё бы конечно в электронике немного разбираться и вручную спаять схему счетчика с регистрами, хотябы, но это уж чтоб точно сказать "я понимаю этот мир" :) )
dmtrbskkv Автор
09.10.2025 20:33Спасибо. Рад, что мы вместе развиваемся. Кто-то статьи пишет, кто-то учится читать. Всех нас ждёт успех
Bladimir
09.10.2025 20:33Свои 5 копеек о микросервисах:
2 причины зачем нужны:
1) большое приложение с большой БД и очень много пользователей. Перефразируя скандально известного коммерсанта: у кого нет 10к пользователей идут ... в монолит. На больших нагрузках у микросервисов можно легче замасштабировать и сами экземпляры и СУБД каждого микросервиса. Чудес не бывает, чтобы заставить отдельные микросервисы работать отностительно удобно для пользователя придется напрягаться.
2) Большая компания, с кучей бизнес-юнитов и каждое подразделение генерирует запросы на новые функиции, которые надо надо относительно быстро выдать в пром. В монолите можно, но значительно сложнее предотвратить побочные эффекты от нового функционала, особенно в шарном коде. Зачастую совершено безобидное улучшение UX вдруг выстреливает в каких-то хитрых сценариях в неожиданном месте.
Если этого нет и не предвидидется в разумной перспективе - то монолит быстрее разработать и он будет требовать меньше ресурсов.
Реально оценивайте свои перспективы - если вы в ларек с шаурмой закупите IT-фарш как на федеральную сеть фастфуда, то на 2й ларек у вас может тупо не хватить денег.
Samidara
09.10.2025 20:33Шедевр!
Статью можно брать в рамку и приводить как аргумент в пользу того, что питухон вызывает рак мозга, когда кто-то в интернете пытается защищать этот недоязык.
Samidara
09.10.2025 20:33Микросервисы - это не только про порядок в архитектуре (хотя и про это тоже), но и про надежность, гибкость и масштабируемость проекта.
Вот некоторые кейсы пользы микросервисов, выходящие за пределы просто архитектуры:
1) Допустим, мне нужно реализовать надежный, отказоустойчивый функционал для обработки данных, поступающих от партнеров. Я могу сделать отдельный сервис "приемник" который будет максимально легковесным и надежным, он будет ТОЛЬКО принимать данные и складывать их в очередь, благодаря чему партнеры смогут максимально быстро передавать нам данные почти мгновенно получая 200е коды и при этом у нас будут минимальные риски что в этом микросервисе что-то пойдет не так. А все риски и основную нагрузку будет брать на себя другой сервис, который будет эти данные обрабатывать в фоне. При этом, эта обработка никак не будет тормозить первый сервис, которым пользуются партнеры.
2) Допустим, среди доступного функционала у нас есть один наиболее ресурсозатратный флоу, дающий большую нагрузку на железо.
- В монолите, этот флоу всегда будет тормозить весь сервер, включая сервисы взаимодействующие с пользовательскими запросами. Даже если увеличить количество ресурсов, нагрузка от этого флоу всегда будет влиять на общее быстродействие системы.
- В микросервисной архитектуре, этот тяжелый флоу можно не только запускать на отдельных мощностях, но и масштабировать точечно только его. Просто статические буфера и прочий кэш заменяешь на межсервисную память типа redis и плодишь хоть 20 инстансов этого сервиса на отдельно выделенных ресурсах. При этом, сервисы для пользовательских запросов будут продолжать работать на отдельных мощностях и сайты/приложения для юзеров вообще никак не тормозятся в таком случае.
И это не какие то теоретические фантазии из области высоких материй, а реальные кейсы из личной практики, которые решают реальные проблемы на реальных проектах.
При чем, это только первое что в голову пришло, продолжать можно долго при желании.dx-77
09.10.2025 20:33Тема холиварная, конечно.
По первому пункту. Можно обойтись монолитом. Никто ж не запрещает в монолите юзать, к примеру, кафку и партнёры точно также получат быстро 200 код, а обработка будет точно также в фоне)
Второй пункт. Можно обойтись монолитом. Этот тяжёлый флоу можно тоже "обойти". Запускать в отдельном инстансе, например, или крон таской, да хоть селери таской)
dmtrbskkv Автор
09.10.2025 20:33Никто не запрещает изначальный монолит постепенно делить на микросервисы по мере необходимости. Поэтому вы оба тут правы
Такое чаще всего как раз бывает со старыми проектам, которые живут уже какое-то время
GreyPoint
09.10.2025 20:33Популярность микросервисов заставила монолитные решения отойти на задний план. А ведь монолиты требуют дешевых серверов, они проще в развертывании и разработке, часто они более практичны.
Если правильно распоряжаться ресурсами, то разница в цене серверов будет не столь уж ощутима.
Простота развертывания - здесь согласен, закинуть бинарник на ВМку и скатать systemd .service за 5 мин в разы проще чем создавать multi-stage build образы для каждого сервиса, писать под них чарты для куба, кафку между ними воткни, мониторингом все это обмажь.. Другая сторона вопроса - тех долг. Я думаю каждый, хоть немного поработавший инженер сталкивался с тонной легаси, когда кажется что это безобразие не зарефакторить и за 100 лет. А ведь закрытие тех долга тормозит введение новых фичей, да и в целом не знаю людей которые с удовольствием бы копались в легаси коде.
Что касается разработки - не согласен. Если в команде 1-2 разработчика, может имеет место быть, но как правило над более-менее сложным продуктом работает большой штат разработчиков, с разделением не только на фронтенд и бэкенд, но и на языки, часто встречал такое, что бэкенд пишется на разных языках - какие-то микросервисы на java, какие-то на go, где-то вообще C для iot. И если для микросервисной архитектуры это в целом okay, то монолит ты так просто не соберёшь без жертвоприношений Перуну.
dmtrbskkv Автор
09.10.2025 20:33Один из немногих комментариев с которым я полностью согласен. Хотя есть немного другой опыт:
У нас несколько небольших проектов монолитных лежат на сервере до тысячи рублей. А один микросервисный проект лежит на сервере более тысячи рублей и периодически ему плохо. По нагрузке монолиты посещают чаще и логика в них тяжелее
Понятно, что можно все это дело оптимизировать, сделать лучше и тд, но пока вот так
fossfusion
Как вы сюда умудрились приплести боокировки ввода-вывода я поражаюсь. Микросервисы можно масштабировать независимо от всего приложения. Микросервисы дают организационные преимущества, когда части приложения можно разделить на разные репозитории, команды разработки, циклы релиза. Заголовок этой статьи не соответствует даже содержанию этой статьи, потому что вы рассказываете про узкое подмножество микросервисов, а не про концепт в целом.
dmtrbskkv Автор
Просто я использую реальные знания, а не концепции из конференций и прочего. Если не считать прям крупных компаний, которые могут себе позволить большой цикл разработки, то у остальных микросервисы - это по факту мини проекты, которые можно было реализовать внтури одного проекта и более грамотно
И что ещё более важно, компаниям просто было бы проще собирать монолиты, тестировать их, проверять гипотизы, а потом уже думать о микросервисах по мере их необходимости. А я как раз говорю в статье о том, что необходимости зачастую нет, но эти микросервисы все равно делают. Это и быстрее и дешевле (как сервера, так и время разработчиков)
Но современный мир веб разработки говорит все больше сводится к упрощению и минимальному порогу входа, что создает огромный шклав джунов жалающих делать микросервисы на питоне, не думая о том как это в дальнейшем повлияет на проект
MechanicZelenyy
>>> Просто я использую реальные знания, а не концепции из митапов и прочего
Нет, вы используете какую чушь (видимо которую вам выдал искусственный идиот),
Я знаю много претензий к пайтон, со многими вполне солидарен, но ваша статья выглядит как какая-то очень не смешная шутка.
dmtrbskkv Автор
Если бы ИИ хорошо понимал проблематику, я был бы только рад. Так что для вас может и бред, но думаю есть те, кто уже успел прочувствовать проблему
Из реальных проблем, я мог не очень правильно структурировать статью, из-за чего до конца мало кто читает и делают преждевремнные выводы
MechanicZelenyy
Вот представьте, я бы написал статью от том, как я начал писать на php оффлайн мобильные приложения и столкнувшись с асинхронного получения снимка с камеры сделал вывод о том что монолиты зло. Ваша статья выглядит примерно также.
dmtrbskkv Автор
Да, только вот php и python - это одни из самых популярных решений на рынке веб разработки. И на основе этих инструментов я описал проблему. На основе одних из самых популярных
nikulin_krd
Так проблема не в языках, а в том, кто их неправильно юзает
dmtrbskkv Автор
Проще говоря, микросервисы предоставляют столько же организационных преимуществ, сколько и недостатков
Hardcoin
Не смешивайте небольшие личные знания и всё многообразие разработки. Разумеется сейчас вам может казаться, что вы уже точно знаете, как правильно. Но попробуйте реализовать с коллегами ещё проект по-крупнее и появится новый опыт, новые проблемы и новые выводы.
В некоторых случаях проверять гипотезы на монолите просто нецелесообразно.
dmtrbskkv Автор
Обо всем этом я высказался в конце статьи. Коротко: внедрять микросервисы нужно разумно и не надо их пихать только потому что это модно. И если проект уже очень большой или команда очень большая, то микросевисы и просто сервисы - это хорошо. Но в большинстве остальных случаев, особенно с небольшими компаниями, проще делать монолит и лишь по необходимости выделять отдельные сервисы
Hardcoin
Не проще. У нас сервисов больше, чем разработчиков и совет переделать на монолит, мне, кстати, давали. Но это просто неразумно, переделывать на микросервисы потом, когда будет гипотетическая очень большая команда.
dmtrbskkv Автор
Все правильно сделали. Но при этом не надо забывать, что куча разработчиков на одном проекте - это не самая частая история. Да и не самая нужная иногда. Если это реально один проект и он не является в сущности чем-то очень сложным
nikulin_krd
Расскажите причем тут размер «компании» и необходимость использовать микросервисы или монолит. Вот читая вашу «статью» и ваши комментарии у меня сложилось впечатление что вы джун, который в принципе не понимает для чего нужны микросервисы
dmtrbskkv Автор
Вот у вас 1-2 разработчика на базовом веб проекте. И вам надо в кротчайшие сроки запустить, проверить гипотизы и только затем начинать развивать продукт и выходить на рынок. В этом случае проще сделать изначально архитектуру проекта без микросервисов и организивать сами файлы и папки, саму кодовую базу так, чтобы можно было все это грамотно и быстро делать
Но вот у вас компании 5 лет, вы уже имеете какой-то продукт. И понимаете, что у вас тяжелый легаси код. Монолит в самом плохом смысле. И этот монолит через кое-какие кривые PR обновляется командой из 5 разработчиков. В этом случае, вам надо 100% менять подход и потому что вас много и сложно как-то мерджить все это дело. И потому что ваш легаси код уже не тянет нормально. И вам нужны более современные решения
А вот представим, что вы на рынке 10-15 лет. У вас есть большой проект с кучей внутренних сервисов. К этому моменту у вас уже должна каждая комнда заниматься свои сервисом. И т.к. у вас уже есть возможность на нормальный пайплайн разработки, то у вы можете позволить разделить зоны ответвенности, нанять отдельных разработчиков на отдельные микро-сервисы и жить на поддержке или не очень скоростном развитии
iamkisly
Никто не спорит, что собрать модульный монолит можно и нужно в первую очередь. Потому что если вы хотите влететь в MVP с микросервисами, то либо у вас очень мощный архитектор (нет), либо это явная преждевременная оптимизация.
А вот это как правило тяжело обосновать, особенно, если ты не являешься "человеком принимающим решения". Обычно куча других задач из технического долга, известные "бутылочные горлышки".. и архитектура как правило не является одним из них. Проект приносит деньги, а в каком он этапе жизненного цикла? Переписывание ради переписывания возможно только если это ваш личный пет, и вы пилите его ради лулзов
nikulin_krd
От того что их будет 50 или компании будет 10 лет необходимости в микросервисах на БАЗОВОМ веб-проекте не будет, потому что он БАЗОВЫЙ. Необходимость той или иной технологии основывается на потребностях продукта и бизнеса, а не на кол-ве человек в команде или возрасте компании.
dmtrbskkv Автор
Разработка проекта должна вестись не с учетом того как правильно. А в балансе между правильно и сроками бизнеса. И я точно знаю, что на разных этапах у бизнеса очень разные сроки. А сроки зависят и от числа разработчиков(больше не равно быстрее), и от концепций разработки, принятых с самого начала
dmtrbskkv Автор
Мои знания как раз исходя из очень разных проектов. И очень больших, и средних и совсем мелких. А стек разработки самый базированный в вебе. Именно поэтому статья была написана. Потому что я достаточно насмотрелся и захотел высказаться о том что сейчас в большинстве своем происходит
fossfusion
Я лично отвечаю за микросервис для работы с S3. Я сам вынес его из древнего монолита на yii и php 7.1 и переписал на симфони и php 8.3. Я добавил запуск в мультинстанс и теперь все другие микросервисы и могут работать с файлами как и когда им угодно, не обращаясь к монолиту. На митапы не хожу, так что не понял суть вашего возражения.
Politura
Микросервисы популяризовал бигтек, в котором никто для высоконагруженных сервисов не использует ни Питон, ни ПХП, а используют компилируемые языки, в которых нет вообще ни следа проблем из тех, которые вы озвучили в статье. Так что стали (или даже так, вынуждены были) их использовать совсем-совсем по другим причинам.
FanatPHP
А на мой взгляд вы просто пишете случайные слова, пришедшие в голову. Комментатор выше прав - не справившись с асинхронным запросом вы почему-то начали рассуждать о микросервисах. Что изначально делает ваш текст бессвязным потоком сознания.
И даже опечатку с Git не заметили, а она сильно добавляет статье шизофреничности.
outlingo
Ну, если учесть, что в статье написано "Это удивило меня как PHP-разработчика", то странное сочетание блокировок, gRPC и микросервисов в одной статье становится намного понятней. Ну не в курсе человек про то, что даже в питонячьем серпентарии не WSGI единым жив бакэнд.
dmtrbskkv Автор
Думаю если посмотреть на историю развития веб разработки, то как раз будет понятно, что я тут рассказываю о наиболее популярном пути:
- PHP
- Python
И в этом ключе как раз развивается огромное количество приложений. И в том числе на основе этого пути идет рассказ
Ну и да, методов разработки есть много, особенно тех, которые живут по несколько месяцев. Типичные прорывные технологии, срок жизни которых от 2 до 4х месяцев
Areso
Вы даже не поняли, что вам @outlingo написал. А он написал, что кроме WSGI (который синхронный), есть и ASGI (где А - асинхронный).
Ну и методы разработки, которые живут по несколько месяцев, это что?
А "типичная прорывная технология", если что, релизнулась 7 лет назад.
DarthVictor
Монолиты тоже. Монолит в котором 100 функций, из которых используются 10 будет жрать не сильно больше, чем микросервис на 10 функций.
А вот это куда важнее, на мой взгляд. Ещё можно вспомнить про разные языки и стэки технологий.
dmtrbskkv Автор
Про второй пункт тоже согласен. Поэтому в конце как раз написал о том, что надо использовать только когда есть необходимость. И вот разные стеки - это одна из самых реальных необходимостей
nikulin_krd
А зачем нужен монолит, в котором 90% мертвого кода?
DarthVictor
Не мёртвого, а не используемого на данном конкретном экземляре кластера. У вас в монолите условно 100 функций. Вы можете их побить по пяти микросервисам и запускать четыпе экземляпа первого, три — второго и т.д. А можете просто 10 экземляров монолита. Часть из этих десяти могут быть ограничены только какими-то отдельными функциями.
nikulin_krd
Аааа! А вот и прямой пример как делать не надо! Если вам в монолите надо отключать функционал, чтобы поднять экземпляры с определенным функционалом, то вам не нужен монолит. В этом случае нужна или гибридная конфигурация - монолит + микросервисы или чистые микросервисы. Иначе вы в один прекрасный момент столкнетесь с очень неприятными сайд-эффектами от такого решения.
Dhwtj
Ограничить не критичные для бизнеса и жадные до ресурсов процессы?
Я не часто встречаю на практике жадные до ресурсов, но не критичные для бизнеса сервисы.
Можете привести примеры?
Ну, рекомендации в e-commerce часто отключают. Для пользователя это не критично, для бизнеса неприятно, но заказы идут. Платежи отдельно для безопасности. Вот и все микросервисы. )
SpiderEkb
Все это можно делать и без микросервисов (в том понимании, в которым к ним все привыкли).
Почитайте про модель акторов. Она была придумана еще в 70-й годы прошлого столетия. И там все это уже было. И масштабирование и разделение на репозитории, команды разработки, циклы релиза.
У нас, к примеру, есть все - деление на репозитории, команды разработки (у каждой команды свой проект в гите в котором много отдельных репозиториев), циклы релиза. Все, кроме микросервисов.
Система (а она очень большая и очень сложная - АБС крупного банка) работает как набор модулей. Каждый модуль выполняет свою логическую функцию. Каждый модуль разрабатывается, тестируется и внедряется независимо от остальных. И может быть в дальнейшем изменен (оптимизация, изменение внутренней логики и т.п.) при условии сохранения контракта (точнее, контракт может быть расширен, главное - обеспечить обратную совместимость с той его частью, что была объявлена изначально).
Dhwtj
Кроме акторов какой-то из этих способов используете?
1. Модульные монолиты:
- NuGet/Maven пакеты для разных команд
- Feature flags для независимых релизов
- Отдельные схемы БД для модулей
2. Вертикальные слайсы (Влашин об этом пишет):
- Каждая фича - отдельная папка/namespace
- Минимум зависимостей между фичами
- Deploy всё вместе, но разрабатывают независимо
акторы Erlang/Elixir или библиотеки Java/c#?
Проблема микросервисов: решают организационные проблемы техническими средствами. А можно решить организационные проблемы организационными средствами - Conway's Law в обратную сторону.
olegl84
Все это можно сделать и в рамках монолита особенно если делать на пхп.