Шаблоны асинхронного обмена сообщениями и высокий уровень доступности

  • Статья

Асинхронный обмен сообщениями может осуществляться различными способами. Служебная шина Azure поддерживает асинхронность за счет механизма сохранения и пересылки. Этот механизм оперирует очередями, разделами и подписками. В обычном (синхронном) режиме сообщения отправляются в очереди и разделы, а поступают из очередей и подписок. Для создаваемых приложений важно, чтобы эти сущности всегда были доступны. На случай, если работоспособность сущности изменится по какой-либо причине, нужно иметь возможность предоставить доступ к сущности, которая будет работать в ограниченном режиме, но все же удовлетворять большинство потребностей.

Для реализации различных сценариев связи в приложениях обычно используются шаблоны асинхронного обмена сообщениями. Вы можете создавать приложения, в которых клиенты смогут отправлять сообщения в службы, даже если они не запущены. Для приложений, которые испытывают пики обмена данными, очередь может помочь выровнать нагрузку , предоставив место для буферизации обмена данными. Наконец, для распределения сообщений между несколькими компьютерами вы можете воспользоваться простым, но эффективным балансировщиком нагрузки.

Чтобы обеспечить доступность всех этих сущностей, следует предусмотреть ситуации, в которых эти сущности могут стать недоступными для устойчивой системы обмена сообщениями. Как правило, мы видим, что сущность становится недоступной для приложений, которые мы пишем следующими способами:

  • невозможность отправки сообщений;
  • невозможность получения сообщений;
  • невозможность управления сущностями (создание, извлечение, обновление или удаление);
  • невозможность связи со службой.

Для каждого из указанных типов ошибок существуют режимы, которые обеспечат дальнейшую работу приложения с определенным уровнем ограничений. Например, если система может отправлять сообщения, но не может их получать, вы по-прежнему будете получать заказы от клиентов, но не сможете их обрабатывать. В этой статье рассматриваются возможные проблемы и способы их устранения. В служебной шине реализовано несколько способов устранения рисков, которые мы рекомендуем использовать. В этой статье также рассматриваются правила использования этих способов.

Надежность служебной шины

Существует несколько способов решения проблем с сообщениями и сущностями, а также рекомендации по надлежащему использованию этих способов. Для понимания этих рекомендаций необходимо сначала определить участки служебной шины, которые потенциально подвержены сбоям. Благодаря архитектуре систем Azure все эти проблемы обычно имеют краткосрочный характер. В общих чертах можно выделить следующие причины недоступности.

  • Регулирование из внешней системы, от которой зависит служебная шина. Регулирование возникает вследствие взаимодействия с ресурсами хранилища и вычислительными ресурсами.
  • Проблема в системе, от которой зависит служебная шина. Например, могут возникнуть ошибки в определенной части хранилища.
  • Сбой служебной шины в единой подсистеме. В этом случае вычислительный узел может оказаться в несогласованном состоянии и потребовать перезапуска. В результате нагрузка сущностей, обслуживаемых этим узлом, будет перераспределена на другие узлы. Это, в свою очередь, может стать причиной кратковременного замедления обработки сообщений.
  • Сбой служебной шины в центре обработки данных Azure. Это пример "разрушительного сбоя", в результате которого система может быть недоступна в течение длительного времени — от нескольких минут до нескольких часов.

Примечание

Термин хранилище может означать как хранилище Azure, так и SQL Azure.

В служебной шине предусмотрен ряд способов устранения рисков, связанных с этими проблемами. В следующих разделах рассматривается каждая из этих проблем и способы их устранения.

Регулирование

Регулирование в служебной шине позволяет управлять скоростью обмена сообщениями "кооперативным" способом. Каждый отдельный узел служебной шины хранит множество сущностей. Для каждой из этих сущностей требуются ресурсы центрального процессора, памяти, хранилища и др. Если использование какого-либо из ресурсов превысит установленные ограничения, служебная шина может отклонить запрос. Вызывающий объект получит исключение занятости сервера и повторит попытку через 10 секунд.

Для устранения этой проблемы код должен прочитать ошибку и не допустить повторной отправки сообщения по крайней мере в течение 10 секунд. Так как ошибка может возникать в разных элементах клиентского приложения, ожидается, что каждый элемент независимо выполняет логику повторных попыток. Код может снизить вероятность регулирования, включив секционирование в пространстве имен, очереди или разделе.

Дополнительные сведения о том, как код приложения должен обрабатывать проблемы регулирования, см. в документации по шаблону регулирования.

Проблема с зависимостью в Azure

В любом из компонентов Azure время от времени могут возникать проблемы, связанные с работой службы. Например, обновление системы, которая используется служебной шиной, может привести к временному снижению производительности этой системы. Чтобы избежать таких проблем, служебная шина регулярно проверяет и реализует способы устранения рисков. Однако при применении этих способов возможны побочные эффекты. Например, для устранения временных проблем с хранилищем в служебной шине реализована система, которая обеспечивает согласованное выполнение операций отправки сообщений. При устранении рисков отправленное сообщение может появиться в соответствующей очереди или подписке через 15 минут, после чего оно станет доступным для получения. Вообще говоря, эта проблема не затронет большинство сущностей. Тем не менее, в зависимости от количества сущностей в служебной шине Azure, такое устранение рисков иногда необходимо для некоторых клиентов служебной шины.

Сбой служебной шины в единой подсистеме

В любом приложении возможны обстоятельства, которые могут привести к несогласованности внутреннего компонента служебной шины. Когда служебная шина обнаруживает это, она собирает из приложения данные, которые помогут диагностировать проблему. После сбора данных приложение перезапускается, чтобы вернуться в согласованное состояние. Этот происходит довольно быстро, но сущность может стать недоступной. Обычно простой длится недолго, но иногда может достигать нескольких минут.

В таких случаях клиентское приложение инициирует исключение времени ожидания или исключение обмена сообщениями. Служебная шина содержит средство для устранения этой проблемы, которое реализовано в виде автоматизированной логики повтора для клиента. Если период повторных попыток исчерпан, а сообщение все еще не доставлено, можно использовать другие возможности, описанные в статье Рекомендации по изолированию приложений от простоев и аварий служебной шины.

Дальнейшие действия

Вы ознакомились с основами асинхронного обмена сообщениями в служебной шине. Дополнительные сведения см. в статье Рекомендации по изолированию приложений от простоев и аварий служебной шины.