Укажите, что использовать — сообщения или события.

Завершено

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

Чтобы выбрать подходящую технологию Azure, необходимо понимать, какими именно данными обмениваются компоненты приложения. Для каждого типа данных можно выбрать свою технологию Azure.

В первую очередь следует понимать, отправляются ли сообщения или события. Эти знания помогают выбрать соответствующую службу Azure для использования.

Стратегии коммуникации в Azure (API)

Что такое сообщение?

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

  • Сообщение содержит необработанные данные, созданные одним компонентом и потребляемые другим компонентом.
  • Сообщение содержит сами данные, а не просто ссылку на них.
  • Отправляющий компонент предполагает, что компонент-получатель будет обрабатывать содержимое сообщения определенным образом. Общая целостность системы может зависеть от отправителя и получателя, выполняя определенное задание.

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

Что такое событие?

События являются более легкими, чем сообщения, и чаще всего используются для трансляции. Компоненты, отправляющие события, называются издателями, а принимающие их — подписчиками.

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

События обладают указанными ниже характеристиками:

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

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

Это пример дискретного события.

Выбор сообщений или событий

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

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

Для каждого взаимодействия необходимо ответить на вопрос: предполагает ли отправляющий компонент, что получатель обработает переданное содержимое определенным образом?

Если ответ утвердительный, используйте сообщения. Если ответ не указан, возможно, вы сможете использовать события.

Понимание того, как компоненты должны взаимодействовать, помогает выбрать способ взаимодействия компонентов. Начнем с сообщений.

Проверьте свои знания

1.

Предположим, у вас есть распределенное приложение с веб-службой для проверки подлинности пользователей. Когда пользователь входит в систему, веб-служба уведомляет все клиентские приложения, чтобы они показывали, что пользователь в сети. Уведомление о входе — это пример сообщения или события?

2.

Предположим, у вас есть распределенное приложение с веб-службой, которая позволяет пользователям управлять учетной записью. Пользователи могут регистрироваться, редактировать свой профиль и удалять свою учетную запись. Когда пользователь удаляет свою учетную запись, веб-служба уведомляет уровень данных, чтобы данные пользователя были удалены из базы данных. Уведомление об удалении учетной записи — это пример сообщения или события?