Репликация сообщений и федерация между регионами

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

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

Ваше решение будет поддерживать несколько пространств имен служебной шины в разных регионах, реплицировать сообщения между очередями и разделами и (или) обмениваться сообщениями с источниками и целевыми объектами, такими как Центры событий Azure, Центр Интернета вещей Azure или Apache Kafka.

Такие сценарии и рассматриваются в этой статье.

Шаблоны федерации

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

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

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

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

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

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

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

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

В этой категории мы обсудим три разных распределенных шаблона: репликация "все активные", репликация "активный-пассивный" и репликация переброски.

Репликация "все активные"

Шаблон репликации "все активные" позволяет активной реплике одного и того же логического раздела (или очереди) быть доступной в нескольких пространствах имен (и регионах), и все сообщения становятся доступными во всех репликах, независимо от того, где они были поставлены в очередь. Этот шаблон обычно сохраняет порядок сообщений относительно любого издателя.

Как показано на рисунке, в основе шаблона обычно лежат разделы служебной шины. По одному разделу для каждого пространства имен, которое должно участвовать в схеме репликации. Каждый из этих разделов имеет одну "подписку на репликацию" для любых других разделов, в которые будут реплицироваться сообщения. На приведенном выше рисунке есть просто пара разделов и, следовательно, одна подписка на репликацию для соответствующего другого раздела. В сценарии с тремя пространствами имен {n1, n2, n3} раздел в пространстве имен n1 будет иметь две подписки на репликацию: одну для соответствующего раздела в n2 и еще одну — для соответствующего раздела в n3.

Каждая подписка на репликацию имеет правило, которое объединяет выражение фильтра SQL (replicated <> 1) и действие SQL (set replicated = 1). Фильтр правила обеспечивает, что только сообщения, для которых настраиваемое свойство replication не задано или не имеет значение 1, станут допустимыми для этой подписки, а действие устанавливает для этого свойства значение 1 в каждом выбранном сообщении сразу после этого. В результате, когда сообщение копируется в соответствующий раздел, оно больше не подходит для репликации в обратном направлении, и, таким образом, исключается переброс сообщений между репликами.

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

az servicebus topic subscription rule create --resource-group myresourcegroup \
   --namespace mynamespace --topic-name mytopic \
   --subscription-name replication --name replication \
   --action-sql-expression "set replication = 1" \
   --filter-sql-expression "replication IS NULL"

Для моделирования очереди каждый раздел ограничен только одной обычной подпиской (отличной от подписок репликации), которую совместно используют все потребители.

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

Репликация "активный — пассивный"

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

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

Преимуществом этого шаблона является то, что он помогает свести к минимуму дублирующую обработку. Во время репликации в свойстве TimeToLive сообщения задается длительность в реплицированных сообщениях, которая отражает ожидаемое время, в течение которого сбой исходного раздела приведет к отработке отказа. Например, если в вашем варианте использования требуется переключение потребителя на вторичный раздел в течение не более 1 минуты после того, как появятся проблемы с извлечением сообщений из основного раздела, то в идеале во вторичном разделе должны быть все сообщения, к которым не удалось получить доступ в основном разделе, и минимальное количество сообщений, которые вы уже обработали в основном разделе до появления проблем. Если установить значение TimeToLive вдвое больше, т. е. 2 минуты, то во время репликации (set sys.TimeToLive = '0:2:0' в действии правила) вторичный раздел будет сохранять только сообщения за 2 минуты и удалять более старые. Это означает, что, когда получатель переключается на вторичный раздел, он может быстро прочитать и отбросить сообщения старше последнего обработанного, а затем обрабатывать, начиная с первого сообщения, которое он еще не видел. Фактическая продолжительность хранения будет зависеть от конкретного варианта использования и от того, как быстро вы хотите и можете переключаться на вторичный раздел в своем приложении. Параметр TimeToLive обрабатывается в диапазоне от нескольких секунд до нескольких дней.

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

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

Репликация переброски

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

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

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

Если обработка должна происходить в течение определенного срока, параметр TimeToLive для очереди и (или) сообщений должен быть установлен таким образом, чтобы обработка все еще могла быть выполнена в срок вторичным потоком переброски. Например, в TimeToLive может быть установлено значение, представляющее половину разрешенного времени.

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

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

Оптимизация задержки

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

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

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

Проверка, сокращение и обогащение

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

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

Репликация из потока в очередь

Центры событий Azure — идеальное решение для обработки больших объемов входящих событий. Но ни центры событий, ни аналогичные механизмы, такие как Apache Kafka, не предоставляют управляемую службами модель конкурирующих потребителей, в которой несколько потребителей могут одновременно обрабатывать сообщения из одного и того же источника без риска дублирования обработки и, наконец, организовывать эти сообщения после их обработки.

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

Консолидация и нормализация

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

Нормализация — это разновидность сценария консолидации, при котором две (или более) входящие последовательности сообщений несут один и тот же вид информации, но с разными структурами или разными кодировками, и сообщения необходимо перекодировать или преобразовать, прежде чем их можно будет использовать.

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

Разделение и маршрутизация

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

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

Приложения репликации в Функциях Azure

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

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

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

Что наиболее важно, в Функциях Azure есть готовые масштабируемые триггеры и привязки вывода для Центров событий Azure, Центра Интернета вещей Azure, Служебной шины Microsoft Azure, Сетки событий Azure и Хранилища очередей Azure, а также настраиваемые расширения для RabbitMQ и Apache Kafka. Большинство триггеров динамически адаптируются к потребностям в пропускной способности, увеличивая и уменьшая количество одновременно выполняемых экземпляров на основе задокументированных метрик.

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

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

Задачи репликации с использованием Azure Logic Apps

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

Next Steps

В этой статье мы рассмотрели ряд шаблонов федерации и объяснили роль Функций Azure в качестве среды выполнения репликации обработки событий и обмена сообщениями в Azure.

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

• Приложения репликации в Функциях Azure
• Репликация событий между сущностями Служебной шины
• Маршрутизация событий в Центры событий Azure
• Получение событий из Центров событий Azure