а есть бенчи какие-то что такое дробление на микросервисы в плюс? просто честно говоря не понятно чем микросервис - селери-воркер лучше нормально распределенных пулов, к примеру, + что с отказоусточивостью, как воркеры переключаются или лег хост с микросервисами такими или вы держите всегда дублирующий воркер на ту же очередь?

мне просто интересно, у нас просто регулярно возникает раз в пару месяцев такая проблема

'''Ок, Лусиану.  С уважением Мовчан Д. А. '''

орчан, морчан или мовчан?

'''Ок, Лусиану.  С уважением Мовчан Д. А. '''

'''Ок, Лусиану.  С уважением Мовчан Д. А. '''

А что будет теперь? В переизданиях поменяют?

А то мало ли, покивал и забыл

А что будет теперь? В переизданиях поменяют?

Расширяемся. Ищем Python разработчика. Офис на севере СПб. 120-150к Команда: 10 инженеров (8BE + 2FE), UX/UI дизайнер и QA Стек: Python 3, Django, Django Rest Framework, RQ, Postgres, Redis, Ansible, AWS, Github, Circle CI, LogDNA, Sentry В Acquired IO мы делаем "центр управления" привлечением пользователей в мобильные приложения наших клиентов. Через наш продукт крупнейшие западные разработчики игр управляют десятками тысяч рекламных объявлений. Дополнительная информации о нашем продукте есть на сайте http://acquired.io, а также в пресс-релизах на VentureBeat и TechCrunch https://spb.hh.ru/vacancy/23864074?1 #вакансия #работа #job #oфис #office

Благодарю, приклеил обратно

Привет. Нужен совет. Устроился на работу. Здесь используют селери и называют это микросервисами. Микросервис -- селери воркер. Для общения с микросервисом юзают send_task (http://docs.celeryproject.org/en/latest/reference/celery.html#celery.Celery.send_task), либо broadcast сообщения (http://docs.celeryproject.org/en/latest/userguide/routing.html#broadcast). Меня жутко коробит, что инструмент для task queue используют как средство месседжинга. Сегодня пытался отстоять использование просто 'kombu', но не смог найти аргументов против наличия тулинга вокруг селери (типа flower). Вопрос: нормально ли использовать селери (очередь задач) как основу для микросервисов? Это вообще законно?

Редис все же не самое лучшее решение для организации очередей. Имхо рэббит лучше, ибо он для этого создан практически

скорее всего имелось в виду не для очередей, а для обмена сообщениями между сервисами

Привет. Нужен совет. Устроился на работу. Здесь используют селери и называют это микросервисами. Микросервис -- селери воркер. Для общения с микросервисом юзают send_task (http://docs.celeryproject.org/en/latest/reference/celery.html#celery.Celery.send_task), либо broadcast сообщения (http://docs.celeryproject.org/en/latest/userguide/routing.html#broadcast). Меня жутко коробит, что инструмент для task queue используют как средство месседжинга. Сегодня пытался отстоять использование просто 'kombu', но не смог найти аргументов против наличия тулинга вокруг селери (типа flower). Вопрос: нормально ли использовать селери (очередь задач) как основу для микросервисов? Это вообще законно?

Привет. Нужен совет. Устроился на работу. Здесь используют селери и называют это микросервисами. Микросервис -- селери воркер. Для общения с микросервисом юзают send_task (http://docs.celeryproject.org/en/latest/reference/celery.html#celery.Celery.send_task), либо broadcast сообщения (http://docs.celeryproject.org/en/latest/userguide/routing.html#broadcast). Меня жутко коробит, что инструмент для task queue используют как средство месседжинга. Сегодня пытался отстоять использование просто 'kombu', но не смог найти аргументов против наличия тулинга вокруг селери (типа flower). Вопрос: нормально ли использовать селери (очередь задач) как основу для микросервисов? Это вообще законно?

Просто надо перестать их называть микросервисами )

Для тех у кого бомбануло, как у меня, это не тот парень @demeliorator

Не, есть только прототип, который грозит вырасти в реализацию. Система с нуля создаётся. Идея тупо не называть это микросервисами мне нравится, спасибо! Только воркеры эти тоже какие-то неполноценные. Их код распихан в отдельных репозиториях, а вызов тасок происходит по их имени (введен специальный нейминг).

он прекрасен для этого, сильно быстрее rabbitmq

Брокер сообщений каким является рэббит это не хранилище ключ-значение, поэтому говорить что редис лучше чем рэббит, потому что быстро -странно

Для тех у кого бомбануло, как у меня, это не тот парень @demeliorator

ну тут же шла речь про "лучше для". когда есть какая конкретная задача, то выбор лучшего инструмента для удоволетворения требований обоснован

Сильно быстрее в каких условиях?

Хранение в памяти это хорошо для скорости пока у тебя не начало ничего течь

Брокер сообщений каким является рэббит это не хранилище ключ-значение, поэтому говорить что редис лучше чем рэббит, потому что быстро -странно

С редисом ты фактически сам изобретаешь брокер сообщений, будет ли он быстро работать - ну, как навелосипедишь так и будет

Течь в брокере? ;)

PHP? (тест)

Kafka же сейчас модно, не ?

http://nsq.io

не особо оправданно, если у тебя нет действительно большого потока сообщений

https://github.com/nsqio/nsq

https://github.com/nsqio/nsq

Какие минусы кафки, если потоки небольшие?

Особенность кафки в том что это распределённая система которой нужен внешний конфигуратор - zookeeper, то есть как минимум два компонента вместо одного придётся поддерживать. Ну и насколько помню там нет никакого UI и всё обслуживание делается через скрипты типа kafka-topics.sh. У rmq например есть довольно удобная веб морда.

так понимаю, это больше вопрос опыта допустим, есть опыт обслуживания кафки, зукипер не пугает, скрипты устраивают - есть другие минусы?

если очередь продалбывает то, что в нее положили без факапов, то она непригодна

господа, а рынок труда в питере сильно отличается от московского?

господа, а рынок труда в питере сильно отличается от московского?

Брокер сообщений каким является рэббит это не хранилище ключ-значение, поэтому говорить что редис лучше чем рэббит, потому что быстро -странно

zmq - это не очередь ))

а говно?

а говно?

База и репозиторий у каждого набора тасок ("микросервиса") своя. Спасибо за ответы! Не ожидал! Есть гейтвей с http ручками, который дёргает селери таски по имени. Сами таски запускаются как селери воркеры со своими базюльками, иногда эмитят ещё бродкаст сообщения. Сейчас думаю может эти наборы тасок ("микросервисы") попихать в питон пакеты, заливать на свой pypi, а в гейтвее добавить в requirements.txt. Тогда гейт и конкретный селери воркер нужно будет деплоить вместе.

Не выгорела моя супер идея с разносом тасок по питон-пакетам (пакет -- набор shared_tasks, работающих с ограниченным набором сущностей) и последующим импортом и в воркере, и в гейтвее. В гейтвей потянутся все зависимости, а это отстой. Придется всеже по имени таски из гейтвея дергать.

а откуда в gw потянутся зависимости?

Да я хотел в гейтвее писать from person.tasks import get_person get_person.delay(id) Но тогда нужно поставить пакет person. А у него зависимости от алхимии и проч.

wtf shared_task ?

Типа таска непривязанная к аппликейшену. Здесь по 'shared_task' погрепайте: http://docs.celeryproject.org/en/latest/userguide/tasks.html

я к тому что для вызова таски не обязательно иметь её код в вызывающем приложении )))

Ага, у селери можно таску даже тупо по имени вызывать: http://docs.celeryproject.org/en/latest/reference/celery.html#celery.Celery.send_task Но х.з. как это версионировать, когда, например, сигнатура таски поменяется. Да и какая-то неочевидная зависимость.

версионировать по имени.

Извиняюсь, если вопрос уже выше был или ответ на него - а трансляция докладов с митапа сегодня будет?