Создавая несколько приложений, которые должны
взаимодействовать между собой, стоит обратить внимание на службу очереди сообщений. Они
предлагают ряд полезных -- и бесплатных -- функций, среди которых:
- гарантированная доставка сообщений;
- маршрутизация;
- регулирование пропускной способности.
Такие инструменты, как серверы ActiveMQ, RabbitMQ, MSMQ, JMS
проверены временем и предназначены для надежного выполнения этих требований. У
меня позитивный опыт использования данных инструментов для так называемых
"happy paths" (максимально гладких вариантов). А вот в случае с
"unhappy paths", независимо от инструментов, бывает достаточно тяжело
спроектировать механизм восстановления после отказа.
Вот что нужно принять во внимание, разрабатывая решение с
помощью очередей:
Скорость обработки
Очереди по сути являются системой producer/consumer
(производитель/потребитель) или pub/sub (вещание/подписка). То есть,
медленный темп потребления приводит к скоплению сообщений.
В высокопроизводительных системах обработки транзакций
буквально за несколько часов способны скопиться миллионы записей -- заставляя
производителя снизить скорость отправки сообщений. Проектируя решение, следует
измерить и протестировать скорость обработки. Избежать таких проблем поможет
нагрузочное тестирование. После релиза их устранение, как правило, требует
дополнительных усилий.
Пути ошибки
Даже если потребитель на одном уровне с производителем,
существует вероятность того, что из-за ошибок сообщения не будут обработаны.
Если ошибка произошла в сети или вне системы, исправить ее может обычная
повторная доставка из очереди.
Но в реальности, чаще всего, всему виной дефект приложения.
Сперва их нужно устранить, а затем выполнить повторную передачу сообщения.
Решение необходимо проектировать с учетом влияния/разрешения ошибок.
Автоматизированный мониторинг
Автоматизированный мониторинг играет для любой очереди в
промышленной системе решающую роль. Без мониторинга очередь рискует быть
переполненной непотребляемыми сообщениями.
Вмешательство человека
Если потребитель не может обработать сообщение, вероятней
всего потребуется вмешательство человека, чтобы выполнить/отменить планируемое
действие. Например, если ваше приложение обработки платежей отправляет
сообщение, а ответственному за доставку "процессору" не удается его
обработать, для выполнения пересылки или отмены команды потребуется
вмешательство человека. Разрабатывая решение, следует определить такие
пограничные случаи.
Развертывания
В основном очереди хорошо справляются с хранением
необработанных сообщений для отключенных потребителей. Однако, если между
развертываниями большое время простоя, границы очереди могут расшириться.
Комментариев нет:
Отправить комментарий