Асинхронный Обмен Сообщениями. Начало
1. Основы распределённой архитектуры
Это совсем не новая проблема, но в последние несколько лет она становится все более и более распространённой. Кроме того, эту проблему трудно решить быстро - или даже быстро описать решение.
Задача
Проблема обычно проявляется в желании досрочно вернуться из HTTP-запроса. Как только запрос был получен, разработчик хочет, чтобы серверный API не дожидался завершения обработки, а немедленно отправил ответ клиенту. Обычно это называют «запустил и забыл».
Цель состоит в том, чтобы HTTP-вызов просто запускал рабочий процесс. Затем этот рабочий процесс выполнялся бы на стороне сервера без дополнительных действий со стороны клиентского приложения.
Назовём это «внешний запрос», т.к. это код, который выполняется вне основного запроса. Это может быть опасно, поэтому решение более сложное, чем кажется на первый взгляд необходимым.
Решение
Подходящим решением для внешнего запроса является асинхронный обмен сообщениями. Он состоит из двух частей (с необязательной третьей частью):
1) Перманентная очередь
Под «перманентной» подразумевается очередь, которая, по крайней мере, сохраняется на диск при добавлении элемента. Другими словами, сообщения, отправленные в очередь, долговечны. Таким образом, очереди в памяти
Queue<T>, BlockingCollection<T> или ChannelWriter<T> не являются «перманентными очередями».2) Бэкенд-сервис
Это независимый сервис, который читает из этой перманентной очереди и обрабатывает элементы в ней (т.е. выполняет длительную операцию).
3) (необязательно) Какой-либо метод получения результатов.
Если клиенту необходимо знать результат длительной операции, то это та часть, которая предоставляет этот результат клиенту.
Один из распространённых примеров - отправка e-mail. Если API хочет отправить письмо, но не хочет ждать окончания отправки перед возвратом клиенту, то API должен добавить сообщение в перманентную очередь с описанием отправляемого письма, а затем вернуться. Поскольку это перманентная очередь, сообщение очереди сохраняется на диск перед отправкой HTTP-ответа клиенту. Затем отдельный сервис, читающий из этой очереди, извлекает сообщение и фактически отправляет e-mail.
Другой распространённый пример - запись в базу данных. Иногда возникают ситуации, когда API знает, что писать в БД, но не хочет заставлять клиента ждать. В этом случае API должен записать информацию в перманентную очередь, а затем выдать ответ клиенту. Затем отдельный бэкенд-сервис, читающий из этой очереди, извлекает информацию и выполняет фактическое обновление БД.
Получения результатов часто не требуется. Например, собственно письмо обычно является результатом отправки e-mail, а записи в базе данных в итоге будут отображаться, когда пользователь обновит страницу. Но иногда вам нужно, чтобы клиент был уведомлён о результатах. Это возможно либо с помощью опроса, либо с помощью упреждающего уведомления с использованием технологии обмена сообщениями, такой как WebSockets.
Далее мы подробно остановимся на каждой части решения и рассмотрим конкретные подходы.
Продолжение следует…
Источник: https://blog.stephencleary.com/2021/01/asynchronous-messaging-1-basic-distributed-architecture.html