Насколько надежен доступ к служебной шине Azure?

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

Эти данные должны быть поставлены в очередь и обработаны другим работником.

Очень важно, чтобы эти уведомления не были пропущены, поэтому мне интересно:

  • Допустимо ли (с учетом моего требования) ставить сообщения в очередь непосредственно на служебную шину Azure?

  • Или мне следует сначала поставить в очередь локальный MSMQ, а затем поставить другого работника, который читает сообщения из MSMQ и отправляет их в служебную шину Azure?

Спасибо


azure azureservicebus
person Avram    schedule 06.03.2014    source источник
comment
Надежный - довольно расплывчатый термин. Что конкретно вам нужно знать?   -  person Paul Turner    schedule 06.03.2014
comment
@Tragedian Думаю, я хотел знать, могу ли я предположить, что вызовы служебной шины будут успешными. Но, поскольку кажется, что мне нужно учитывать временные ошибки, я не могу этого сделать.   -  person Avram    schedule 06.03.2014

Ответы (2)


arrow_upward
5
arrow_downward

Доступ к служебной шине очень надежен, но вам всегда придется создавать свое решение, чтобы справляться с «временными сбоями». Таким образом, вы можете проверить, не возникает ли какая-либо ошибка (временная ошибка 404 в очереди, проблема с подключением на вашей стороне и т. д.). Эти ошибки называются временными ошибками, и вы должны повторить попытку их устранения. Для этого клиент служебной шины имеет встроенные функции, и на клиенте можно указать RetryPolicy. Доступны различные политики повторных попыток, и вы можете создать свою собственную (ExponentialBackoff и т. д.). Проверьте: http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.servicebus.messaging.messageclientity.retrypolicy.aspx

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

Надеюсь это поможет

person Sam Vanhoutte    schedule 06.03.2014
comment
Я думаю, что MSMQ подойдет. Процесс порождается для каждого уведомления и должен быстро завершиться, чтобы их не осталось в большом количестве. Я думаю, что было бы безопаснее засунуть его в MSMQ, а затем взять оттуда, а не ждать повторной попытки, чтобы добиться успеха. Большое спасибо. - person Avram; 06.03.2014
comment
Это действительно зависит от вашего сценария, но повторные попытки действительно исключительны (и поддерживаются SLA). Я всегда предпочитаю, чтобы архитектуры и решения были как можно более простыми, и на первый взгляд это выглядит довольно сложной дополнительной частью работы, только для нескольких случаев, когда могут возникнуть проблемы с подключением. Но опять же: все зависит от вашего сценария. Удачи - person Sam Vanhoutte; 07.03.2014

arrow_upward
2
arrow_downward

Служебная шина Azure гарантирует доступность на уровне 99,9 % (не более 8,76 часов недоступности в год). Источник: http://www.windowsazure.com/en-us/support/legal/sla/

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

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

Если вы поместите службу MSMQ между своими очередями Azure и вашим приложением, вам все равно придется иметь дело с возможностью того, что эта локальная очередь может быть недоступна — вы не можете запустить и забыть, если вам нужно знать, что сообщения не теряясь. Должно быть подтверждение получения и механизм повторной доставки сообщений, для которых вы не получили подтверждения.

person Paul Turner    schedule 06.03.2014