Я 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
Комментарии люблю и уважаю, и в них есть дополнения к статье. К счастью, читатели показали мне, что структура статьи получилась сложной и акцент сильно теряется. Но статья уже написана, и, надеюсь, найдутся те, кто понимает мою боль, или те, для кого написанное станет пищей для ума и поводом обдумать свой подход к разработке в положительную сторону.
Комментарии (38)
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Думаю самая главная проблема в структуре текста. Я давно не писал статьи и видимо не тот путь выбор в логике повествования. Из-за этого многие начинают акцентироваться не на том. Точнее я делаю акцент не на том изначально
Andchir
09.10.2025 20:33В Python всё иначе. Программа разделяет один поток на всех пользователей. Если кто-то тормозит систему, то и у остальных всё останавливается. Таким образом, из-за одного сложного запроса сотни других пользователей могут наблюдать бесконечную загрузку.
Как Вы это определили? Можно узнать как Вы деплоите Ваши Python приложения на продакшн?
dmtrbskkv Автор
09.10.2025 20:33Потому что питон - это однопоточная штука. Если только не запускать его через костыли по типу gunicorn. И вся параллельность в нем фейковая, работающая по типу генераторов(очень-очень грубо говоря)
MechanicZelenyy
09.10.2025 20:33Основная ваша проблема что вы совершенно не понимаете смысл терминов, но при этом вы активно пытаетесь их использовать.
Python не однопоточный, он вполне себе многопоточный язык, но в котором есть GIL, а это уже само по себе разные вещи. Не говоря уже что там хватает асинхроных библиотек.
Во-вторых вы постоянно используете термина микросервисы, хотя их у вас нет. Микросервисы это определенная архитектура, а не запуск нескольких параллельных обработчиков запросов. У вас что если поднять монолит на двух серверах и поставить балансировщик нагрузки, то монолит превратиться в микросервис?
В-третьих, там есть параллельность через мультипроцессинг, да это не так удобно и хорошо как параллелизм в общем пространстве памяти, но что есть. Кстати сама по себе многопоточность без gil не гарантирует параллельности, это разные понятия.
test4354545
09.10.2025 20:33пониманием, откуда взялся тренд на микросервисы в современном мире
нет, вы неправильно поняли причину возникновения тренда на микросервисы
dmtrbskkv Автор
09.10.2025 20:33А если мы говорим о повсеместном использовании? Исключая большие компании - они в целом во многом исключения из-за большого числа ресурсов и возможностей
test4354545
09.10.2025 20:33Вы серьезно думаете что небольшой комании легче создать отдельный микросервис чем запустить нужную блокирующую задачу в отдельном процессе/потоке?
fossfusion
Как вы сюда умудрились приплести боокировки ввода-вывода я поражаюсь. Микросервисы можно масштабировать независимо от всего приложения. Микросервисы дают организационные преимущества, когда части приложения можно разделить на разные репозитории, команды разработки, циклы релиза. Заголовок этой статьи не соответствует даже содержанию этой статьи, потому что вы рассказываете про узкое подмножество микросервисов, а не про концепт в целом.
dmtrbskkv Автор
Просто я использую реальные знания, а не концепции из конференций и прочего. Если не считать прям крупных компаний, которые могут себе позволить большой цикл разработки, то у остальных микросервисы - это по факту мини проекты, которые можно было реализовать внтури одного проекта и более грамотно
И что ещё более важно, компаниям просто было бы проще собирать монолиты, тестировать их, проверять гипотизы, а потом уже думать о микросервисах по мере их необходимости. А я как раз говорю в статье о том, что необходимости зачастую нет, но эти микросервисы все равно делают. Это и быстрее и дешевле (как сервера, так и время разработчиков)
Но современный мир веб разработки говорит все больше сводится к упрощению и минимальному порогу входа, что создает огромный шклав джунов жалающих делать микросервисы на питоне, не думая о том как это в дальнейшем повлияет на проект
MechanicZelenyy
>>> Просто я использую реальные знания, а не концепции из митапов и прочего
Нет, вы используете какую чушь (видимо которую вам выдал искусственный идиот),
Я знаю много претензий к пайтон, со многими вполне солидарен, но ваша статья выглядит как какая-то очень не смешная шутка.
dmtrbskkv Автор
Если бы ИИ хорошо понимал проблематику, я был бы только рад. Так что для вас может и бред, но думаю есть те, кто уже успел прочувствовать проблему
Из реальных проблем, я мог не очень правильно структурировать статью, из-за чего до конца мало кто читает и делают преждевремнные выводы
MechanicZelenyy
Вот представьте, я бы написал статью от том, как я начал писать на php оффлайн мобильные приложения и столкнувшись с асинхронного получения снимка с камеры сделал вывод о том что монолиты зло. Ваша статья выглядит примерно также.
dmtrbskkv Автор
Да, только вот php и python - это одни из самых популярных решений на рынке веб разработки. И на основе этих инструментов я описал проблему. На основе одних из самых популярных
dmtrbskkv Автор
Проще говоря, микросервисы предоставляют столько же организационных преимуществ, сколько и недостатков
Hardcoin
Не смешивайте небольшие личные знания и всё многообразие разработки. Разумеется сейчас вам может казаться, что вы уже точно знаете, как правильно. Но попробуйте реализовать с коллегами ещё проект по-крупнее и появится новый опыт, новые проблемы и новые выводы.
В некоторых случаях проверять гипотезы на монолите просто нецелесообразно.
dmtrbskkv Автор
Обо всем этом я высказался в конце статьи. Коротко: внедрять микросервисы нужно разумно и не надо их пихать только потому что это модно. И если проект уже очень большой или команда очень большая, то микросевисы и просто сервисы - это хорошо. Но в большинстве остальных случаев, особенно с небольшими компаниями, проще делать монолит и лишь по необходимости выделять отдельные сервисы
Hardcoin
Не проще. У нас сервисов больше, чем разработчиков и совет переделать на монолит, мне, кстати, давали. Но это просто неразумно, переделывать на микросервисы потом, когда будет гипотетическая очень большая команда.
dmtrbskkv Автор
Все правильно сделали. Но при этом не надо забывать, что куча разработчиков на одном проекте - это не самая частая история. Да и не самая нужная иногда. Если это реально один проект и он не является в сущности чем-то очень сложным
nikulin_krd
Расскажите причем тут размер «компании» и необходимость использовать микросервисы или монолит. Вот читая вашу «статью» и ваши комментарии у меня сложилось впечатление что вы джун, который в принципе не понимает для чего нужны микросервисы
dmtrbskkv Автор
Вот у вас 1-2 разработчика на базовом веб проекте. И вам надо в кротчайшие сроки запустить, проверить гипотизы и только затем начинать развивать продукт и выходить на рынок. В этом случае проще сделать изначально архитектуру проекта без микросервисов и организивать сами файлы и папки, саму кодовую базу так, чтобы можно было все это грамотно и быстро делать
Но вот у вас компании 5 лет, вы уже имеете какой-то продукт. И понимаете, что у вас тяжелый легаси код. Монолит в самом плохом смысле. И этот монолит через кое-какие кривые PR обновляется командой из 5 разработчиков. В этом случае, вам надо 100% менять подход и потому что вас много и сложно как-то мерджить все это дело. И потому что ваш легаси код уже не тянет нормально. И вам нужны более современные решения
А вот представим, что вы на рынке 10-15 лет. У вас есть большой проект с кучей внутренних сервисов. К этому моменту у вас уже должна каждая комнда заниматься свои сервисом. И т.к. у вас уже есть возможность на нормальный пайплайн разработки, то у вы можете позволить разделить зоны ответвенности, нанять отдельных разработчиков на отдельные микро-сервисы и жить на поддержке или не очень скоростном развитии
dmtrbskkv Автор
Разработка проекта должна вестись не с учетом того как правильно. А в балансе между правильно и сроками бизнеса. И я точно знаю, что на разных этапах у бизнеса очень разные сроки. А сроки зависят и от числа разработчиков(больше не равно быстрее), и от концепций разработки, принятых с самого начала
dmtrbskkv Автор
Мои знания как раз исходя из очень разных проектов. И очень больших, и средних и совсем мелких. А стек разработки самый базированный в вебе. Именно поэтому статья была написана. Потому что я достаточно насмотрелся и захотел высказаться о том что сейчас в большинстве своем происходит
fossfusion
Я лично отвечаю за микросервис для работы с S3. Я сам вынес его из древнего монолита на yii и php 7.1 и переписал на симфони и php 8.3. Я добавил запуск в мультинстанс и теперь все другие микросервисы и могут работать с файлами как и когда им угодно, не обращаясь к монолиту. На митапы не хожу, так что не понял суть вашего возражения.
Politura
Микросервисы популяризовал бигтек, в котором никто для высоконагруженных сервисов не использует ни Питон, ни ПХП, а используют компилируемые языки, в которых нет вообще ни следа проблем из тех, которые вы озвучили в статье. Так что стали (или даже так, вынуждены были) их использовать совсем-совсем по другим причинам.
outlingo
Ну, если учесть, что в статье написано "Это удивило меня как PHP-разработчика", то странное сочетание блокировок, gRPC и микросервисов в одной статье становится намного понятней. Ну не в курсе человек про то, что даже в питонячьем серпентарии не WSGI единым жив бакэнд.
dmtrbskkv Автор
Думаю если посмотреть на историю развития веб разработки, то как раз будет понятно, что я тут рассказываю о наиболее популярном пути:
- PHP
- Python
И в этом ключе как раз развивается огромное количество приложений. И в том числе на основе этого пути идет рассказ
Ну и да, методов разработки есть много, особенно тех, которые живут по несколько месяцев. Типичные прорывные технологии, срок жизни которых от 2 до 4х месяцев
Areso
Вы даже не поняли, что вам @outlingo написал. А он написал, что кроме WSGI (который синхронный), есть и ASGI (где А - асинхронный).
Ну и методы разработки, которые живут по несколько месяцев, это что?
А "типичная прорывная технология", если что, релизнулась 7 лет назад.
DarthVictor
Монолиты тоже. Монолит в котором 100 функций, из которых используются 10 будет жрать не сильно больше, чем микросервис на 10 функций.
А вот это куда важнее, на мой взгляд. Ещё можно вспомнить про разные языки и стэки технологий.
dmtrbskkv Автор
Про второй пункт тоже согласен. Поэтому в конце как раз написал о том, что надо использовать только когда есть необходимость. И вот разные стеки - это одна из самых реальных необходимостей