Привет. Нужен совет. Устроился на работу. Здесь используют селери и называют это микросервисами. Микросервис -- селери воркер. Для общения с микросервисом юзают 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). Вопрос: нормально ли использовать селери (очередь задач) как основу для микросервисов? Это вообще законно?

Добрый день, спасибо за указанную неточность. Мы решили, что надо имя писать как «Лусьяно» С уважением Мовчан Д. А.

А я не понимаю, что можно НЕ уложить в понятие воркера. Т.е. что такого должен делать микросервис, чтобы его нельзя было стартовать как селери воркер. Сейчас там полно селери тасок, которые тупо делают select by id из postgres. Они принимают сообщение из рэббита и кладут в редис. Чем не микросервис?

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

а база одна на все микросервисы?

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

Не, у каждого набора тасок ("микросервиса") своя.

и все равно это неправильно

А деплоятся по отдельности или все сразу?

Может у него самого спросить?

меня нет ни в фб ни в твиттере

Пока не продуман деплой :) Это хороший вопрос как раз стоял сейчас на остановке и думал

и не предвидится

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

В общем пока не понятно почему это микросервисы, видимо слово знакомое для всех. С единой базой раздельный речной деплой поддержать будет сложно, cd еще сложнее. Команда постоянно должна думать про обратную совместимость схемы данных либо про паралельный деплой. Степень изолированности хромает кмк.

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

Теперь можно дать ответ. Единая БД врядли является уместной в использовании микросервисной архитектуры.

Видать пора идти спать )прочитал что база одна

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

если уж ты меняешь направление своей деятельности, то и информационные источники стоит сменить ) хорошо что хоть до телеграма добрался )

Мне кажется, что важно именно наличие связей между сущностями в БД, если они есть в самой БД, то про какие сервисы вообще речь ) Если просто используется одна СУБД, то почему и нет.

это не связано)

Спасибо за ответы!

Привет. Нужен совет. Устроился на работу. Здесь используют селери и называют это микросервисами. Микросервис -- селери воркер. Для общения с микросервисом юзают 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). Вопрос: нормально ли использовать селери (очередь задач) как основу для микросервисов? Это вообще законно?

мне интересно, а когда таска это селери воркер, то сколько там тредов-воркеров на один менеджер?

интересно, не связан ли твой проект с финансами ? и анализом данных, а то звучит знакомо ?

Самое стремное, что как раз дергать celery из ноды не проблема, а вот либы которая позволяет писать celery воркеры на ноде нет ? Ох уж эти инструменты существующие только для одного языка... Благо простую очередь можно наколбасить на RPOP/BRPOP, а если не лень то на RPOPLPUSH ? Но в такие моменты задумываешься, что свернул куда-то не туда...

https://github.com/mher/node-celery

Так самое время такую либу написать?

ты всегда можешь просто вызывать py общающийся с celery из js,

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

мне интересно, а когда таска это селери воркер, то сколько там тредов-воркеров на один менеджер?

Не, один "микросервис" -- не одна таска, но их набор, работающий с определенным набором сущностей. На данный используются дефолтные настройки селери воркера при запуске "микросервиса".

а есть какое-то оправдание микросервисам в проекте?

и каждый воркер слушает свою очередь отдельную? и сколько сейчас микросервисов?

а как воркеры поднимаются при стаке?