Рекомендации по изолированию приложений от простоев и аварий служебной шины
Критически важные приложения должны работать постоянно, даже при возникновении незапланированных простоев или аварий. В этой статье описаны методы, которые можно использовать для защиты приложений служебной шины от возможного простоя службы или аварии.
Простой определяется как временная недоступность служебной шины Azure. Простой может влиять на некоторые компоненты служебной шины, например на хранилище сообщений или даже на весь центр обработки данных. После устранения проблемы служебная шина снова становится доступной. Как правило, сбой не приводит к потере сообщений или других данных. Примером сбоя компонента является недоступность определенного хранилища сообщений. Примером простоя центра обработки данных является сбой питания центра обработки данных или неисправность сетевого коммутатора центра обработки данных. Простой может длиться от нескольких минут до нескольких дней.
Авария определяется как полная потеря единицы масштабирования или центра обработки данных служебной шины. Центр обработки данных может или не стал доступным снова. Авария обычно вызывает потерю некоторых или всех сообщений или других данных. Примеры аварий — пожар, наводнение или землетрясение.
Защита от сбоев и аварий — уровень "Премиум"
Концепции высокого уровня доступности и аварийного восстановления встроены прямо в уровень "Премиум" Служебная шина Azure, как в одном регионе (через зоны доступности), так и в разных регионах (с помощью геокатастирного восстановления).
Геоизбыточное аварийное восстановление
служебная шина уровня "Премиум" поддерживает гео-аварийное восстановление на уровне пространства имен. Дополнительные сведения см. в разделе Географическое аварийное восстановление в служебной шине Azure. Функция аварийного восстановления, доступная только для номера SKU класса Premium, реализует аварийное восстановление метаданных и использует первичные и вторичные пространства имен. При геокатастасовом восстановлении метаданные для сущностей реплика между основными и вторичными пространствами имен.
Зоны доступности
Уровень "Премиум" служебная шина поддерживает зоны доступности, предоставляя изолированные от сбоя расположения в одном регионе Azure. Служебная шина Microsoft Azure управляет тремя копиями хранилища сообщений (1 первичная и 2 вторичных). служебная шина сохраняет синхронизацию всех трех копий для операций управления и данных. Если первичная копия завершается сбоем, одна из вторичных копий повышается до первичной без наблюдаемого простоя. Если приложения видят временные отключения от служебная шина, логика повторных попыток в пакете SDK автоматически повторно подключается к служебная шина.
При использовании зон доступности метаданные и данные (сообщения) реплика между центрами обработки данных в зоне доступности.
Примечание.
Поддержка зон доступности для уровня "Премиум" доступна только в регионах Azure, где присутствуют зоны доступности.
При создании пространства имен уровня "Премиум" на портале поддержка зон доступности (если она доступна в выбранном регионе) автоматически включена для пространства имен. При создании пространства имен уровня "Премиум" с помощью других механизмов, таких как шаблоны Azure Resource Manager или Bicep, CLI или PowerShell, свойство zoneRedundant должно быть явно задано, чтобы true включить зоны доступности (если они доступны в выбранном регионе). Дополнительные затраты на использование этой функции не требуются, и вы не можете отключить или включить эту функцию после создания пространства имен.
Защита от сбоев и аварий — стандартный уровень
Чтобы обеспечить устойчивость к сбоям центра обработки данных с помощью стандартной ценовой категории обмена сообщениями, можно использовать активные или пассивные реплика. В каждом из этих подходов, если заданная очередь или раздел должны оставаться доступными при простое центра обработки данных, то эти очередь или раздел можно создать в обоих пространствах имен. Обе сущности могут иметь одно и то же имя. Например, первичная очередь может быть доступна как contosoPrimary.servicebus.windows.net/myQueue, а ее вторичный аналог — как contosoSecondary.servicebus.windows.net/myQueue.
Примечание.
Активные реплика ипассивные настройки реплика tion являются решениями общего назначения, а не конкретными функциями служебная шина. Логика реплика tion (отправка в 2 разных пространства имен) находится в приложениях отправителя, а получатель должен иметь пользовательскую логику для обнаружения дубликатов.
Если приложению не требуется постоянное взаимодействие отправителя с приемником, приложение может реализовать устойчивую очередь на стороне клиента, чтобы предотвратить потерю сообщения и защитить отправителя от временных служебная шина ошибок.
Активная репликация
При активной репликации для каждой операции используются объекты в обоих пространствах имен. Любой клиент, отправляющий сообщение, отправляет две копии одного и того же сообщения. Первая копия отправляется основной сущности (например, contosoPrimary.servicebus.windows.net/sales), а вторая копия — дополнительной сущности (например, contosoSecondary.servicebus.windows.net/sales).
Клиент получает сообщения из обеих очередей. Получатель обрабатывает первую копию сообщения, а вторая копия пропускается. Во избежание дублирования сообщений отправитель должен помечать каждое сообщение уникальным идентификатором. Обе копии сообщения должны быть помечены одним и тем же идентификатором. Для тега сообщения можно использовать свойства ServiceBusMessage.MessageId или ServiceBusMessage.Subject или пользовательское свойство. Получатель должен хранить список уже полученных им сообщений.
В примере [гео-реплика со стандартным уровнем служебная шина][Гео-реплика с служебная шина уровня "Стандартный") демонстрируется активное реплика tion сущностей обмена сообщениями.
Примечание.
При активной репликации количество операций удваивается, поэтому этот подход может привести к увеличению расходов.
Пассивная репликация
При отсутствии сбоев в пассивной репликации используется только одна из двух сущностей обмена сообщениями. Клиент отправляет сообщение активной сущности. При сбое операции на активной сущности с кодом ошибки, который указывает, что центр обработки данных, в котором размещена активная сущность, может быть недоступным, клиент отправляет копию сообщения резервной сущности. На этом этапе активные и резервные сущности переключают роли. Отправляя клиент считает старую активную сущность новой сущностью резервного копирования, а старая сущность резервного копирования является новой активной сущностью. Если обе операции отправки завершаются ошибкой, роли двух сущностей остаются неизменными, и возвращается ошибка.
Клиент получает сообщения из обеих очередей. Так как получатель получает две копии одного сообщения, получатель должен подавлять повторяющиеся сообщения. Устранить дубликаты можно так же, как при активной репликации.
В целом пассивная репликация экономичнее активной, поскольку в большинстве случаев выполняется только одна операция. Задержки, пропускная способность и расходы для нее идентичны сценарию без репликации.
При использовании пассивного реплика tion в следующих сценариях сообщения могут быть потеряны или получены дважды:
- Задержка или потеря сообщения. Предположим, что отправитель успешно отправил сообщение m1 в основную очередь, а затем очередь стала недоступной до получения сообщения m1 получателем. Отправитель отправляет следующее сообщение m2 в дополнительную очередь. Если основная очередь временно недоступна, то получатель получит сообщение m1 после того, как очередь снова станет доступной. Когда происходит авария, получатель никогда не получит m1.
- Дублирование. Предположим, что отправитель отправляет сообщение m в основную очередь. Служебная шина успешно обрабатывает m, но ей не удается отправить ответ. По истечении времени ожидания отправки сообщения отправитель посылает идентичную копию сообщения m в дополнительную очередь. Если получатель смог получить первую копию m до того как основная очередь стала недоступной, то он получит обе копии m приблизительно в одно и то же время. Если получатель не может получить первую копию m до того, как первичная очередь становится недоступной, получатель изначально получает только вторую копию m, но затем получает вторую копию m, когда первичная очередь становится доступной.
В примере задач репликации сообщений Azure с помощью .NET Core демонстрируется реплика сообщения между пространствами имен.
Следующие шаги
Дополнительные сведения об аварийном восстановлении см. в следующих статьях: