Используйте очередь, которая выступает в качестве буфера между задачей и службой, которая вызывается, чтобы сглаживать временные тяжелые нагрузки, которые могут привести к сбою службы или времени ожидания задачи. Это может помочь свести к минимуму влияние пиков спроса на доступность и скорость реагирования как для задачи, так и для службы.
Контекст и проблема
Многие решения в облаке используют выполняемые задачи, которые вызывают службы. В этой среде, если служба подвергается кратковременным всплескам нагрузки, то могут возникать проблемы с производительностью или надежностью.
Служба может быть частью того же решения, что и задачи, которые ее используют. Или это может быть сторонняя служба, предоставляющая доступ к часто используемым ресурсам, таким как кэш или служба хранилища. Если одна служба используется рядом задач, выполняемых одновременно, то может быть сложно предсказать число запросов к службе в любое время.
В службе могут возникать всплески нагрузки спроса, которые приводят к ее перегрузке и неспособности своевременно отвечать на запросы. Наполнение службы большим числом одновременных запросов также может приводить к сбоям в работе службы, если она не может справиться с конфликтом, вызываемым этими запросами.
Решение
Выполните рефакторинг решения и создайте очередь между задачей и службой. Задача и служба выполняются асинхронно. Задача отправляет сообщение, содержащее данные, необходимые службе для очереди. Очередь работает как буфер, сохраняя сообщение, пока оно не будет извлечено службой. Служба извлекает сообщения из очереди и обрабатывает их. Запросы от ряда задач, которые могут создаваться с крайне изменчивой скоростью, можно передавать в службу с помощью той же очереди сообщений. На этом рисунке показано использование очереди для балансировки нагрузки в службе.
Очередь отделяет задачи из службы, а служба может обрабатывать сообщения в удобном для нее темпе, независимо от числа запросов от параллельных задач. Кроме того, отсутствует задержка, связанная с задачей, если служба недоступна в тот момент, когда она отправляет сообщение в очередь.
Такой подход обеспечивает следующие преимущества:
Он помогает добиться максимальной доступности, так как задержки, возникающие в службах, не будут оказывать немедленное и прямое влияние на приложение, которое может по-прежнему отправлять сообщения в очередь, даже если служба в данный момент недоступна или не обрабатывает сообщения.
Он позволяет добиться максимальной масштабируемости, так как для удовлетворения спроса можно изменять как количество очередей, так и количество служб.
Он помогает контролировать затраты, так как число развернутых экземпляров службы должно быть достаточным для обработки средней нагрузки, а не пиковой нагрузки.
Некоторые службы применяют регулирование количества запросов, когда спрос достигает порогового значения, за которым может произойти сбой системы. Регулирование количества запросов может сократить число доступных функциональных возможностей. С помощью этих служб можно реализовать балансировку нагрузки, чтобы пороговое значение не достигалось.
Проблемы и рекомендации
При принятии решения о реализации этого шаблона необходимо учитывать следующие моменты.
- Во избежание перегрузки целевого ресурса необходимо реализовать логику приложения, контролирующую скорость, с которой службы обрабатывают сообщения. Избегайте передачи пиковых нагрузок спроса в следующую стадию системы. Протестируйте систему под нагрузкой, чтобы убедиться, что она обеспечивает необходимую балансировку, а также настройте количество очередей и экземпляров службы, которые обрабатывают сообщения, для достижения этой цели.
- Очереди сообщений представляют собой механизм односторонней связи. Если задача ожидает ответа от службы, то может потребоваться реализовать механизм, который служба может использовать для отправки ответа. Дополнительные сведения см. в руководстве по асинхронному обмену сообщениями.
- Будьте осторожны, если вы применяете автомасштабирование к службам, которые прослушивают запросы в очереди. Это может вызвать дополнительные конфликты для любых ресурсов, совместно используемых этими службами, и снизить эффективность использования очереди при балансировке нагрузки.
- В зависимости от нагрузки службы вы можете столкнуться с ситуацией, когда вы действительно всегда следя за ней, где система всегда в очереди больше запросов, чем вы обрабатываете. Необходимо учитывать вариативность входящего трафика в приложение.
- Шаблон может потерять сведения в зависимости от сохраняемости очереди. Если очередь завершает работу или удаляет сведения (из-за системных ограничений) есть вероятность того, что у вас нет гарантированной доставки. Поведение очереди и системных ограничений необходимо учитывать в зависимости от потребностей решения.
Когда следует использовать этот шаблон
Этот шаблон полезен для любого приложения, использующего службы, которые подвержены перегрузкам.
Этот шаблон не будет полезен, если приложение ожидает ответа от службы с минимальной задержкой.
Проектирование рабочей нагрузки
Архитектор должен оценить, как шаблон выравнивания нагрузки на основе очередей можно использовать в проектировании рабочей нагрузки для решения задач и принципов, описанных в основных принципах платформы Azure Well-Architected Framework. Например:
| Принцип | Как этот шаблон поддерживает цели основных компонентов |
|---|---|
| Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя. | Подход, описанный в этом шаблоне, может обеспечить устойчивость к внезапным всплескам спроса, разрежив прибытие задач от их обработки. Он также может изолировать неисправности в обработке очередей, чтобы они не влияли на потребление. - Масштабирование RE:06 - Задания RE:07 Фоновые задания |
| Оптимизация затрат ориентирована на поддержание и улучшение рентабельности инвестиций рабочей нагрузки. | Так как обработка нагрузки отделяется от запроса или приема задач, этот подход можно использовать для уменьшения необходимости перепроверки ресурсов для обработки пиковой нагрузки. - Затраты на масштабирование CO:12 |
| Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. | Этот подход позволяет намеренно разрабатывать производительность пропускной способности, так как потребление запросов не требует корреляции с скоростью обработки. - Pe:05 Масштабирование и секционирование |
Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.
Пример
Веб-приложение записывает данные во внешнее хранилище данных. Если большое число экземпляров веб-приложения выполняются одновременно, хранилище данных может оказаться неспособным отвечать на запросы достаточно быстро. Это приведет к истечению времени ожидания у запросов, регулированию запросов или сбоям при их обработке. На схеме ниже показана служба, перегруженная большим числом параллельных запросов от экземпляров приложения.
Чтобы устранить эту проблему, можно использовать очередь для балансировки нагрузки между экземплярами приложения и хранилищем данных. Приложение Функций Azure считывает сообщения из очереди и выполняет запросы чтения и записи к хранилищу данных. Логика приложения в приложении-функции может контролировать скорость, с которой это приложение передает запросы в хранилище данных, чтобы предотвратить перегрузку хранилища. (В противном случае приложение-функция просто перенесет эту проблему в серверную часть.)
Следующие шаги
При реализации этого шаблона следует принять во внимание следующие рекомендации:
Руководство по асинхронному обмену сообщениями. Очереди сообщений по своей сути асинхронны. Может потребоваться изменить логику приложения в задаче, если ее адаптировали для использования очереди сообщений вместо непосредственного взаимодействия со службой. Аналогичным образом может потребоваться выполнить рефакторинг службы, чтобы принимались запросы из очереди сообщений. Также можно реализовать прокси-службу, как описано в примере.
Сравнение трех служб обмена сообщениями Azure: Сетка событий, Центры событий и Служебная шина. Сведения о выборе механизма обмена сообщениями и организации очереди в приложениях Azure.
Асинхронное взаимодействие на основе сообщений.
Связанные ресурсы
- Стиль архитектуры веб-очередей и рабочей роли. Веб-интерфейс и рабочая роль реализованы без отслеживания состояния. Сведения о состоянии сеанса можно сохранять в распределенном кэше. Любые длительные задачи выполняются рабочей ролью в асинхронном режиме. Рабочая роль запускается при помещении сообщений в очередь или по расписанию для пакетной обработки.
При реализации этого шаблона могут быть также важны следующие шаблоны:
Шаблон конкурирующих потребителей. Можно запустить несколько экземпляров службы, каждый из которых будет действовать как потребитель сообщений из очереди балансировки нагрузки. Этот подход можно использовать для настройки скорости, с которой сообщения принимаются и передаются в службу.
Шаблон регулирования. Простой способ реализовать регулирование количества запросов с помощью службы — это использовать балансировку нагрузки на основе очередей и перенаправлять все запросы к службе через очередь сообщений. Служба может обрабатывать запросы со скоростью, которая гарантирует, что ресурсы, необходимые для службы, не будут исчерпаны. При этом также сокращается число конфликтов, которые могут возникнуть.