День 1037. Асинхронный Обмен Сообщениями. Продолжение 1. Основы распределённой архитектуры 2. Перманентные очереди Примеры перманентных очередей 3. Бэкенд-сервисы Назначение фонового сервиса - обработка сообщений очереди. Это другая сторона «трубы». HTTP-приложение - это производитель, помещающий сообщения в очередь, а фоновый сервис - потребитель, извлекающий сообщения из очереди и обрабатывающий их. Обычно рекомендуется, чтобы фоновый сервис был независимым от HTTP-приложения, но это не обязательно. Причины для отдельного сервиса: - Независимое масштабирование: приложение масштабируется на основе HTTP-запросов, а фоновый сервис на основе количества сообщений в очереди. - Отдельный сервис требует использования внешней перманентной очереди. Если сервис и приложением находятся в одном процессе, не очевидно, что очередь в памяти является неподходящим решением. И в будущем команда, сопровождающая систему, может «оптимизировать» реализацию очереди, поместив её в память. - Отдельный сервис полностью состоит из кода внешнего запроса, поэтому необходимо соблюдать особую осторожность, чтобы обеспечить надлежащее завершение работы HTTP-приложения, если сервис является его частью. Идемпотентность Операция является идемпотентной, если её можно применять несколько раз и каждый раз получать один и тот же результат. Другими словами, как только была применена идемпотентная операция, будущие применения этой же операции игнорируются. Это необходимо, т.к. перманентные очереди доставляют сообщения как минимум один раз. Т.е. фоновый сервис может получить одно и то же сообщение более одного раза. В идеале код обработки дубликата должен приводить к пустой операции (noop). Иногда это означает захват дополнительной информации о «состоянии» системы во время постановки сообщения в очередь и включение этого состояния в сообщения. Когда идемпотентность невозможна, можно использовать дедупликацию: явно проверять наличие повторяющихся сообщений в течение разумного периода времени. Примеры бэкенд-сервисов Основные решения - облачные, в частности, Functions as a Service (FaaS). Основные облачные провайдеры имеют встроенную поддержку для объединения своих перманентных очередей с FaaS: Azure Functions, AWS Lambdas или Google Cloud Functions. Поддержка включает в себя логику масштабирования: каждый облачный провайдер будет автоматически масштабировать FaaS-потребителей на основе объёма сообщений в очереди. Для локальных решений естественным подходом является служба Win32 (в Windows) или демон в Linux. Эти фоновые службы работают всё время, пока серверная машина включена, независимо от того, вошел ли пользователь в систему, и не допускают прямого взаимодействия с пользователем. Другое решение - консольное приложение в контейнере Docker, который можно развернуть локально или в облаке. Этот подход имеет лучшую поддержку горизонтального масштабирования. Наименее рекомендуемое решение - бэкенд-сервис как часть HTTP-приложения. Некоторые выбирают этот вариант, несмотря на недостатки. Заметьте, что хост должен быть уведомлён о фоновой работе, иначе она может быть потеряна. Кроме того, любые «вышестоящие» системы, такие как HTTP-прокси, балансировщики нагрузки и сценарии развертывания, могут потребовать изменений, чтобы они также знали о нестандартных правилах завершения работы. Замечание: в ASP.NET Core используйте IHostedService или IHostApplicationLifetime для обнаружения и блокировки завершения работы приложения HTTP. BackgroundService также можно использовать, но имейте в виду, что работа может быть потеряна, если время завершения работы хоста истечёт. В ASP.NET Framework используйте HostingEnvironment.QueueBackgroundWorkItem или IRegisteredObject. Продолжение следует… Источник: blog.stephencleary.com/2021/01…sor.html