есть 3 приложения на Elixir, которые тянут данные с определенных источников. Будем называть их провайдерами, и пусть они будут обозначены P1, P2 и P3. Сейчас эти провайдеры пишут сообщения в MQ. Далее эти сообщения разбирает некий collector, преобразует в общий формат и кладет обратно в MQ. Назовем этот сервис C1. Далее крутятся еще 3 сервиса, которые забирают сообщения из MQ от C1 обрабатывают их и отправляют во внешний мир. Меня смущает использование MQ для коммуникаций. Как мне кажется для OTP приложений это лишнее ? Но MQ дает какие-то гарантии что сообщение будет доставлено и обработано. В OTP же можно передавать сообщения между процессами, по модели Акторов. Как всегда принимаем в расчет что любой из сервисов может упасть в какой то момент. Конечно этим займется Supervisor. Но волнует то что если сервис упал на обработке сообщения, то оно как правило пропадает из mailbox и сервис дальше обрабатывает следующее. В идеальной ситуации стоит записать куда-то что на таком то сообщении сервис упал, попробовать еще 3 раза и если все плохо, взять следующее. Если идти Erlang-way то тут мы можем использовать вместо MQ свою реализацию на ETS/DETS ? или Mnesia ? Или это все параноя и MQ в этой архитектуре не лишний ?

Ранее мне советовали использовать gen_stage тут но идея back propagation никак не ложится на сервисы P1,P2,P3

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

в общем я подтверждение тут и имел в виду да

мы на рубях просто подобное городили и просто вынимали из редиса перекладывая в процессинг и супервайзер перекладывает обратно если чайлд накрылся

с другой стороны ETS оно же в памяти и она может закончится. чаще синкать в DETS ?

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

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

да вот тут как раз и получается что надо как то строить баланс

и опять же у меня на основной работе в итоге так и сделали

т.к нужны прямо железобетонные гарантии

в базе хранить все стали ?

да

там такого говна накрутили

но в итоге более менее нормальная скорость и гарантии

у меня этот кейс в голове крутился изначально,

но всегда было чувство что делаю что-то не так

у нас просто работа с данными соц.обеспечения если там чего не выполнится, все - секир башка

даже спец чувак на зарплате следит за очередями

т.е. по сути очередь в СУБД сделали да ? с логгином событий

да

только брокер из говна и палок

т.к база лочится

с другой стороны это очень удобно, можно обратно прокрутить какой то промежуток времени

на том же тесте

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

готовых решений нет

а придумать - с первого раза явно говно получится

раза с 3 получилось что сейчас бегает

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

в общем убедил. будем писать в базу

у нас там сотни две джобок протерялись, еще на старом решении, а мужик менеджера ножом пырнул в офисе

хера себе у вас там

т.к он пришел за пособием а ему оно не начислилось

вот это и ошибка программиста ценою жизни

ну просто у него оплата жилья и вообще еду на это покупает

почти как софт для боингов писать

мы потом сделали тревожную кнопку

хотя чему удивляться если сейчас уже кардиостимуляторы взламывают

идешь такой, а у тебя сердце хакнули. и чтобы не сдохнуть перечисли 1000 битков

вот такую штуку запилили

нас кстати в целях "знакомства с пользователями" мы ходили в офисы местного собеса

ад

но отпали многие вопросы

я раньше принимал участие в создании первых тогда еще веб-приложений для больничек. там где еще половина UI была на ActiveX для Internet Explorer only. ходил по больничкам, общался. ад. там люди валерьянкой с утра закидываются и сидят на антидепрессантах.

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

есть 3 приложения на Elixir, которые тянут данные с определенных источников. Будем называть их провайдерами, и пусть они будут обозначены P1, P2 и P3. Сейчас эти провайдеры пишут сообщения в MQ. Далее эти сообщения разбирает некий collector, преобразует в общий формат и кладет обратно в MQ. Назовем этот сервис C1. Далее крутятся еще 3 сервиса, которые забирают сообщения из MQ от C1 обрабатывают их и отправляют во внешний мир. Меня смущает использование MQ для коммуникаций. Как мне кажется для OTP приложений это лишнее ? Но MQ дает какие-то гарантии что сообщение будет доставлено и обработано. В OTP же можно передавать сообщения между процессами, по модели Акторов. Как всегда принимаем в расчет что любой из сервисов может упасть в какой то момент. Конечно этим займется Supervisor. Но волнует то что если сервис упал на обработке сообщения, то оно как правило пропадает из mailbox и сервис дальше обрабатывает следующее. В идеальной ситуации стоит записать куда-то что на таком то сообщении сервис упал, попробовать еще 3 раза и если все плохо, взять следующее. Если идти Erlang-way то тут мы можем использовать вместо MQ свою реализацию на ETS/DETS ? или Mnesia ? Или это все параноя и MQ в этой архитектуре не лишний ?

Перекладывать из очереди в очередь... MQ не очень про это, как мне кажется. Для подобных вещей лично я взял бы http://storm.apache.org/ . А bolt для шторма с нужной логикой написал бы на Clojure.

Там есть гарантированная доставка, и throughput просто охеренный.

у нас не настролько там все биг-биг чтобы штормы с джавами туда тащить. ну правда) MQ хорошо для общения между микросервисами. изначально так и планировалось, пока не решили что Elixir будет достаточно для всего

акей)

там выбор то был небольшой: NodeJS or Python/AsyncIO or Elixir/OTP

шторму джава не нужна ни разу. шторм сам по себе на Clojure написан)

ааа, ну тогда без вариантов. Всё лучше нодыджээс.

Дык что с докером

ну Clojure то ранается на JVM же

Если отп не подходит

Что тогда делать и как ?

JVM, но не Java.

точнее тогда JRE но не JDK )

ну JDK это JRE + библиотечки.

я к тому, что Clojure на JVM себя ведёт намного приятнее, чем Java.

а в JRE разве есть javac ?

емнип нет.

я утрирую)

не хочу перечислять, что есть в JDK, но нет в JRE

а по поводу докера, запустить можно конечно

ERROR: S client not available

у меня пока оно в дебаг режиме крутится

Ну что тогда

Если не доуер

+ примитивный service discovery через consul + registrator

если не докер то голый сервак, очевидно же

хероку вроде OTP не научился ранать, хотя и врядли будет

если не докер, то да, голое приложение. собирать релиз и запускать.

мне с докером еще не совсем понятно как там с эрланговскими нодами быть. вот захотел я ноду подцепить, поднял контейнер еще один, первому сообщил его адресок. все ли будет так гладко. не тестил

с epmd могут быть проблемы теоретически)

ну и не стоит забывать что докер накладывает небольшое лэтенси на сеть. на WebRTC это было очень заметно)

А вот это хорошее замечание, про WebRTC

запишу щас в книжечку

почитал про storm - неплохо, думаю надо попробовать

ну это у нас coturn в контейнере бежал и без него

это для TURN/STUN

я понял. :)

в итоге поставили пару голых серверов чисто с coturn и вроде окей

просто если у нас надумают поднимать турн-сервера в докерах, надо будет их поотговаривать

у нас турн-серверов будет сильно больше.

ну это было кстати в 2016) может сейчас в докере сетка быстрее стала я не знаю. надо тестить

выгоднее просто через тот же АПИ того же digital ocean поднимать новые TURN сервера голые по требованию и сообщать айпи клиентам.

почитал про storm - неплохо, думаю надо попробовать

Шторм хорош как раз на числогрызках, вычислительных задачах, для которых на Эрланге пришлось бы поднимать map-reduce, типа старого discoproject.org, и думать как быстро делать вычисления, на каком языке. А Storm - all-in-1.

Clojure охеренный язык как раз для потоковой обработки данных, в т.ч. вычислений.

Связки Erlang+Clojure как правило более чем достаточно для всех задач.

Ну у меня пока что выбора не остается. У нас в конторе он выбран по дефолту. единственную нормальную книгу, которую я выидел - это SaltCookbook По крайней мере доступно объяснено что к чему

http://saltstackfordevops.com/ Я правда сам не читал, ничего не могу сказать про содержание, но вот есть такая книга

Clojure охеренный язык как раз для потоковой обработки данных, в т.ч. вычислений.

просто там же везде immutable state почти

Там много чего, да. А иммутабельность самым положительным образом влияет на работу JVM GC, кардинально уменьшая кол-во сборок мусора per time.

в шторме кложи кот наплакал

емнип вся кложа что там есть, это только ради дсл

переписали, что-ли... раньше больше было.