Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 141
Как вы сюда умудрились приплести боокировки ввода-вывода я поражаюсь. Микросервисы можно масштабировать независимо от всего приложения. Микросервисы дают организационные преимущества, когда части приложения можно разделить на разные репозитории, команды разработки, циклы релиза. Заголовок этой статьи не соответствует даже содержанию этой статьи, потому что вы рассказываете про узкое подмножество микросервисов, а не про концепт в целом.
Просто я использую реальные знания, а не концепции из конференций и прочего. Если не считать прям крупных компаний, которые могут себе позволить большой цикл разработки, то у остальных микросервисы - это по факту мини проекты, которые можно было реализовать внтури одного проекта и более грамотно
И что ещё более важно, компаниям просто было бы проще собирать монолиты, тестировать их, проверять гипотизы, а потом уже думать о микросервисах по мере их необходимости. А я как раз говорю в статье о том, что необходимости зачастую нет, но эти микросервисы все равно делают. Это и быстрее и дешевле (как сервера, так и время разработчиков)
Но современный мир веб разработки говорит все больше сводится к упрощению и минимальному порогу входа, что создает огромный шклав джунов жалающих делать микросервисы на питоне, не думая о том как это в дальнейшем повлияет на проект
>>> Просто я использую реальные знания, а не концепции из митапов и прочего
Нет, вы используете какую чушь (видимо которую вам выдал искусственный идиот),
Я знаю много претензий к пайтон, со многими вполне солидарен, но ваша статья выглядит как какая-то очень не смешная шутка.
Если бы ИИ хорошо понимал проблематику, я был бы только рад. Так что для вас может и бред, но думаю есть те, кто уже успел прочувствовать проблему
Из реальных проблем, я мог не очень правильно структурировать статью, из-за чего до конца мало кто читает и делают преждевремнные выводы
Проще говоря, микросервисы предоставляют столько же организационных преимуществ, сколько и недостатков
Не смешивайте небольшие личные знания и всё многообразие разработки. Разумеется сейчас вам может казаться, что вы уже точно знаете, как правильно. Но попробуйте реализовать с коллегами ещё проект по-крупнее и появится новый опыт, новые проблемы и новые выводы.
В некоторых случаях проверять гипотезы на монолите просто нецелесообразно.
Обо всем этом я высказался в конце статьи. Коротко: внедрять микросервисы нужно разумно и не надо их пихать только потому что это модно. И если проект уже очень большой или команда очень большая, то микросевисы и просто сервисы - это хорошо. Но в большинстве остальных случаев, особенно с небольшими компаниями, проще делать монолит и лишь по необходимости выделять отдельные сервисы
Не проще. У нас сервисов больше, чем разработчиков и совет переделать на монолит, мне, кстати, давали. Но это просто неразумно, переделывать на микросервисы потом, когда будет гипотетическая очень большая команда.
Расскажите причем тут размер «компании» и необходимость использовать микросервисы или монолит. Вот читая вашу «статью» и ваши комментарии у меня сложилось впечатление что вы джун, который в принципе не понимает для чего нужны микросервисы
Вот у вас 1-2 разработчика на базовом веб проекте. И вам надо в кротчайшие сроки запустить, проверить гипотизы и только затем начинать развивать продукт и выходить на рынок. В этом случае проще сделать изначально архитектуру проекта без микросервисов и организивать сами файлы и папки, саму кодовую базу так, чтобы можно было все это грамотно и быстро делать
Но вот у вас компании 5 лет, вы уже имеете какой-то продукт. И понимаете, что у вас тяжелый легаси код. Монолит в самом плохом смысле. И этот монолит через кое-какие кривые PR обновляется командой из 5 разработчиков. В этом случае, вам надо 100% менять подход и потому что вас много и сложно как-то мерджить все это дело. И потому что ваш легаси код уже не тянет нормально. И вам нужны более современные решения
А вот представим, что вы на рынке 10-15 лет. У вас есть большой проект с кучей внутренних сервисов. К этому моменту у вас уже должна каждая комнда заниматься свои сервисом. И т.к. у вас уже есть возможность на нормальный пайплайн разработки, то у вы можете позволить разделить зоны ответвенности, нанять отдельных разработчиков на отдельные микро-сервисы и жить на поддержке или не очень скоростном развитии
Вот у вас 1-2 разработчика на базовом веб проекте. И вам надо в кротчайшие сроки запустить, проверить гипотизы и только затем начинать развивать продукт и выходить на рынок.
Никто не спорит, что собрать модульный монолит можно и нужно в первую очередь. Потому что если вы хотите влететь в MVP с микросервисами, то либо у вас очень мощный архитектор (нет), либо это явная преждевременная оптимизация.
Но вот у вас компании 5 лет, вы уже имеете какой-то продукт. И понимаете, что у вас тяжелый легаси код .. вам нужны более современные решения
А вот это как правило тяжело обосновать, особенно, если ты не являешься "человеком принимающим решения". Обычно куча других задач из технического долга, известные "бутылочные горлышки".. и архитектура как правило не является одним из них. Проект приносит деньги, а в каком он этапе жизненного цикла? Переписывание ради переписывания возможно только если это ваш личный пет, и вы пилите его ради лулзов
Вот у вас 1-2 разработчика на базовом веб проекте.
От того что их будет 50 или компании будет 10 лет необходимости в микросервисах на БАЗОВОМ веб-проекте не будет, потому что он БАЗОВЫЙ. Необходимость той или иной технологии основывается на потребностях продукта и бизнеса, а не на кол-ве человек в команде или возрасте компании.
Разработка проекта должна вестись не с учетом того как правильно. А в балансе между правильно и сроками бизнеса. И я точно знаю, что на разных этапах у бизнеса очень разные сроки. А сроки зависят и от числа разработчиков(больше не равно быстрее), и от концепций разработки, принятых с самого начала
Пока опыт показывает, что чаще всего приходиться распиливать. Хотя это не отменяет банального принципа: не надо использовать технологии бездумно. Но это капитанство совершенно ни к чему.
Мои знания как раз исходя из очень разных проектов. И очень больших, и средних и совсем мелких. А стек разработки самый базированный в вебе. Именно поэтому статья была написана. Потому что я достаточно насмотрелся и захотел высказаться о том что сейчас в большинстве своем происходит
Я лично отвечаю за микросервис для работы с S3. Я сам вынес его из древнего монолита на yii и php 7.1 и переписал на симфони и php 8.3. Я добавил запуск в мультинстанс и теперь все другие микросервисы и могут работать с файлами как и когда им угодно, не обращаясь к монолиту. На митапы не хожу, так что не понял суть вашего возражения.
Микросервисы популяризовал бигтек, в котором никто для высоконагруженных сервисов не использует ни Питон, ни ПХП, а используют компилируемые языки, в которых нет вообще ни следа проблем из тех, которые вы озвучили в статье. Так что стали (или даже так, вынуждены были) их использовать совсем-совсем по другим причинам.
Просто я использую реальные знания
А на мой взгляд вы просто пишете случайные слова, пришедшие в голову. Комментатор выше прав - не справившись с асинхронным запросом вы почему-то начали рассуждать о микросервисах. Что изначально делает ваш текст бессвязным потоком сознания.
И даже опечатку с Git не заметили, а она сильно добавляет статье шизофреничности.
Как вы сюда умудрились приплести боокировки ввода-вывода
Ну, если учесть, что в статье написано "Это удивило меня как PHP-разработчика", то странное сочетание блокировок, gRPC и микросервисов в одной статье становится намного понятней. Ну не в курсе человек про то, что даже в питонячьем серпентарии не WSGI единым жив бакэнд.
Думаю если посмотреть на историю развития веб разработки, то как раз будет понятно, что я тут рассказываю о наиболее популярном пути:
- PHP
- Python
И в этом ключе как раз развивается огромное количество приложений. И в том числе на основе этого пути идет рассказ
Ну и да, методов разработки есть много, особенно тех, которые живут по несколько месяцев. Типичные прорывные технологии, срок жизни которых от 2 до 4х месяцев
Микросервисы можно масштабировать независимо от всего приложения.
Монолиты тоже. Монолит в котором 100 функций, из которых используются 10 будет жрать не сильно больше, чем микросервис на 10 функций.
Микросервисы дают организационные преимущества, когда части приложения можно разделить на разные репозитории, команды разработки, циклы релиза.
А вот это куда важнее, на мой взгляд. Ещё можно вспомнить про разные языки и стэки технологий.
Про второй пункт тоже согласен. Поэтому в конце как раз написал о том, что надо использовать только когда есть необходимость. И вот разные стеки - это одна из самых реальных необходимостей
А зачем нужен монолит, в котором 90% мертвого кода?
Не мёртвого, а не используемого на данном конкретном экземляре кластера. У вас в монолите условно 100 функций. Вы можете их побить по пяти микросервисам и запускать четыпе экземляпа первого, три — второго и т.д. А можете просто 10 экземляров монолита. Часть из этих десяти могут быть ограничены только какими-то отдельными функциями.
Аааа! А вот и прямой пример как делать не надо! Если вам в монолите надо отключать функционал, чтобы поднять экземпляры с определенным функционалом, то вам не нужен монолит. В этом случае нужна или гибридная конфигурация - монолит + микросервисы или чистые микросервисы. Иначе вы в один прекрасный момент столкнетесь с очень неприятными сайд-эффектами от такого решения.
У вас монолит может обслуживать инстансы десятков разных клиентов, с разным набором функционала.
Может, но:
Это не эффективно
Это сложно сопровождать
Это огромное поле для отказа
Что именно неэффективно и сложно сопровождать? Иметь много пользователей? Иметь разные планы подписок?
Вы планы подписки реализуете через отключение функционала монолита и запуском отдельного экземпляра для клиента? Серьезно?)) А теперь представим что вы меняете код какой-нибудь функции, которая у вас включена только у 10% ваших клиентов! Вопрос? Вы обновляете все экземпляры монолита или только те, которые имеют эту измененную функцию? Не видите проблемы? Да?))
Вы планы подписки реализуете через отключение функционала монолита и запуском отдельного экземпляра для клиента?
Бл... Я наверное плохо сформулировал, раз столько странных вопросов.
Я ничего не отключаю, у меня просто не все функции часто используются. (Вообще тут должно быть прошедшее время, на текущем проекте вообще лямбды. Прямо как в любимом автором РНР). Так вот многие из них могут и не вызываться на отдельных экземплярах. Но это не повод выносить их в отдельный сервис, чтобы разные по частоте использования вещи масштабировать отдельно.
У меня есть обратный пример из недавнего опыта. Есть оператор под кубернетис. Оператор, по сути, controller-manager + несколько контроллеров и вебхуков. Возникает необходимость добавить ещё один контроллер. Я могу добавить этот контроллер в общий процесс, который оркестрирует все контроллеры и раздуть свой монолит. Я могу скопировать main.go и включить там только новый контроллер. Я могу добавить контроллер в общий монолит и расставить флаги, который включают тот или иной набор контроллеров.
Последний вариант предпочтителен, т.к. все контроллеры опираются на одни и те же библиотеки client go для кубера, поэтому какой вариант не компилируй -- в него будут встроены одни и те же либы. Можно скомпилировать единственный вариант с флагами, тогда потребителям придётся качать один гошный бинарь вместо двух разных, но очень похожих. Когда этот гошный бинарь -- часть докер образа, профит ещё больше.
Ограничить не критичные для бизнеса и жадные до ресурсов процессы?
Я не часто встречаю на практике жадные до ресурсов, но не критичные для бизнеса сервисы.
Можете привести примеры?
Ну, рекомендации в e-commerce часто отключают. Для пользователя это не критично, для бизнеса неприятно, но заказы идут. Платежи отдельно для безопасности. Вот и все микросервисы. )
Микросервисы можно масштабировать независимо от всего приложения. Микросервисы дают организационные преимущества, когда части приложения можно разделить на разные репозитории, команды разработки, циклы релиза.
Все это можно делать и без микросервисов (в том понимании, в которым к ним все привыкли).
Почитайте про модель акторов. Она была придумана еще в 70-й годы прошлого столетия. И там все это уже было. И масштабирование и разделение на репозитории, команды разработки, циклы релиза.
У нас, к примеру, есть все - деление на репозитории, команды разработки (у каждой команды свой проект в гите в котором много отдельных репозиториев), циклы релиза. Все, кроме микросервисов.
Система (а она очень большая и очень сложная - АБС крупного банка) работает как набор модулей. Каждый модуль выполняет свою логическую функцию. Каждый модуль разрабатывается, тестируется и внедряется независимо от остальных. И может быть в дальнейшем изменен (оптимизация, изменение внутренней логики и т.п.) при условии сохранения контракта (точнее, контракт может быть расширен, главное - обеспечить обратную совместимость с той его частью, что была объявлена изначально).
Кроме акторов какой-то из этих способов используете?
1. Модульные монолиты:
- NuGet/Maven пакеты для разных команд
- Feature flags для независимых релизов
- Отдельные схемы БД для модулей
2. Вертикальные слайсы (Влашин об этом пишет):
- Каждая фича - отдельная папка/namespace
- Минимум зависимостей между фичами
- Deploy всё вместе, но разрабатывают независимо
акторы Erlang/Elixir или библиотеки Java/c#?
Проблема микросервисов: решают организационные проблемы техническими средствами. А можно решить организационные проблемы организационными средствами - Conway's Law в обратную сторону.
Немного не так. У нас очень специфическая платформа и стек.
Насколько я понимаю (я ни в коей степени не гуру в микросервисах и не претендую, так что могу ошибаться), микросервисы - это не столько про модульность, сколько про контейнеризацию. Про то, что каждый сервис (в общем случае) работает в своем изолированном окружении и даже полное падение одного сервиса никак не влияет на работу остальных.
Так вот, на нашей платформе все что запускается, запускается в своем задании (job). Которое в достаточной степени (почти полностью) изолировано от остальных. Все ресурсы выделяются в рамках задания (точнее, в рамках группы активации, которых в одном задании может быть несколько, но это уже частности) и автоматически освобождаются по окончании задания.
Как такового монолита нет. Есть большое количество модулей (бинарников, программ), каждый из которых выполняет свою логическую функцию. Каждый модуль разрабатывается, тестируется и деплоится независимо от остальных. Т.е. фактически модуль - это отдельная API со своим контрактом. Т.е. если на пальцах - написал программу которая выполняет какую-то логику, собрал, задеплоил - появилась новая API которая всем доступна.
Вызываемый модуль может быть вызван (запущен) из вызывающего как синхронно в том же задании, так и асинхронно в отдельном (параллельном).
Количество модулей очень большое - десятки, если не сотни тысяч.
БД одна на всех (тоже очень большая - несколько десятков тысяч так или иначе связанных между собой таблиц). Одна - потому что затраты на синхронизацию данных в таких масштабах будут очень велики. Точнее, есть некоторые части БД, которые продублированы в отдельных инстансах, но это там, где отставание по данным в рамках пары-тройки сотен миллисекунд не является критичным. Но в целом все модули работают с одной БД и всегда с актуальными данными.
Все это можно сделать и в рамках монолита особенно если делать на пхп.
А зачем упираться в питона или в пхп, вы правильно сказали инструмент! Так есть инструменты наверняка которые лучше подходят под ваши задачи, не зря в мире овер-дофига языков программирования и пока не нашли того на котором пишут все и вся!
Зачем мне рассказывать то чего я не знаю? Я рассказываю о тех инструментах с которыми я активно работаю уже определенное время. Плюс мои инструменты:
- Pyhton, который база современного интернета и рынка труда веб разработчиков
- PHP база для старого интернета
Кончено, есть ещё net проекты на шарпе и реальные микросервисы на GO и подобном. Но все это не самая частая практика
Но вы же буквально пишете о том чего не знаете)))
- Pyhton, который база современного интернета и рынка труда веб разработчиков
Повеселило особенно))) Прям база))
Ну видимо на рынок труда давно не заходили. Сейчас основной поток веб разработчиков - питонисты. Может и хочется вам верить в что-то иное. Но я говорю о том, что действительно происходит. Если будет возможность, крайне советую поискать разработчиков на веб проект. Очень удивитесь тому кого на рынке больше всего
Не обязательно городить микросервисы для того, чтобы загрузить файл на S3. Достаточно монолита. Достаточно даже синхронного монолита на Питоне.
Именно об этом я и пытаюсь сказать. Местами хватит монолита на чем угодно. Надо трезво оценивать необходимость микросервисов и не делать их просто потому что так модно
Я бы даже сказал, что монолита почти всегда хватит) А проблема с S3, описанная в статье, вообще не проблема, так как она никак не зависит от бэкенда и его реализации, даже если он почему-то однопоточный и однопроцессный (хотя так никто не делает) И тормозить ничего не будет, если хоть немного почитать доку S3
Про S3 - это тригер моего расследования так сказать. Проблему то я решил быстро. Просто именно она дала мне пищу для размышления
Но если чисто про S3, там была проблема с boto3 клиентом. Aioboto3 решил все
Думаю самая главная проблема в структуре текста. Я давно не писал статьи и видимо не тот путь выбор в логике повествования. Из-за этого многие начинают акцентироваться не на том. Точнее я делаю акцент не на том изначально
монолита почти всегда хватит
Вопрос только в том, что какой ценой
В Python всё иначе. Программа разделяет один поток на всех пользователей. Если кто-то тормозит систему, то и у остальных всё останавливается. Таким образом, из-за одного сложного запроса сотни других пользователей могут наблюдать бесконечную загрузку.
Как Вы это определили? Можно узнать как Вы деплоите Ваши Python приложения на продакшн?
Потому что питон - это однопоточная штука. Если только не запускать его через костыли по типу gunicorn. И вся параллельность в нем фейковая, работающая по типу генераторов(очень-очень грубо говоря)
Основная ваша проблема что вы совершенно не понимаете смысл терминов, но при этом вы активно пытаетесь их использовать.
Python не однопоточный, он вполне себе многопоточный язык, но в котором есть GIL, а это уже само по себе разные вещи. Не говоря уже что там хватает асинхроных библиотек.
Во-вторых вы постоянно используете термина микросервисы, хотя их у вас нет. Микросервисы это определенная архитектура, а не запуск нескольких параллельных обработчиков запросов. У вас что если поднять монолит на двух серверах и поставить балансировщик нагрузки, то монолит превратиться в микросервис?
В-третьих, там есть параллельность через мультипроцессинг, да это не так удобно и хорошо как параллелизм в общем пространстве памяти, но что есть. Кстати сама по себе многопоточность без gil не гарантирует параллельности, это разные понятия.
Я понимаю, что у одного термина может быть несколько смыслов, исходя из контекста
А проблема тут в статье одна - люди думают увидеть детальное исследование с примерами. Но тут огромное количество упрощений и обобщений. И судя по статистике, часть пользователей поняла это
Кстати python 3.14 можно собрать без GIL и получить полный многопоток. Сам не тестил ещё, в тырнетах читал, но вроде как именно то что все давно просили - настоящий параллелизм на множественных ядрах в общем пространстве памяти. Пока не верю, в интернете могут врать, но хочется верить, хотя многие фреймворки ещё не будут готовы к такому, как минимум потому что это специально собирать питон таким надо, и нет релизнутого бинаря
Потому что питон - это однопоточная штука.
Не правда. Кстати, Вам нужно ознакомиться с понятием "конкурентность". Это не то же самое, что "многопоточность".
через костыли по типу gunicorn
Это всё равно что для PHP сказать - "через костыли по типу PHP-FPM". Gunicorn — это не костыль, а стандартный, профессиональный WSGI-сервер для production.
пониманием, откуда взялся тренд на микросервисы в современном мире
нет, вы неправильно поняли причину возникновения тренда на микросервисы
Да, да. На Пике им. Даннинга-Крюгера вообще всё "зло". Только в Долину лучше не спускаться. Особенно с таким шерпой, как Чятик.
Я так и не понял, причем тут микросервисы. Вы не умеете писать на питоне, но приплели почему-то микросервисы
PS: Это прям эпично: Я PHP-разработчик с восьмилетним коммерческим опытом. А потом мы читаем статьи в которых авторы удивляются почему PHP во многих компаниях ред флаг и, что рынок труда полностью испорчен, и я не нужен со своим опытом 8 лет
И вот тогда я понял, почему микросервисы стали так популярны одновременно с Python.
Мда. Вселенский вывод. Микросервисы появились на фоне проблемы, которая к тому времени много где обострилась - сложность масштабирования монолитов + появление удобной инфраструктуры для масштабирования - облака с лямбдами и подобным, виртуалки, ансибл, докер и прочий CI. Питон серьёзно вообще мало кто воспринимал вплоть до взлёта MLов.
Ну вы б хотя бы спросили у ИИ, почему появились микросервисы. Питон тут явно не при чём...
ИМХО, использовать питон для разработки - моветон, так же как например чистый JS (без TS).
В коммерческой разработке я уже восемь лет. Для меня язык программирования — это инструмент и не более.
Так не бывает. Даже у тех, кто в профессии исключительно за "длинным рублем", есть любимчики, синдром утенка и список просто субъективно некомфортных языков. Поэтому когда я читаю подобные фразы, я вижу просто желание с порога показать себя дофига профессионалом, и придать значимости.
Апелляция к опыту в 99% случаев является ред флагом, который показывает, что опыта как такового и нет. Что в принципе мы и видим в статье. Есть прекрасная фраза для таких случаев «Не стыдно быть бедным, стыдно быть дешевым»
Бывает, несмотря на то, что есть субъективное восприятие. Недавно посчитал, что за этот год мне пришлось использовать больше десятка языков. И несмотря на то, что не все они мне по душе, ничего от меня не отвалилось. Не будете же Вы писать новый Sink для Confluent не на Java, расширение для PostgreSQL не на C, CLR функцию для MS SQL не на C# и т.п.?
самоуверенные ленивые дилетанты - это зло.
"...плашек на 5/8 нет... а трамвай пустить собираются..." (с) ИИ и ЕП. Во время чтения статьи отчего то часто вспоминалось )
В PHP кстати, сейчас активно переходят на файберы. На сколько понимаю.
Полнейшая чушь.
Так выглядят галлюцинации мясной LLM
PHP-модель — это как бесконечный пул воркеров
gunicorn --workers 1000, где каждый воркер умирает после одного запроса. Надежно, но крайне неэффективно.
Микросервисы тут не при чём. Просто не надо переносить опыт пхп напрямую. Откуда вы взяли синхронные библиотеки, кстати?
Эпик фейл, смотришь на такое и понимаешь, что спокойно хоть до пенсии с такими горе конкурентами можно в разработке проработать))) Новое поколение разрабов от курсов вкати в ит)
Да ладно вам, автор же просто стебется. Каждый пыхер знает что PHP однопоточнее некуда, асинхронный curl и fibers не в счёт, и вебе живёт только благодаря FPM. Зачем же так жестко карать за незнание, пусть ещё пишет, осваивает новое вне PHP.
PHP однопоточнее некуда, асинхронный curl и fibers не в счёт
Ну даже учитывая то, что коммент - откровенная ирония и сарказм, и надо всё делить на 10, но всё равно потоки и асинхронность - это абсолютно разные вещи, которые можно соединить в одну концепцию только используя термин "green thread" (да и то, это абстракция над потоками, так что ничего не гарантируется).
Те же файберы в пыхе и есть грин треды, или стекфулл корутинки, которые не красят функции, но могут работать на одном треде (что скорее всего, в 99.9% случаях) без должной реализации.
Наивная какая-то статья. Даже как-то неловко. И при чем тут git вообще...
А тема то какая холиварная! Почти никто не согласен с автором, но каждому хочется вставить свои 5 копеек:)
А что плохого сразу (конечно имея для этого опыт) сделать на микросервисах, чтобы потом не тратить отдельно ресурсы на миграцию?
Интересно ваше мнение про Service Oriented Architecture
Не могу удержаться, чтобы не перефразировать автора)
Для меня топор - это всего лишь инструмент. Поэтому переход на молоток не вызвал у меня трудностей. Моя сила удара и поставленная рука сделала переход простым. Но потом я столкнулся с проблемой: оказалось, молоток плохо колет дрова!
Даже не рассматривая обоснованность выбора Python для микросервисов, игнорируя Go, Java, C# или даже Rust или C/C++, проблема GIL, в принципе, решаема. Нерешаема проблема динамической типизации. Но это отдельный разговор.
Микросервисы пошли от Гугла, с кубернатесом, го и gRPC. А питон с ними никак не связан. Он существовал задолго до этих технологий.
Да ну?
UPD 3
В статье очень много упрощений. Учитывайте это. И да, я знаю, что микросервисы появились давно и не из-за всяких питонов. Знаю, что при желании все можно запустить в многопотоке. Знаю, что крупные компании могут позволить себе большой и серьезный путь разработки со всеми хорошими практикам. И конечно же, знаю, что питон лишь один из языков бекенда. Но все ещё это один из наиболее популярных языков.
Так и не понял сколько у вас комерческого опыта программирования
Вы распределили нагрузку между копиями одного и того же инстанса и объявили это микросервисной архитектурой...
На мыльно-точильно-дрочильном заводе работает маленький Пьер.
Намылит, наточит, надрочит, хохочет и думает: "Я инженер!"
Честно говоря, ничего не понял. Мысли статьи:
Не пишите микросервисы, потому что блокирующий ввод-вывод вас подвесит. (К слову, блокирующий ввод-вывод хорошо сочетается с потоками, а асинхронный живёт в одном, использовать блокирующий не по делу — это не знать азов.) Но скажите, как это вообще связано с микросервисами? Я не вижу никакой связи.
Научитесь пользоваться git, прежде чем писать микросервисы. Ну, git — штука полезная, конечно, стандарт сейчас. Но как он связан с архитектурами???
Микросервисы надо применять по назначению. Ну, всё на свете надо применять по назначению. Касторка помогает от запора, но не лечит зубную боль. С архитектурами так же. Где здесь ценное сообщение?
Чтобы делать микросервисы, нужна большая команда. Тезис загадочен. При чём тут размер команды?
В общем, озадачен прочитанным. Прямо хочется спросить, что именно автор понимает под словом "микросервис"?
Монолиты часто сложно развивать по частям и иногда масштабировать, но — опять же иногда — они намного удобнее и проще поддерживаются, чем система микросервисов, если приложение не очень велико. Микросервисы могут превратиться в ад, если у вас возникло множество плохо прослеживаемых зависимостей, и просадить производительность, если не учесть того, что взаимодействие с ними требует времени.
В общем, вещи, которые действительно хорошо отделяются, можно и нужно делать микросервисами (в системе, которая не совсем маленькая, конечно). Но не всё. Далеко не всё.
Никак, я не совсем об этом. Блокирующий ввод-вывод — это как мой личный триггер изучения вопроса
Он является более базовым знанием, которое позволяет управлять проектом если в команде несколько человек без необходимости резать на микросервисы и усложнять архитектуру
Оно тут и не должно быть, это статья типа "Мнение", а не исследование
Причинно-следственная связь у меня наборот. Если есть большая команда, то может понадобиться делать микросервисы
Микросервисы - это небольшие приложения, желательно максимально автономно работающие
А вот это как раз то о чем я писал и полностью согласен:
Монолиты часто сложно развивать по частям и иногда масштабировать, но — опять же иногда — они намного удобнее и проще поддерживаются, чем система микросервисов, если приложение не очень велико. Микросервисы могут превратиться в ад, если у вас возникло множество плохо прослеживаемых зависимостей, и просадить производительность, если не учесть того, что взаимодействие с ними требует времени.
Все что хорошо - хорошо. В остальное стандарт. Где здесь ценное сообщение?
В общем, вещи, которые действительно хорошо отделяются, можно и нужно делать микросервисами (в системе, которая не совсем маленькая, конечно). Но не всё. Далеко не всё.
Если никак не связаны, то зачем вы их вообще упомянули?
Повторюсь еще раз - микросервисы никак не связаны с размером команды или проекта, вот вообще никак.
Если это просто мнение, то зачем нужна была апелляция к опыту и весь тот бред что написан?
Опять 25... "Большая команда - микросервисы"... Стыдно должно быть такое утверждать
Читая статью вспомнил себя, когда только начал работать программистом, года в 22, наверное. До этого программинг был хобби, лет с 10, и считал себя уже шарящим в этом деле. Ох сколько же открытий предстояло мне сделать... Как же наивен я был...
Но мне повезло с тем, что я начинал с более низкоуровневых языков, типа, C++, Delphi, Assembler в конце концов, где ты просто вынужден был понимать как твои данные располагаются в оперативной памяти, и как доступ к ним из разных потоков мог просто в какаху замешать все твои данные - оттуда и пошли все эти синхронизации, блокировки, семафоры, мьютексты и т.п., а также всякие сборщики мусора. И все последующие новые языки и фреймворки я всегда пропускал через фильтр "а как это работает на базовом уровне?"
Автор, вы правильно всё делаете: изучайте, удивляйтесь, делайте открытия, только рановато вы вышли со своим мнением на такую аудиторию.
Проблема вашей статьи в том, что она, простите, бесполезна для кого бы то ни было, кроме лично вас. Новички ничего не поймут и не почерпнут. Бывалые сразу поймут вашу наивность и либо "зароют", либо попытаются "понять, простить, и отпустить".
Кстати, если хотите познать дзен программирования, вам нужно практиковать более "мощные" языки, типа C#, Java, а ещё лучше спуститься на уровень C/C++ и asm. Когда под отладчиком вы увидите по каким адресам в оперативной памяти лежат ваши данные, и увидите как пошагово эти данные меняются, тогда вы сможете сказать, что вы действительно понимаете как именно работает ваша программа на материальном уровне (ну, почти - ещё бы конечно в электронике немного разбираться и вручную спаять схему счетчика с регистрами, хотябы, но это уж чтоб точно сказать "я понимаю этот мир" :) )
Свои 5 копеек о микросервисах:
2 причины зачем нужны:
1) большое приложение с большой БД и очень много пользователей. Перефразируя скандально известного коммерсанта: у кого нет 10к пользователей идут ... в монолит. На больших нагрузках у микросервисов можно легче замасштабировать и сами экземпляры и СУБД каждого микросервиса. Чудес не бывает, чтобы заставить отдельные микросервисы работать отностительно удобно для пользователя придется напрягаться.
2) Большая компания, с кучей бизнес-юнитов и каждое подразделение генерирует запросы на новые функиции, которые надо надо относительно быстро выдать в пром. В монолите можно, но значительно сложнее предотвратить побочные эффекты от нового функционала, особенно в шарном коде. Зачастую совершено безобидное улучшение UX вдруг выстреливает в каких-то хитрых сценариях в неожиданном месте.
Если этого нет и не предвидидется в разумной перспективе - то монолит быстрее разработать и он будет требовать меньше ресурсов.
Реально оценивайте свои перспективы - если вы в ларек с шаурмой закупите IT-фарш как на федеральную сеть фастфуда, то на 2й ларек у вас может тупо не хватить денег.
Шедевр!
Статью можно брать в рамку и приводить как аргумент в пользу того, что питухон вызывает рак мозга, когда кто-то в интернете пытается защищать этот недоязык.
Микросервисы - это не только про порядок в архитектуре (хотя и про это тоже), но и про надежность, гибкость и масштабируемость проекта.
Вот некоторые кейсы пользы микросервисов, выходящие за пределы просто архитектуры:
1) Допустим, мне нужно реализовать надежный, отказоустойчивый функционал для обработки данных, поступающих от партнеров. Я могу сделать отдельный сервис "приемник" который будет максимально легковесным и надежным, он будет ТОЛЬКО принимать данные и складывать их в очередь, благодаря чему партнеры смогут максимально быстро передавать нам данные почти мгновенно получая 200е коды и при этом у нас будут минимальные риски что в этом микросервисе что-то пойдет не так. А все риски и основную нагрузку будет брать на себя другой сервис, который будет эти данные обрабатывать в фоне. При этом, эта обработка никак не будет тормозить первый сервис, которым пользуются партнеры.
2) Допустим, среди доступного функционала у нас есть один наиболее ресурсозатратный флоу, дающий большую нагрузку на железо.
- В монолите, этот флоу всегда будет тормозить весь сервер, включая сервисы взаимодействующие с пользовательскими запросами. Даже если увеличить количество ресурсов, нагрузка от этого флоу всегда будет влиять на общее быстродействие системы.
- В микросервисной архитектуре, этот тяжелый флоу можно не только запускать на отдельных мощностях, но и масштабировать точечно только его. Просто статические буфера и прочий кэш заменяешь на межсервисную память типа redis и плодишь хоть 20 инстансов этого сервиса на отдельно выделенных ресурсах. При этом, сервисы для пользовательских запросов будут продолжать работать на отдельных мощностях и сайты/приложения для юзеров вообще никак не тормозятся в таком случае.
И это не какие то теоретические фантазии из области высоких материй, а реальные кейсы из личной практики, которые решают реальные проблемы на реальных проектах.
При чем, это только первое что в голову пришло, продолжать можно долго при желании.
Тема холиварная, конечно.
По первому пункту. Можно обойтись монолитом. Никто ж не запрещает в монолите юзать, к примеру, кафку и партнёры точно также получат быстро 200 код, а обработка будет точно также в фоне)
Второй пункт. Можно обойтись монолитом. Этот тяжёлый флоу можно тоже "обойти". Запускать в отдельном инстансе, например, или крон таской, да хоть селери таской)
Популярность микросервисов заставила монолитные решения отойти на задний план. А ведь монолиты требуют дешевых серверов, они проще в развертывании и разработке, часто они более практичны.
Если правильно распоряжаться ресурсами, то разница в цене серверов будет не столь уж ощутима.
Простота развертывания - здесь согласен, закинуть бинарник на ВМку и скатать systemd .service за 5 мин в разы проще чем создавать multi-stage build образы для каждого сервиса, писать под них чарты для куба, кафку между ними воткни, мониторингом все это обмажь.. Другая сторона вопроса - тех долг. Я думаю каждый, хоть немного поработавший инженер сталкивался с тонной легаси, когда кажется что это безобразие не зарефакторить и за 100 лет. А ведь закрытие тех долга тормозит введение новых фичей, да и в целом не знаю людей которые с удовольствием бы копались в легаси коде.
Что касается разработки - не согласен. Если в команде 1-2 разработчика, может имеет место быть, но как правило над более-менее сложным продуктом работает большой штат разработчиков, с разделением не только на фронтенд и бэкенд, но и на языки, часто встречал такое, что бэкенд пишется на разных языках - какие-то микросервисы на java, какие-то на go, где-то вообще C для iot. И если для микросервисной архитектуры это в целом okay, то монолит ты так просто не соберёшь без жертвоприношений Перуну.
Один из немногих комментариев с которым я полностью согласен. Хотя есть немного другой опыт:
У нас несколько небольших проектов монолитных лежат на сервере до тысячи рублей. А один микросервисный проект лежит на сервере более тысячи рублей и периодически ему плохо. По нагрузке монолиты посещают чаще и логика в них тяжелее
Понятно, что можно все это дело оптимизировать, сделать лучше и тд, но пока вот так
Не хватает кармы что бы немного восстановить Вам, как мне кажется, не совсем оправданно заниженный рейтинг. Всех комментариев не читал, но предвижу толпы ущемившихся девопсов и питонистов. Грамотно спроектированный монолит действительно выигрывает у микросервисов по всем параметрам в мире идеального кода, в том числе и в цене за обслуживание кстати. Проблема в том что мы живём в мире неидеального. Для монолита нужны настоящие сеньоры, архитекторы и аналитики в одном лице, их на рынке не так много, поэтому для бизнеса логичнее диверсифицировать свои риски моделью микросервисов и чуть менее квалифицированным персоналом. Плюс играет роль технологический стэк который может быть разным под разные решаемые задачи. Это уже вопрос риторики - считать ли это разными проектами или "микросервисами" одного проекта.
/thread
Я PHP-разработчик
Здесь стоило бы остановиться.
на 521 комментарии стоило бы уже остановится
Вы действительно думаете, что заходя в профили пользователей, которые вам пишут комментарии с критикой, и указывая на их кол-во комментариев, это изменит в положительную сторону отношение к вам и вашей "статье"? Вы так и не сделали правильных выводов из всего что здесь происходит... Повторю народное творчество - "Не стыдно быть бедным, стыдно быть дешевым"
Микросервис дает архитектурные преимущества, Там где их уместно применять. Я согласен, сейчас модно делать все на микросервисах и часто в этом мягко говоря перегибают.
Буквально недавно видел в одной большой коммерческой системе зоопарк из такоих во поделок, каждая со своей БД, с похожими таблицами и синхронизацию данных между ними через рэббит по пол часа. Это ппц
Тем не менее микросервисы совершенно не призваны решать косой питоновский подход к асинхронному программированию. Там свои подходы к решению этих задач но микросервис был выдуман не для этого.
Вспомните SOLID принцип единой ответственности
На шапре с асинхронщиной все в полном порядке, но микросервисты тоже строят - именно для того чтобы иметь модуль который делает одну понятную задачу. И кстати разрабатывать все микросервисы может одна команда. Гитом владеют люди не хуже вас, как бы это ошеломляюще не звучало
Да, как раз об этом я говорил. А питон это как пример языка в котором желание использовать микросервисы может быть больше обычного
Python часто не может обеспечить необходимую латентность. Особенно в случае двунаправленного потокового gRPC. Если коммуникация микросервисов происходит через полпланеты с задержкой 30 мс - это значение не имеет. А если внутри k8s в одном ЦОД - то высокая латентность Python сразу становится поперёк горла.
Изучите ради интереса результат работы protoc для C++ и Python. Там сразу видно, что если для C++ получаем машинный код для доступа к каждому полю protobuf сообщения, то в Python предлагается только полная десериализация всего сообщения в объект интерпретацией строки дескриптора. Отсюда и разница в латентности не на порядок, как обычно бывает, а уже на два порядка. С другой стороны, что ему делать? Не генерировать же C++ код для so/dll специально для каждого proto?
На практике, когда прототипировали, у нас получалось, что медианная латентность тестового микросервиса при ответе на запросы в двунаправленном gRPC потоке на С++ в k8s была ~300 мкс, а Python - ~20 мс. Вот они два порядка!
В итоге всё равно ушли на C#, так как, несмотря на то, что он в полтора раза медленней C++ на фиксированной схеме, при эволюции схемы и, тем более, хранении схем в schema registry, позволяет рефлексией компилировать оптимизированные классы для новых и измененных схем на лету. Чего на C++ добиться затруднительно.
Деньги зло. Политика зло. Женщины зло. Политкорректность зло.
Квас, Битлз и jQuery!
Спасибо за погружение в серый мир банальщины.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микросервисы — это зло