Самый тлен и боль это взлом биржи конечно

Не верю сейчас в алго. Не то время.

Форекс в целом зол

Но не им единым

Эт да. :)

Есть мнения что форекс это для отъема денег

Но это холивар

Знакомый на фонду ушел. Там спокойнее. Я не понимаю, слишком медленно.

Да, тему холивара поднимать не будем. Знающие знают, а остальные пусть сливают дальше:)

Пойду Я отосплюсь. Ещё раз доброй ночи.

Или утра:)

Доброе утро чатик, вопросик. Хочется общую шину данных между микросервисами. Как я себе это представляю - есть кучка микросервисов и все они подключены к одному "чатику", для каждого микросервиса определены свои типы сообщений на которые оно реагирует. В чем профит - не надо хардкорить обращения внутри микросервисов друг к другу. На одно и то же событие(сообщение) необходим отклик нескольких микросервисов. Например на событие создания сделки в cms должен сработать микросервис создающий сделки в crm, микросервис отправляющий сделку в аналитику и микросервис который напишет сообщеньку в slack. В какую сторону смотреть?

Бля, я где-то тебя видел, мб на хакатоне 2гис?

Да, я был там

А по теме ? ;)

Напиши в nodejs тред

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

Собственно в вопросе уже часть ответа как сделать ?

В целом делается эдакий эвент-домен. Там конфиг прописывается, либо сами микросервисы обращаются к домену мол мы подписываемся на событие с таким вот именем, будет что - шли нам. Потом один из микросервисов шлет домену мол вот такое событие я сейчас совершил, вот ещё данные к нему. А домен смотрит, ага, на событие с таким именем подписаны вон те ребята, сейчас я им разошлю. А если никто не подписан - ну и ладно.

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

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

Может что-то затеряться, но падений не будет

А ещё круче если буфер

Мол если микросервис не ответил что получил данные - подождать и попробовать позже

Залогировав конечно что было что-то не то

Но!

Оно выживает

А готовых подобных решений нет? Просто я уверен что тут можно поймать много подводных камней о которых я не подумаю. Я смотрел в сторону zero/rabbitMQ и не смог понять подходит ли мне.

Может быть есть

Но у меня руками

Впрочем если HTTP-протокол между микросервисами - такое пишется дня за 3, может 5, не более.

На ноде

Я бы не был так оптимистичен)

Я сейчас как раз такое пишу

Я бы был ?

Нода, экспресс, реквест, монга

И вперед

Да неважно вообще что

Файла 4

Примерно

Дело не в технологии

Это да

3-5 дней это долго ☹️️. захардкорить обращения это дело 5 секунд ?

Тогда лучше хардкодить

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

Сам эвент-домен правда уязвим может быть ибо централизация архитектуры выходит

А вот не должно расти то

Не то чтобы централизация

В идеальном мире, ага

По факту то нужно - Имя эвента - Данные эвента В обратку - Результат в булеан - Текст ошибки если есть

Бгг

Ну а как иначе?

А если там легаси то сложнее да

Нужно ещё запаковывать и распаковывать

Это не то что "иначе", просто за твоим предложением бездна

У меня сейчас в районе 8 сервисов регулирующих довольно сложный и ветвистый алгоритм

Возможно ты в эвент домен перетащил бизнес-логику?

Ибо тогда да

Бездна

Вполне верю

Если потоком данные, кусочками, могут быть небольшие нюансы про перенаправить

В Яндекс.Метрике через js можно кормить её utm-ками, не указывая их в ссылке, а кормя ими через js api?

Есть три параллельных процесса, один очень быстрый, десятки блоков данных за минуту, второй зависит от ввода пользователя, то есть имеет непредсказуемое время ответа, причем время ещё и ограничено А третий процесс происходит в зависимости от результатов остальных двух и присылает ооочень большой объём данных

Так как обмен сообщениями довольно активный, везде устроен дебаунс сообщений, они накапливаются а потом отправляются пачкой

А почему не сразу?

Что-то проседает?

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

ERROR: S client not available

Да, у тебя бизнес-логика сложная

Тут увы

И всё, система "сообщение — ответ" перестаёт быть такой уж простой и очевидной

Это уже не просто эвент-домен

Это контроллер шины полноценный

Ага

Не один даже

Я одну фишку сделал, однозначно она уже звестна но я прям доволен)

Контроллеры эти — пассивные

И ФП

Всё понятно

?

По доброму смеюсь конечно

Они делают какие то обработки в зависимости от стейта микросервиса Конечный автомат состояний А микросервис в свою очередь при включении начинает активно спрашивать у ближайшего контроллера что ему делать в данном стейте. Хз как объяснить внятно, но короче ни одна из этих частей не требует другой, а при выключении связи просто ждёт

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

Звучит интересно

?

Ну да) Ещё микросервис-redis для оперативного обмена данными

Поверх редиса бахнул ORM

Для полного хардкора)

И ФП

А что ФП?))

Пассивные контроллеры и всё такое

С неизменным там стейтом

?

Гугл подсказал что ampq протокол именно то что я искал и там уже всё есть из коробки. Всем спасибо

При ограниченных ресурсах в случае пиков нагрузок можно ещё отсекать малоприоритетные эвенты

Ну и в целом приоритизация и всё такое

Гугл подсказал что ampq протокол именно то что я искал и там уже всё есть из коробки. Всем спасибо

Да, идея очень стара на самом деле

подскажите пожалуйста, почему NaN в функцию приходит в JS? function picturenet(count){ console.log ("count: " + count); } function start() { console.log(jpglist.length); picturenet(jpglist.length); }

jpglist - массив, полученый из json

console.log(jpglist.length); это корректно отрабатывает

console.log(jpglist.length) Что выводит?