Евгений Самсонов, классный видос, спасибо, теперь смотрю в сторону "отказаться от рэбита" и заменить на редис. Мной, кстати, задавался вопрос про Centrifugo в телеге и Саша ответил, что невозможно дисконнекты отлавливать, - это сразу заставляет писать используя либу Centrifuge =/
идентификатор сервиса (экземпляра), к которому он подключен
возможен такой кейс: команда отправлена в брокер, сервис_1 умер или перезапускается, пользователь отвалился и переподключился уже к новому (поскольку был disconnect на веб-клиенте), бизнес-логика произвела действия и положила данные в очередь. данные не будут вычитаны нужным экземпляром по его идентификатору
Сергей,
- пользователь может отключаться по своей воле, тогда при этом событии данные из очереди очищаются и сервисы websocket отписываются
- пользователь может отключаться временно (на короткий срок, разрывы по причине перезагрузки nginx(edge), плохая связь)
- пользователь подключается к случайному websocket сервису (hash балансировку не планируется), то есть даже в момент разрыва он может переподключиться к уже другой ноде
- сохранность данных-некритичный показатель, поскольку все действия - результат бизнес-логики и операций с базой данных (то есть на каждую команду данные уже в базе), восстановление состояния при долгом разрыве происходит через сервис бизнес-логики и считывание из базы данных
тут RPC по моей логике не подходит из-за того, что сообщения должны оставаться в очереди на момент перезагрузок сервиса_1 или сервиса_2, то есть для веб-клиента обновления должны проходить бесшовно
очереди под каждого клиента это не считается дорого?
jamster, значит заказывай аудит кода, потому что это стандартная рабочая архитектура, тут нечего ломать, если залатаны все дыры (проверки, отдельные эндпоинты и так далее)
jamster, ну так тоже самое, платеж создали, затем проверяете раз в 5-10 секунд статус до тех пор пока он не поменяется, как поменялся, сразу меняете в базе транзакционно все это дело. Общение по https чтобы mitm не проканал
Максим, да именно
только тут одна поправка, в компаниях такого масштаба десятки микросервисов, и логично что там где работа с сетью там эрланг, там где нужны дешевые корутины там го, там где надо сваять быстро и любым отделом там питон
поэтому в корне неверно что кто-то там из гигантов не использует ноду в качестве дата лэйера например... сервисов бизнес логики может быть и не один, а пять, один из них на ноде, общаются через grpc или кафка, как в таком случае дать оценку?
Максим, а откуда статистика то что никто не рассматривает можешь ответить?
1) Мой опыт в Reddit - некоторые микросервисы (преимущественно новые) на ноде.
2) опыт в HP Enterprise - подавляющее (>70%) большинство микросервисов на ноде.
3) бывшие коллеги в Microsoft - там прямо целые проекты с бэком на ноде
еще помню в начале 2010х (11/12 годы) на конференциях по вебу, мобильной разработке Майки (особенно Гайдар Магдануров) пиарили ноду
