Comments 23
Очень содержательно! Благодарю за материал!
Прекрасный инструмент и отличный поддержка со стороны авторов!
Пользуясь случаем, будет поддержка max_workers для Kafka? А то процессами будто накладно масштабироваться.
Добрый день! Мы можем завезти max_workers для конкурентного потребления сообщений из одного топика, но только для ack-first политики потребления. Если мы устанавливаем "ручной" commit, то мы не сможем корректно ставить offset, поэтому тут уже нужно скейлится через consumer-group и горизонтально по воркерам
Если честно, то не понимаю как их вообще можно сравнивать. Инструменты ж для разного.
Есть поддержка получения множества заданий одним процессом для выполнения в своём asyncio.loop?
А отложенное выполнение заданий через время или зависимости делается на стороне брокера, как я понимаю, в вашей архитектуре? То есть по сути только путём включения экспериментальной фичи в RabbitMQ (https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq).
А как с интеграцией в Django?
Если слушать - то в доке есть пример интеграции. Если публиковать - то есть syncify враппер, который позволяет делать publish из синхронного кода
Кроме того, культ Celery настолько силен в умах, что практически все новые библиотеки для работы с MQ пытаются стать его "убийцей" и заменой.
И у меня подгорает с этих вайтишников, которые с трудом могут написать три строки кода для самостоятельной обработки очереди на нативной библитеке от поставщика, так им подавай зачем-то целый фреймворк.
Вообще проблема лежит не на разработчиках фреймворков и даже не на технологической пропоганде всякой ерунды в Интернете, а на работодателях, которые считают, что чем больше у соискателя подобных пустышек в резюме тем с более опытным программистом они имеют дело. Так сегодня существуют прикладные программисты никогда не спускавшиеся в дебри реализации Python и все глубже идущие на поводу моды и все глубже закапываясь в эту щелуху оберток.
Решить проблему кмк может только серьезная конкуренция самих инструментов, такая которая позволит качественно показать преимущество, но для этого рынок ИТ решений слишком молод и не прекращает непрерывную гонку вперед каждый день. Сегодня Celery, а завтра уже FastStream.
Вернемся к конкуренции, а что же в действительности позволяют все эти инструменты? Самый толковый аргумент, который я слышал, что эти инструменты хорошо протестированы и позволяют быстро переключиться между системами. Вот и выходит, что при возникновении проблемы современный вайтишник идет заменять драйвер, а не разбираться в причинах проблемы. Хорошо известный подход хренак-хренак и в продакшен.
Как можно решить проблему бесконечных оберток? Вводить понятные криетрии оценки: скорость, производительность, удобство разработки, количество отказов, рики для бизнеса в уходе инструмента с рынка и т.д.
В заключении конечно мне скорее всего не удасться вразумить всю эту современную школу, но возможно удасться посеять зерно и ответить не мне, так себе на вопрос, а зачем вы вообще тащите весь этот старый хлам себе в код?
И у меня подгорает с этих вайтишников, которые с трудом могут написать три строки кода для самостоятельной обработки очереди на нативной библитеке от поставщика, так им подавай зачем-то целый фреймворк.
Мне очень понравился ваш тезис и я даже разделяю ваше негодование на тему "вайтишников". Неспособность решить проблему без помощи `pip/npm/whatever install ...` - это боль современного ИТ.
Однако, с остальными вашими тезисами я вынужден не согласиться. Звучит так, будто вы разделяете инструменты только с точки зрения того, как они работают с кодом: "зачем вам эти абстракции, если можно и на клиентах все реализовать?".
Вот только современные инструменты конкурируют не только своим "удобным" API (от которого зависит скорость разработки), надежностью кода и его производительностью. Инструменты конкурируют еще и тем, какой круг задач они позволяют вам решить своим использованием.
Жизненный цикл проекта заключается не только в "написании кода", но и в его тестировании, развертывании, сопровождении и тд. Инструменты, которые закрывают как можно больше число из вышеописанных аспектов - это то, что бизнесу и разработчикам нужно сегодня.
FastStream как раз закрывает потребности не разработчиков по написанию кода, но бизнеса - по всем стадиям развития проекта:
1) Удобный API - написание кода, легче онбординг, дешевле найм и обучение, меньше ошибок на самописных костылях
2) In-Memory тестирование - воспроизводимое поведение, остутствие флакующих тестов, быстрое и безболезненное тестирование в CI
3) AsyncAPI документация - экономим на простоте взаимодействия команд, том же онбординге
4) Готовые рецепты и интеграции для Observability - увеличивает шансы, что кто-то это таки внедрит, что существенно упростит расследование инцидентов, улучшит понимание системы, позволит избежать некоторых аварий
Не случайно в статье всего 1 маленький пример кода - ведь мы говорим не о нем и "абстракциях над абстракциями"
К тому же "абстракции над абстракциями" - это не абсолютное зло. В процессе реализации функционала вашего сервисы вы будете вынуждены написать собственные абстракции, если не берете готовые. Вы уверены, что у вас получится лучше, чем у вендора "готовых абстракций"? Этот вендор скорее всего уже собрал большую часть граблей, которые вы скорее всего прочувствуете на своей шкуре. Просто банально за счет распространенности его проекта и потоку Issues от пользователей, на которые он вынужден реагировать.
Инструменты конкурируют еще и тем, какой круг задач они позволяют вам решить своим использованием.
Очевидно речь пойдет не о функциональных возможностях, так как абстракция в лучшем случае сохранит эти возможности, а в худшем сузит предоставляемый API.
Жизненный цикл проекта заключается не только в "написании кода", но и в его тестировании, развертывании, сопровождении и тд. Инструменты, которые закрывают как можно больше число из вышеописанных аспектов - это то, что бизнесу и разработчикам нужно сегодня.
Пойдем от противного. Предположим, что наш разработчик пишет сложный в тестировании код, тяжелый в развертывании и сопровождении. Мне кажется, что мы подходим напрямую к определению "вайтишника" и вот теперь когда мы понимаем, что он это не сделает хорошо, то мы предлагаем решение. Я о этом и говорю.
Вы уверены, что у вас получится лучше, чем у вендора "готовых абстракций"? Этот вендор скорее всего уже собрал большую часть граблей, которые вы скорее всего прочувствуете на своей шкуре.
А тут уже откровенно начинаем говорить о околонулевом опыте "вайтишника". Если этакий специалист не может решить задачу в три строки и тем более сомневается в своем решении, то такому специалисту как-то нужно получать опыт. Стоит ли делать ошибки на бизнес домене или на домене технологическом вопрос открытый.
Просто банально за счет распространенности его проекта и потоку Issues от пользователей, на которые он вынужден реагировать.
Мы все еще говорим о абстракции в три строки или о драйвере. О реализациях драйверов ниже есть отличный пост. Исправлять ошибки в workaround это как я думаю достаточно популярный антипаттерн и рекомендую исправлять оригинальную библиотеку по мере возможности, а не городить очередной лес костылей вокруг.
Простите, я снова вынужден с вами спорить
абстракция в лучшем случае сохранит эти возможности, а в худшем сузит предоставляемый API
Абстракция может не только "сохранить в лучшем случае", но и приумножить. Например, тот же Celery расширяет функциональные возможности голых брокеров (пряча оригинальные, но мог бы и не делать этого)
Предположим, что наш разработчик пишет сложный в тестировании код, тяжелый в развертывании и сопровождении.
Вот вы набрасываете, но не аргументируете. Я спрашиваю - "как вы будете тестировать контракты в асинхронном взаимодействии?". Это не вина разработчика, что он не смог. У него просто нет для этого инструментов
А тут уже откровенно начинаем говорить о околонулевом опыте "вайтишника"
В написанном коде всегда будут ошибки. Не важно, пишете его вы, я или "вайтишник". Если этот код написал разработчик библиотеки, а протестировали его тысячи других пользователей - шанс на ошибку в разы меньше
Абстракция может не только "сохранить в лучшем случае", но и приумножить. Например, тот же Celery расширяет функциональные возможности голых брокеров (пряча оригинальные, но мог бы и не делать этого).
Вы сужаете возможности конкретного драйвера оригинального API и говорите, что это приумножает возможности? Нет, это ограничивает API каждой конкретной библиотеки до какого-то общего (минимально достаточного) уровня.
Сравниваете скорее всего уже не абстракцию над конкретном драйвере, а скорее всего реализации и продаете клиенту уже не драйвер, а менеджер этих драйверов создавая долг в виде, а мы потом определимся с наиболее подходящим, а то и вовсе заменим. История примерно такая же как и с ORM-ами разных сортов.
Как вы будете тестировать контракты в асинхронном взаимодействии? Это не вина разработчика, что он не смог. У него просто нет для этого инструментов.
Если автор не представил асинхронный клиент, то первый разработчик выбравший этот брокер вынуждены его разработать. Если повезет, то предложить автору полученное решение, а дальше дорабатывать его сообществом сколько душе угодно. После чего можно протестировать полученный результат. Вроде проблема всех первопроходцев.
Другое дело, что такой подход создаст конкурентное преимущество другим компаниям, так что такую библиотеку коммерческая компания просто не выпустит в открытый доступ. Речь о рынке и рыночных отношениях, а не о обвинении конкретного исполнителя испытывающего дефицит инструментов, времени и т.д.
Если этот код написал разработчик библиотеки, а протестировали его тысячи других пользователей - шанс на ошибку в разы меньше
Мне пока непонятно почему разработчик сам не может протестировать свою библиотеку. Если она приносит значительные доходы компании, то это будет в обозримом будущем сделано. В противном случае говорим о выброшенных каких-то продуктах с околонулевой поддержкой.
Кстати, интересное замечание насчет
нативной библитеки от поставщика
А вы уверены, что с ними так все хорошо? Давайте пройдемся по ним, чтоли
1) RabbitMQ - тут, слава богу, все хорошо. Есть официальная pika, вот только она синхронная, не везде подойдет. Есть Дмитрий Орлов и его aio-pika - клиент феноменального качества, вот только это обертка над aiormq, который обертка над pamqp.
Какой уровень абстракций вы считаете приемлимым? - Мне не очень понятно
2) Kafka. Ну, тут у нас весело - есть confluent-kafka, которая просто python-биндинги поверх C библиотеки. И падает оно с segfault на каждый чих. Отличная "библиотека от вендора". Есть еще aiokafka - но она же не от вендора, да и не все фичи самой Kafka поддерживает
3) NATS. Еще веселее. nats-py клиент пишет человек из core-команды NATS. Вот только он же пишет и ruby клиент. И язык Python для него не основной. Я нашел МНОГО багов, пока реализовывал поддержку NATS в FastStream поверх этой библиотеки. Часть пофиксили через PR в nats-py, часть получилось обойти на уровне кода. Еще одна прекрасная библиотека от вендора
4) SQS. Тут у нас botocore (синхронный) и aiobotocore (асинхронный) ну и прочие boto3. Это абсолютно непригодные для разработки инструменты, тк банально не имеют ни автокомплитов в IDE, ни проверки типов - это просто классы, которые конструируются в рантайме, поэтому ваш код на момент написания ничего не знает об их поведении
Я не буду продолжать по всем брокерам, просто хочу сказать, что "нативные библиотеки" - это не всегда лучшее решение. В большинстве случаев потом что сам инструмент разрабатывался на одном языке, а клиенты нужны - под все. И у разработчиков вполне может не хватить экспертизы чтобы написать качественный и удобный клиент.
А вы уверены, что с ними так все хорошо?
Я достоверно знаю, что все плохо с перечисленными продуктами. Большую часть которых нет смысла использовать. Более того с трудом понимаю зачем мне нужно знать и тащить зависимости и костыли в проект над этими продуктами.
Если бизнесу в действительности переживает за решение, то выясняет с кем имеет дело и какие риски могут возникнуть с этим поставщиком, так меня в свое время смутил подход одной государственной компании заключившей договор(!) с лицензией на брокер очередей. Та еще свистопляска была его установить и использовать. И такое тоже бывает.
RabbitMQ - тут, слава богу, все хорошо.
К сожалению, все плохо с драйвером на С/C++ где течет память и крашится сама библиотека. Сейчас уже не вспомню, но имел некоторое отношение к поиску этих двух проблем. К сожалению, состояние дел на данный момент мне не известно, но надеюсь, что проблему коллегам удалось решить и отправить PR с решением автору.
Какой уровень абстракций вы считаете приемлимым? - Мне не очень понятно
Все это какие-то обертки оберток создающие еще больший зоопарк драйверов. Точно такой же зоопарк в свое время развели вокруг MySQL. Уровень абстракции один это драйвер от поставщика. Все остальное это добавочная стоимость сомнительного качества решающая сомнительные частные задачи каких-то людей. Хотите сделать что-то хорошее - помогите автору улучшить (написать) драйвер к вашему языку.
Kafka. Ну, тут у нас весело - есть confluent-kafka, которая просто python-биндинги поверх C библиотеки. И падает оно с segfault на каждый чих. Отличная "библиотека от вендора". Есть еще aiokafka - но она же не от вендора, да и не все фичи самой Kafka поддерживает
Зачем использовать продукт с ошибкой? Опять же если компетенций достаточно, то почему бы не предложить решение проблемы раз вы используете их продукт? Выходит какая-то потребительская позиция вот они там разработали (саночки возят), а мне только прокатиться разок (денег получить). Если Вы получаете прибыль с продукта, то почему бы не помочь разработчику помогающему вам в этом? Не умеете, то отправьте донат с комментарием (купите подписку, оплатите лицензию), а не городите костыли вокруг.
Я не буду продолжать по всем брокерам, просто хочу сказать, что "нативные библиотеки" - это не всегда лучшее решение. В большинстве случаев потом что сам инструмент разрабатывался на одном языке, а клиенты нужны - под все. И у разработчиков вполне может не хватить экспертизы чтобы написать качественный и удобный клиент.
Нативные библиотек всегда лучшее решение, так как это самая короткая дорога к разработчику без посредников (перекупщиков, переклейщиков наклеек, универсальных решателей проблем и т.д.), которая позволят вносить вклад (исправлять) напрямую контактируя с разработчиком и предоставляя обратную связь. Другой вопрос станет ли разработчик просто так за спасибо вашим соучастником в достижении вашей цели. Скорее всего - нет.
У вас есть выбор скорость разработки или скорость выполнения. Вы можете потратить 10 лет и разработать свой микроконтроллер, который будет идеально работать с кроликом в реальном времени. А можете использовать библиотку за 5 секунд. Странно что вас удивляют подобные вещи.
У вас есть выбор скорость разработки или скорость выполнения... можете использовать библиотеку за 5 секунд.
Вы кривите душой и это понятно, так как пытаетесь подсунуть хромую кобылу помытую и причесанную. Использование библиотеки посредника вносит еще один слой требующий обслуживания и по хорошему ещё и аудита. Вносит уйму зависимостей и каких-то сомнительных патчей требующих ревью, а так же выкашивает экспертизу у исполнителя. И все это предприятие получит всего за 5 секунд. Как и риски связанные с смертью этой чудесной библиотеки.
Вы можете потратить 10 лет и разработать свой микроконтроллер, который будет идеально работать с кроликом в реальном времени.
Ой, какая прелесть: прямо написание реализации займет 10 лет? Трех строчек кода обработки очереди? Сколько по вашему стоит реализация клиента? По моему опыту рабочий день, а толковый интерн напишет за неделю.
Я предлагаю закругляться, так как я свою позицию уже озвучил и мне добавить особенно нечего. Хотите упорствовать и продвигать разработку упражняясь в политике (демагогии) и маркетинге - ничего не имею против.
FastStream — новый убийца Celery?