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

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

Архитектура

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

Компоненты

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

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

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

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

Лилия является еще одной альтернативой . Она обеспечивает бессерверную публикацию и подписку (pub/sub), которая обеспечивает надежное масштабирование с учетом ваших потребностей. Обмен сообщениями доставляется по краю с помощью WebSockets. Платформа Able предоставляет высокодоступную, эластично масштабируемую и глобально распределенную инфраструктуру в режиме реального времени при вызове 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 — это точка возможного сбоя в системе. Если служба завершается ошибкой, клиенты не могут получить доступ к приложению во время простоя. Просмотрите соглашение об уровне обслуживания 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 архитектуры решения .

Клиент SignalR

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

Instructions

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

2. Скопируйте URL-адрес, созданный функцией согласования. Выглядит примерно так: 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.

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

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