в общих словах :)
Если нужно записать что-то тяжёлое в базу (или выполнить ещё какую-то такую тяжкую операцию) и отпустить клиента, не заставляя ждать, есть ли способы сделать это в монолите?
Отдельным сервисом с общением через gRPC я делал, да, просто сервис получает на вход данные, чтобы с ними уже что-то сделать, а клиента отпускает восвояси, тут всё понятно.
А есть ли вариант в едином монолите такого, или это априори невозможно?
Ну то есть тебе нужен просто fire-and-forget? Task.Run и всего делов, ха-ха :)
Ну звучит вроде того, да.
Ну, по уму такое обычно делают отдельным сервисом, жизненный цикл которого отвязан от обработки запроса клиента. А реализуют уже как угодно: простой отдельный шедулер а-ля cron, или же какая-то очередь (in-proc, out-of-proc), или уже отдельный микросервис. Я видал такое и в рамках условно монолитного деплоймента.
Ну вот микросервисом я дало такое, да. :) Стало интересно именно как такое можно сделать без отдельного сервиса.
Как-то отвязаться от жизненного цикла запроса тебе всё равно нужно. Конечно, можно делать всякие изъёбства, но проще всего это отдельным сервисом (который необязательно микро-, и может деплоиться и как часть монолита).
Ну я и делал отдельным сервисом, который общался с монолитом по gRPC, но просто утром проснулся и подумал: «Хм, а вот если хочу сделать в монолите? 🤔», и понеслось. 🙂
Концептуально то же самое.
Разобрались уже? Описанная задача может тривиально решаться, например, введением отдельной таблички в базе, в которую пишутся "запросы на выполнение задач". Затем фоновый сервис, реализованный, например, как IHostedService (см. https://docs.microsoft.com/ru-ru/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice) раз в N секунд заглядывает в табличку и выбирает записи с IsProcessed = false, и затем по очереди (или параллельно) выполняет задачи, если они есть. В любой момент пользователь может узнать состояние любой задачи, заглянув в эту табличку. В микросервисных архитектурах чудо-табличка может быть заменена очередью сообщений, например, RabbitMQ.
Не назвал бы такое решение тривиальным, ибо (как и я делал, и как @fvnever писал) чаще всего просто мутится сервис/микросервис, который сам этим занимается. :) Но за идею спасибо.
слышь, вы, рыба, куда делась rss читалка с гитхаба?
Тривиальное скорее в том контексте, что задача решается в пределах одной программы (и даже одного процесса). Сильнее связность, но меньше сервисов, которые надо поднимать для отладки системы в сборе.
Салют! Планировалось её полностью переписать, но руки так и не дошли, к сожалению. Обнаружилось, что ReactiveUI плохо работает с AOT-компиляцией (приходятся сохранять огромные куски сборок через .rd.xml). Сейчас делается reflection-free ReactiveUI, но пока неизвестно, когда доделается: https://github.com/reactivemarbles/ObservableEvents Ещё делают WhenAny на сорсгенераторах.
Обсуждают сегодня