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

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

Архитектура

Скачайте файл Visio этой архитектуры.

Компоненты

• Служебная шина Azure — это высоконадежная облачная служба обмена сообщениями между приложениями и службами, даже если один или несколько находятся в автономном режиме.
• Служба Azure SignalR упрощает добавление в веб-приложение сообщений в режиме реального времени.
• Функции Azure — это управляемая событиями бессерверная вычислительная платформа, которая также может решать сложные задачи оркестрации.

Альтернативные варианты

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

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

Ably является еще одной альтернативой. Она обеспечивает бессерверную публикацию и подписку (pub/sub) обмена сообщениями, которая надежно масштабируется в соответствии с вашими потребностями. Сообщения доставляются на границе с помощью WebSocket. Платформа Ably предоставляет высокодоступную, эластично масштабируемую и глобально распределенную инфраструктуру в режиме реального времени по вызову API.

Хотя Pusher, PubNub и Ably являются наиболее распространенными платформами для обмена сообщениями в режиме реального времени, в этом сценарии вы будете делать все в Azure. Мы рекомендуем Использовать SignalR в качестве платформы перехода, так как она обеспечивает двунаправленную связь между сервером и клиентом. Это также инструмент с открытым кодом с 7,9 тысячи звезд GitHub и 2,2 тысячи вилок GitHub.

Дополнительные сведения см. в репозитории с открытым кодом SignalR на сайте GitHub.

Сведения о сценарии

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

Вы будете использовать службу SignalR, настроенную в бессерверном режиме, для интеграции с приложением Функции Azure, активируемой служебной шиной, и все это с помощью .NET Core.

Потенциальные варианты использования

Эти другие варианты использования имеют аналогичные конструктивные шаблоны:

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

Рекомендации

Эти рекомендации реализуют основные принципы Azure Well-Architected Framework, которая представляет собой набор руководящих принципов, которые можно использовать для повышения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

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

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

Если вы помните две предыдущие функции платформы SignalR, вам будет легко быстро приступить к работе.

Доступность, масштабируемость и безопасность

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

Региональные пары

Каждый регион Azure образует пару с другим регионом в пределах одной географической территории. В общем случае выбирайте регионы из одной региональной пары (например, восточная часть США 2, центральная часть США). Преимущества:

• При большом сбое приоритетом является восстановление по крайней мере одного региона из каждой пары.
• запланированные обновления системы Azure распространяются в парах регионов последовательно во избежание возможных простоев;
• во многих случаях пары находятся в пределах одной географической территории в соответствии с требованиями к местонахождению данных.
• Однако убедитесь, что оба региона поддерживают все службы Azure, необходимые для вашего приложения. См. сведения о доступности служб по регионам. Дополнительные сведения о парах регионов см. в статье Непрерывность бизнес-процессов и аварийное восстановление в службах BizTalk: в парах регионов Azure.

Azure Front Door

Скачайте файл Visio этой архитектуры.

Azure Front Door — это масштабируемая и безопасная точка входа для быстрого предоставления глобальных приложений. При использовании маршрутизации по приоритету она автоматически выполняет отработку отказа, если основной регион становится недоступным. Архитектура с несколькими регионами может обеспечить более высокий уровень доступности, чем развертывание в одном регионе. Если региональный сбой влияет на основной регион, можно использовать Front Door для отработки отказа в дополнительный регион.

Эта архитектура также помогает при сбое отдельной подсистемы или решения. Останавливайте атаки сетевого уровня и уровня приложений в пограничной зоне с помощью брандмауэра веб-приложения и Защиты от атак DDoS. Усиление защиты службы с помощью наборов правил, управляемых Корпорацией Майкрософт, и создание собственных правил для настраиваемой защиты приложения.

Front Door — это точка возможного сбоя в системе. В случае сбоя службы клиенты не смогут получить доступ к приложению во время простоя. Изучите соглашение об уровне обслуживания (SLA) Front Door и определите, соответствует ли использование Front Door вашим бизнес-требованиям для обеспечения высокой доступности. Если это не так, рекомендуем добавить резервное решение для управления трафиком. Если в службе Front Door произошел сбой, измените записи CNAME в службе доменных имен, чтобы они указывали на резервную службу управления трафиком. Этот шаг необходимо выполнить вручную, и приложение будет недоступно до распространения изменений DNS.

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

Предположим, что в вашем бизнесе есть 1000 заказов в день, и все они должны совместно использовать данные о местоположении. Предполагаемое использование Azure для развертывания этого сценария будет близко к 192 долл. США в месяц на основе цен на дату публикации.

Развертывание этого сценария

Разработка функций Azure

Бессерверное приложение в режиме реального времени, созданное с помощью Функции Azure и Служба Azure SignalR, обычно требует двух Функции Azure:

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

SignalRFunctionApp

SignalRFunctionApp — это приложение-функция, которое создает экземпляр Функции Azure с триггером служебной шины с SignalR.

Negotiate.cs

Эту функцию активирует HTTP-запрос. Он используется клиентскими приложениями для получения маркера из службы SignalR, который клиенты могут использовать для подписки на концентратор. Эта функция должна иметь имя negotiate. Дополнительные сведения см. в статье Функции Azure разработка и настройка с помощью Служба Azure SignalR.

Message.cs

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

Instructions

Перед началом работы

• Убедитесь, что в Azure подготовлена очередь служебной шины.
• Убедитесь, что служба SignalR подготовлена в бессерверном режиме в Azure.

1. Введите строки подключения (служебная шина и SignalR) в файле local.settings.json .
2. Введите URL-адрес клиентского приложения (клиент SignalR) в CORS (общий доступ к ресурсам между источниками). Последний синтаксис см. в разделе Функции Azure разработки и настройки с помощью Служба Azure SignalR.
3. Введите имя очереди служебной шины в триггер служебной шины в файле Message.cs .

Теперь давайте настроим клиентское приложение для тестирования. Сначала получите примеры источников на странице GitHub solution-architectures .

Клиент SignalR

Это простое веб-приложение .NET Core для подписки на концентратор, созданный SignalRFunctionApp. В нем отображаются сообщения, полученные в очереди служебной шины в режиме реального времени. Хотя вы можете использовать SignalRFunctionApp для работы с мобильным клиентом, давайте воспользуемся веб-клиентом для этого сценария в этом репозитории.

Инструкции

1. Убедитесь, что SignalRFunctionApp запущен.

2. Скопируйте URL-адрес, созданный функцией negotiate. Он выглядит примерно так: http://localhost:7071/api/.

3. Вставьте URL-адрес в файлchat.js внутри signalR.HubConnectionBuilder().withUrl("YOUR_URL_HERE").build();.

4. Запустите приложение.

   Состояние подключается, когда веб-клиент успешно подписывается на концентратор SignalR.

SendToQueue.js

Этот скрипт node.js отправляет сообщение в служебную шину, чтобы вы могли протестировать развертывание, которое вы только что завершили.

Instructions

1. Установите модуль узла Служебной шины Azure (@azure/service-bus).

2. Введите свои строки подключения и имя очереди в скрипте.

3. Выполните скрипт.

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

Этот сценарий можно использовать в рабочей среде. Однако убедитесь, что службы Azure настроены на масштабирование. Например, для Служебной шины Azure следует выбрать план "Стандартный" или "Премиум".

Вы можете развернуть код в Функциях Azure прямо из Visual Studio. Чтобы узнать, как опубликовать код в Функции Azure из Visual Studio, ознакомьтесь с руководством по разработке программного обеспечения.

Узнайте, как работать с привязками Служебная шина Azure в Функции Azure. Функции Azure поддерживает триггерные и выходные привязки для очередей и разделов служебной шины.

Узнайте, как выполнять проверку подлинности и отправлять сообщения в режиме реального времени клиентам, подключенным к Служба Azure SignalR, с помощью привязок Служба SignalR в Функции Azure. Служба "Функции Azure" поддерживает входные и выходные привязки для службы SignalR.

Связанные ресурсы

• Пакетная обработка большого объема транзакций
• Подсистема обмена сообщениями промежуточного центра динамической публикации и подписки
• Бессерверная обработка событий
• Приложение для рабочих процессов блокчейна
• Автоматизация процессов в облаке на основе событий