Николай, Задача - записать в БД признак, что все N задач пользователя выполнены. Но из за того что задачи могут возвращаться в очередь, получается что последняя по счету задача выполняется не всегда последней
У меня 4 задачи, считаются одной для пользователя, а событие фиксирует выполнение каждой задачи. Насчет сокетов - могли бы вы чуть больше подсказать, не работал с ними еще
Этот вариант пока самый близкий, и в других сущностях я его использовал, просто затык в том что есть определенные "средние метрики", которые должны быть посчитаны на момент просчета каждой строки.
dimonchik2013, Нет, на сейчас это к сожалению не получится. Кроме того единственный мне знакомый вариант это PostgreSQL но с ним я работаю только месяц как, мало знаний очень еще
luna3956, Понял, спасибо большое за уделенное время! Вы мне очень помогли) у меня есть теперь более цельная картина и представление о том какие варианты решения есть вообще. Этот опыт очень ценен!)
luna3956, Авторизация будет только через центральный АПИ (как единая точка входа на всех сервисы). А логика авторизации заключается в JWT токене.
Все апи знают секретное слово. Центральный АПИ генерирует токен, а потом при обращении уже на сторонние АПИ, токен расшифровуется на предмет того, что он мог такой быть и с него как раз получается инфа о лимитах клиента на текущий момент.
Все, вот как дальше уже не знаю, пока только ваши идеи мне понравились, насчет синхронизации лимитов, потому что они все таки нужны будут в центральном фронте видны, как только пользователь туда зайдет
luna3956, Единый АПИ сейчас в схеме только для того, что бы иметь доступ к БД с клиентами со всего сервиса по сути и биллинг клиента. Вся загвоздка для меня в том что если человек регистрируется в расширении для браузера например, или отдельном фронте, это все попадает в единую базу и кроме этого, при авторизации если человек зашел то имеет доступ сразу ко всей сети сервисов. Вот поэтому идея центрального АПИ и сохраняется, единая точка авторизации, регистрации.
Если все будет на "чистых микросервисах" то где хранить клиентов, их оплату ? я достаточно много видимо не понимаю в микросервисах)
luna3956, Спасибо большое!, все больше понимаю суть всей ситуации.
И сразу отвечаю на вопрос, зачем центральный АПИ: идея в том, что на общей фронт части в определенные моменты нужно будет подтягивать данные из разных сервисов (АПИ), и центральная АПИ служит не только как шлюз регистрации но и как "переходник", что бы получать данные и приводить их в единый формат.
Так как предполагается что один из сервисов будет на Node.js + MongoDB, центральный же это php+ postgre и еще один сервис это php+mysql
это все вытекло из нескольких бизнес задач:
1. единый сервис для разных веб приложений
2. единая регистрация
3. единая тарификация + шлюз оплаты
поэтому такую схему и составил, но она черновик. Пока пытаюсь собрать опыт интернета и людей что бы как можно правильные спроектировать. Так как монолитная архитектура уже не может быть реализована
Спасибо, но скажите в таком подходе это не приведет к слишком усложненной структуре ? я в том плане что центральный АПИ всегда будет участвовать в запросах, и собственно время полного цикла запроса будет большим.
Вопрос такой, допустимо что например апи сервис 2 один раз узнает лимиты, а потом они передаются в его базу и там уже проверяются, локально только на том апи ? такое дублирование имеет место быть ?
Дело в том что я первый раз настраиваю такой процесс, поэтому других способов не знаю.
Сейчас логика такова, что изменения проверяются на битбакете, и потом jenkins должен загрузить их на сервер.
Все задач 3, в каждой задаче своя ветка
есть ветки prod, dev и demo
и по факту две из них всегда буду выполняться одновременно.
Подскажите, вообще в случае организации труда нужно заводить .git на самом сервере, или достаточно будет репозитория только на битбакете например ?
То есть все сводится к тому, что я один только делаю на локалке ( по скольку я один бэкендщик), и пушу код всегда на сервер, и все клиенты при разработке общаются с ним, верно понимаю ?
на данный момент использую Bitbucket и pipeline, но там есть только 60 минут в месяц на деплой кода на сервер, jenkins не пробовал, узнаю, за это спасибо
Станислав Тамат, Спасибо, но еще такой вопрос, действительно ли нужно ставить сервер очередей ? я никогда с ними не работал и сделать корректную оценку его надобности не могу, много читал видел явные плюсы. Но вот моя задача на самом деле заключается в том, что есть один скрипт, который будет работать круглосуточно с интервалом в 15 минут и проводить закачку файла по api и записывать данные оттуда в БД.
Переписать скрипт на cli версию получилось, он теперь не отваливается, а запускаю я его при помощи cron, просто вызываю в режиме cli.
Из всего этого, подскажите, такая организация работы нормальная или реально сервер очередей делает это лучше и главное надежней ?
Валерий, Спасибо, вы немного прояснили мне взгляд на этот момент. А то попробовать технологию хочется, и задача серьезная, но решить точно нужна ли она у меня нет оснований. Думаю у меня сводится к классическому REST серверу
Да, вы правы. Изначально думал о нагрузке, но еще есть нюанс с задачами, которые могут выполняться долго (до 30 сек). Пример это формирования отчета. Клиент запрашивает отчет за период, и сервера связываются с другой базой для того, что бы выбрать данные, принять к себе и потом отдать клиенту в хорошем виде. Если есть задачи такого рода, нужны ли очереди ?
И буду задачи а-ля Cron, где клиент сможет настроить получение PUSH сообщений например об изменениях в свое кабинете и выбрать период, например каждый час, каждые 12 часов, каждые 24 часа
Это все как может быть связано с необходимостью сервера очереди?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.