Федерация для нескольких сайтов и нескольких регионов
Для многих сложных решений требуется, чтобы одни и те же потоки событий были можно было использовать в нескольких местах, или чтобы потоки событий можно было собирать в нескольких расположениях, а затем консолидировать их в определенном месте для использования. Также часто возникает необходимость в обогащении или сокращении потоков событий или преобразований форматов событий, в рамках одного региона и решения.
Практически это означает, что решение будет поддерживать несколько Центров событий Azure, часто в разных регионах и пространствах имен Центров событий Azure, а затем реплицировать события между ними. Можно также обмениваться событиями с источниками и целевыми объектами, такими как служебная шина Azure, Центр Интернета вещей Azureили Apache Kafka.
Обслуживание нескольких активных Центров событий Azure в разных регионах позволяет клиентам выбирать и переключаться между ними, если их содержимое объединено, что делает общую систему более устойчивой к проблемам доступности по регионам.
В главе "Федерация" приводятся шаблоны федерации и способы их реализации с помощью бессерверных функций Azure Stream Analytics или сред выполнения Функций Azure с возможностью иметь собственный код преобразования или обогащения непосредственно в пути потока событий.
Шаблоны федерации
Есть много потенциальных причин, по которым может потребоваться переместить события между разными Центрами событий Azure или другими источниками и целями. В этом разделе перечислены наиболее важные шаблоны, а также предоставлены ссылки на более подробные рекомендации по соответствующему шаблону.
- Устойчивость к событиям доступности по регионам
- Оптимизация задержки
- Проверка, сокращение и обогащение
- Интеграция со службами аналитики
- Консолидация и нормализация потоков событий
- Разделение и маршрутизация потоков событий
- Проекции журналов
Устойчивость к событиям доступности по регионам
Хотя максимальная доступность и надежность являются главными операционными приоритетами для Центра событий Azure, тем не менее существует множество вариантов, в которых производитель или потребитель может быть лишен возможности взаимодействия с назначенным ему "основным" Центром событий Azure, когда возникают проблемы с сетью или разрешением имен, или когда объект Центра событий может временно не отвечать или возвращать ошибки.
Такие условия не являются настолько катастрофическими, чтобы полностью отказаться от регионального развертывания, как можно было бы сделать в ситуации аварийного восстановления, но на бизнес-сценарий некоторых приложений вполне могут влиять события доступности, которые длятся не более нескольких минут или даже секунд.
Для таких сценариев есть два базовых шаблона:
- Шаблон репликации предназначен для репликации содержимого основного Центра событий в дополнительный, при котором основной Центр событий обычно используется приложением для создания и использования событий, а дополнительный — как резервный вариант на случай недоступности основного Центра событий. Так как репликация выполняется в одном направлении, от основного центра к дополнительному, переключение поставщиков и потребителей из недоступного основного центра на дополнительный приведет к тому, что старый основной центр больше не будет получать новые события, и, следовательно, перестанет быть актуальным. Поэтому чистая репликация подходит только для односторонних сценариев перехода на другой ресурс. После перехода на другой ресурс старый основной Центр событий больше не используется, и нужно создать новый дополнительный Центр событий в другом целевом регионе.
- Шаблон слияния дополняет шаблон репликации, непрерывно выполняя слияние содержимого двух или более Центров событий Azure. Каждое событие, изначально созданное в одном из Центров событий Azure, включенных в схему, реплицируется в другие Центры событий Azure. При репликации событий в них добавляются заметки, чтобы они потом игнорировались процессом репликации целевого объекта репликации. Результатом использования шаблона слияния становятся два или более Центров событий Azure, которые, в конце концов, будут содержать одинаковый набор событий.
В любом случае содержимое Центров событий Azure не будет идентичным. События от одного производителя, сгруппированные по одному и тому же ключу секции, будут отображаться в том же относительном порядке, в котором они были изначально отправлены, но абсолютный порядок событий может отличаться. Это особенно относится к сценариям, в которых количество секций исходного и целевого Центров событий Azure отличается, что желательно для некоторых из описанных здесь расширенных шаблонов. Разделитель или маршрутизатор может получить срез из большого Центра событий с сотнями секций и перенаправить их в меньший Центр событий с несколькими секциями, более подходящий для обработки подмножества с ограниченными ресурсами обработки. И наоборот, консолидация позволяет собрать данные из нескольких небольших Центров событий Azure в один большой с большим количеством секций, чтобы получить больше ресурсов для пропускной способности и вычислений.
Для хранения событий вместе используется ключ секции, а не идентификатор исходной секции. Дополнительные сведения о приоритетах и способах аварийного перехода с одного Центра событий на другой без использования единой области смещения потоков приводятся в описании шаблона репликации.
Руководство.
Оптимизация задержки
Потоки событий записываются один раз производителями, но могут быть прочитаны любое количество раз потребителями событий. Для сценариев, где поток событий в регионе совместно используется несколькими потребителями и должен быть постоянно доступен во время обработки аналитики, находящейся в другом регионе, или при наличии всех требований, которые могут привести к замедлению работы одновременных потребителей, может оказаться полезным разместить копию потока событий рядом с обработчиком аналитики, чтобы уменьшить задержку обмена данными.
Репликация предпочтительнее, чем использование событий удаленно из разных регионов, особенно в тех случаях, когда регионы находятся далеко друг от друга, например Европа и Австралия, которые практически географические антиподы, поэтому сетевые задержки могут легко превысить 250 мс для любого кругового пути. Скорость света увеличить невозможно, но можно уменьшить число круговых путей с высокой задержкой при взаимодействии с данными.
Руководство.
Проверка, сокращение и обогащение
Потоки событий могут отправляться в Центр событий клиентами, которые являются внешними для вашего решения. Для таких потоков событий может потребоваться, чтобы события, отправленные извне, проверялись на соответствие заданной схеме, а несоответствующие ей события удалялись.
В сценариях, где клиенты имеют ограниченную пропускную способность, так как это происходит во многих сценариях "Интернета вещей" с измеряемой пропускной способностью, или когда события изначально отправляются по сетям без IP-адресов с ограниченными размерами пакетов, события могут быть дополнены ссылочными данными, чтобы обработчики событий, находящиеся ниже, могли использовать дополнительный контекст.
В других случаях, особенно при консолидации потоков, можно уменьшить сложность или объем данных события, опустив некоторые детали.
Любая из этих операций может выполняться в рамках репликации, консолидации или слияния потоков.
Руководство.
Интеграция со службами аналитики
Некоторые облачные службы аналитики Azure, такие как Azure Stream Analytics или Azure Synapse, лучше работают с потоковыми или предварительными пакетными данными из Центров событий Azure, а Центры событий Azure также обеспечивают интеграцию с несколькими пакетами аналитики с открытым кодом, такими как Apache Samza, Apache Flink, Apache Spark и Apache Storm.
Если решение в основном использует служебную шину Microsoft Azure или Сетку событий Azure, эти события можно легко сделать доступными для таких систем аналитики, а также для архивации с помощью функции "Сбор" Центров событий Azure, передавая события в Центр событий Azure. Сетка событий поддерживает для этого интеграцию с Центром событий, а для служебной шины нужно выполнить инструкции по репликации служебной шины Microsoft Azure.
Azure Stream Analytics интегрируется с Центрами событий напрямую.
Руководство.
Консолидация и нормализация потоков событий
Глобальные решения часто состоят из региональных зон, которые в значительной степени независимы, включая наличие собственных возможностей обработки, но надрегиональные и глобальные перспективы требуют интегрированной перспективы и, следовательно, централизованной консолидации тех же потоков событий, которые оцениваются в соответствующих региональных зонах для локальной перспективы.
Нормализация — это разновидность сценария консолидации, при котором два (или более) входящих потоков событий несут один и тот же вид событий, но с разными структурами или разными кодированиями, и события необходимо перекодировать или преобразовать, прежде чем их можно будет использовать.
Нормализация также может включать криптографические задачи, такие как расшифровка полностью зашифрованных полезных данных и их повторное шифрование с использованием других ключей и алгоритмов для целевой аудитории потребителей.
Руководство.
Разделение и маршрутизация потоков событий
Центры событий Azure иногда используются в сценариях "публикация-подписка", где входящий поток событий значительно превышает емкость служебной шины Microsoft Azure или Сетки событий Azure, обе из которых имеют встроенные возможности распространения и фильтрации "публикация-подписка" и являются предпочтительными для этого шаблона.
Хотя настоящая функция "публикация-подписка" оставляет выбор нужных событий за подписчиками, шаблон разделения имеет возможность сопоставлять события с секциями по предварительно заданной модели распространения, а назначенные потребители затем монопольно извлекают их из своей секции. Центр событий буферизует весь трафик, что позволяет выделить содержимое конкретной секции, на которую приходится часть исходного объема, и реплицировать ее в очередь для надежной обработки потребителями с поддержкой транзакций и конкуренции.
Многие сценарии, в которых Центры событий в основном используются для перемещения событий в пределах приложения внутри региона, имеют несколько случаев, когда события выборы, возможно, только из одной секции, также должны быть доступны в других местах. Этот сценарий аналогичен сценарию разделения, но может использовать масштабируемый маршрутизатор, который считает все сообщения, поступающие в Центр событий, и выберет для маршрутизации всего лишь несколько сообщений, с возможной дифференциацией целевых объектов маршрутизации по метаданным или содержимому событий.
Руководство.
Проекции журналов
В некоторых сценариях требуется доступ к последнему значению, отправленному для любого подпотока события, и, как правило, отличающемуся ключом секции. В Apache Kafka это часто достигается путем включения "сжатия журнала" в разделе, который удаляет все события, кроме последнего, с меткой любого уникального ключа. Сжатие журнала имеет три недостатка:
- Для сжатия требуется непрерывная реорганизация журнала, а это очень дорогостоящая операция для брокера, оптимизированного только для рабочих нагрузок добавления.
- Сжатие — разрушительный процесс и не поддерживает сжатые и несжатые перспективы того же потока.
- В сжатом потоке по-прежнему имеется модель последовательного доступа. Это означает, что для поиска требуемого значения в журнале в худшем случае потребуется прочитать весь журнал, что обычно приводит к оптимизации, реализующей в точности представленный здесь шаблон: проецирование содержимого журнала в базу данных или кэш.
В конечном итоге сжатый журнал является хранилищем "ключ-значение" и, поэтому является наихудшим возможным вариантом реализации такого хранилища. Для поиска и уточняющих запросов гораздо более эффективным будет создание и использование постоянной проекции журнала на подходящее хранилище "ключ-значение" или другую базу данных.
Так как события являются неизменяемыми, а порядок всегда сохраняется в журнале, любая проекция журнала на хранилище «ключ-значение» всегда будет идентична для одного и того же диапазона событий, то есть проекция, которая постоянно обновляется, всегда дает достоверное представление, и нет никаких веских причин перестраивать ее на основе содержимого журнала после создания.
Руководство.
Технологии приложений репликации
Чтобы реализовать описанные выше шаблоны, требуется масштабируемая и надежная среда выполнения для задач репликации, которые следует настроить и запустить. В Azure для выполнения таких задач лучше всего подходят среды Azure Stream Analytics для задач репликации потоков с отслеживанием состояния и Функции Azure для задач репликации без отслеживания состояния.
Приложения репликации с отслеживанием состояния в Azure Stream Analytics
Для приложений репликации с отслеживанием состояния, которые должны рассматривать отношения между событиями, создавать составные события, обогащать или сокращать события, создавать статистические запросы данных и преобразовывать полезные данные событий, лучшим вариантом реализации будет Azure Stream Analytics.
В Azure Stream Analytics вы создаете задания , которые объединяют входные и выходные данные и интегрируют их из входных данных с помощью запросов , возвращающих результат, который затем становится доступным для выходных данных.
Запрос на языке SQL-запросов можно использовать для фильтрации, сортировки, агрегирования и объединения данных потоковой передачи за определенный промежуток времени. Этот язык SQL-запросов можно расширить с помощью определяемых пользователем функций JavaScriptи C#. Вы можете легко настроить параметры упорядочивания и продолжительность временных окон при осуществлении операций агрегирования с помощью простых языковых конструкций и (или) конфигураций.
Каждое задание поддерживает один или несколько потоков вывода преобразованных данных. Вы можете также настроить действия по результатам анализа информации. Например, администратор может сделать следующее:
- отправлять данные в службы, такие как Функции Azure, разделы служебной шины или Очередь, чтобы активировать связи или нисходящие пользовательские рабочие процессы;
- отправлять данные на информационную панель Power BI для мониторинга в режиме реального времени;
- сохранять данные в других службах хранилища Azure (например, Azure Data Lake, Azure Synapse Analytics и т. д.), чтобы выполнять пакетную аналитику и обучать модели машинного обучения на основе очень больших индексированных пулов исторических данных;
- Хранение проекций (также называемых "материализованными представлениями") в базах данных (База данных SQL, Azure Cosmos DB).
Приложения репликации без отслеживания состояния в Функциях Azure
Для задач репликации без отслеживания состояния, чтобы пересылать события, не учитывая их полезные данные, или обрабатывать их по отдельности без необходимости учитывать отношения событий (за исключением их относительного порядка), можно использовать Функции Azure, которые обеспечивают огромную гибкость.
В Функциях Azure есть готовые масштабируемые триггеры и привязки вывода для Центров событий Azure, Центра Интернета вещей Azure, Служебной шины Microsoft Azure, Сетки событий Azure и Хранилища очередей Azure, а также настраиваемые расширения для RabbitMQ и Apache Kafka. Большинство триггеров динамически адаптируются к потребностям в пропускной способности, увеличивая и уменьшая количество одновременно выполняемых экземпляров на основе задокументированных метрик.
Для создания проекций журналов Функции Azure поддерживает выходные привязки для Azure Cosmos DB и хранилища таблиц Azure.
Функции Azure могут выполняться с управляемым удостоверением Azure и могут содержать значения конфигурации для учетных данных в хранилище со строго контролированном доступом в Azure Key Vault.
Более того, Функции Azure позволяют напрямую интегрировать задачи репликации с виртуальными сетями Azure и конечными точками служб для всех служб обмена сообщениями Azure, и они легко интегрируются с Azure Monitor.
При использовании плана потребления Функций Azure готовые триггеры могут даже масштабироваться до нуля, а для репликации не будет доступных сообщений. Это означает отсутствие затрат на поддержание готовности к масштабированию. Ключевым недостатком использования плана потребления является то, что задержка "пробуждения" задач репликации из этого состояния, значительно выше, чем задержка планов размещения, на которых работает инфраструктура.
В отличие от всего этого, наиболее распространенные механизмы репликации для обмена сообщениями и событиями, такие как MirrorMaker Apache Kafka, требуют предоставления среды размещения и самостоятельного масштабирования механизма репликации. Сюда входит настройка и интеграция функций безопасности и сети, а также упрощение потока данных мониторинга, и при этом по-прежнему не будет возможности внедрять в поток настраиваемые задачи репликации.
Выбор между Функциями Azure и Azure Stream Analytics
Azure Stream Analytics (ASA) — это лучший вариант, если необходимо обработать полезные данные событий при их репликации. ASA может копировать события по одному или создавать статистические запросы, которые сжимают данные потоков событий перед их пересылкой. ASA может легко использовать дополнительные эталонные данные , хранящиеся в Хранилище BLOB-объектов Azure или Базе данных SQL Microsoft Azure, без необходимости импортировать эти данные в поток.
С помощью ASA можно легко создавать постоянные материализованные представления потоков в гипермасштабированных базах данных. Это гораздо более надежный подход к громоздкой модели сжатия журнала Apache Kafka и временных табличных проекций на стороне клиента для потоков Kafka.
ASA может легко обрабатывать события, имеющие полезные данные, закодированные в форматах CSV, JSON и Apache Avro . Кроме того, можно подключать пользовательские десериализаторы для любого другого формата.
Для всех задач репликации, в которых требуется копировать потоки событий "как есть", не затрагивая полезные данные, или если необходимо внедрить маршрутизатор, выполнить шифрование, изменить кодирование полезных данных или, если в противном случае требуется полный контроль над содержимым потока данных, лучшим вариантом является Функция Azure.
Next Steps
В этой статье мы рассмотрели ряд шаблонов федерации и объяснили роль Функций Azure в качестве среды выполнения репликации обработки событий и обмена сообщениями в Azure.
Далее можно узнать, как настроить приложение-репликатор с помощью Azure Stream Analytics или Функций Azure, а также как выполнять репликацию потоков событий между концентраторами событий и другими системами обработки событий и обмена сообщениями.