День 1039. Асинхронный Обмен Сообщениями. Окончание 1. Основы распределённой архитектуры 2. Перманентные очереди Примеры устойчивых очередей 3. Бэкенд-сервисы 4. Получение результатов 5. Прочее Здесь собраны различные прочие соображения по поводу асинхронного обмена сообщениями. Очереди мёртвых сообщений При проектировании системы вам необходимо решить, как обрабатывать сообщения очереди, которые не могут быть обработаны. Обычно делают какую-то «очередь недоставленных сообщений» для хранения этих «мёртвых» сообщений и настраивают оповещения разработчиков для этой очереди. Многие облачные очереди автоматически сделают это за вас. Только не забудьте настроить оповещения! Управление версиями Сообщения в очереди можно считать своего рода объектами передачи данных (DTO). Они действуют как мост между двумя процессами: HTTP-приложением и бэкенд-обработчиком. Как и остальная система, DTO со временем будут меняться, и к этому лучше быть готовым. Возможно указывать версии в самом имени очереди, либо в самих DTO. Версии вводятся для того, чтобы старый потребитель не мог обрабатывать новые типы сообщении в очереди. Сервисы разных провайдеров Вполне возможно масштабировать, например, функции Azure на основе RabbitMQ или подключить бэкенд-сервис в Docker, размещённый в Google Cloud, к очереди Amazon SQS. Хотя иногда при этом возникают дополнительные расходы, а иногда вам нужно написать плагин, чтобы ваш бэкенд-сервис использовал ваш тип очереди для масштабирования. Готовые решения Существуют готовые комплексные решения для асинхронного обмена сообщениями. Примерами являются Hangfire (.NET) и Delayed Job (Ruby). Их универсальность означает, что их легче настроить, но и то, что они менее гибкие. То, что создали разработчики этого решения, может сильно отличаться от того, что нужно вашему приложению. В частности, вам необходимо изучить: 1) Используется ли перманентная очередь? В противном случае лучше даже не рассматривать это. Всё, что использует Redis в его конфигурации по умолчанию, не должно использоваться. Следует настроить Redis на перманентное хранение в файле только для добавления (Append Only File) с синхронизацией этого файла для каждой команды. Hangfire и Delayed Job используют базу данных для очереди, что нормально (при условии, что у вас уже есть база данных), но не идеально (теперь ваш сервер базы данных должен иметь дело с сообщениями очереди, помимо обычных данных). 2) Как сериализуются сообщения: будет ли сериализация обратно совместима при обновлении библиотеки? До недавнего времени Hangfire не поддерживал скользящие обновления из-за способа сериализации заданий. Приложения должны были полностью отключаться перед развёртыванием обновления Hangfire, а если требовался откат, они также должны были полностью отключаться перед выполнением отката. 3) Как сериализуются задания: как может изменяться код? Например, .NET довольно специфичен в сериализации делегатов методов, и даже добавление параметра (со значением по умолчанию) может вызвать сбой. Любое подобное изменение потребует двух обновлений вместо одного: первое добавит новую перегрузку, а после завершения всех старых заданий можно развернуть второе обновление, чтобы удалить старую перегрузку. 4) Как обрабатываются ошибки? Большинство универсальных решений автоматически повторяют попытку. По умолчанию Hangfire оставляет эти сообщения в состоянии «failed» (и вы должны создать какое-то уведомление об этом), тогда как Delayed Job удаляет их! Просто будьте бдительны. Не добавляйте бездумно готовое решение в свою архитектуру. Хорошо продуманная и правильная реализация асинхронного обмена сообщениями почти всегда является лучшим вариантом. Источник: blog.stephencleary.com/2021/02…ons.html