Выдержит ли соединение Azure Service Bus перестановку узла Azure Service Fabric? - PullRequest
0 голосов
/ 04 мая 2018

Я использую Обмен сообщениями служебной шины Azure (ASB) в качестве Промежуточного программного обеспечения для сообщений (MOM). В частности, тема и подписки как решение Pub-Sub.

Я использую ASB в кластере Azure Service Fabric (ASF). Управление кластером ASF может перетасовать узлы, которые прерывают соединения с ASB.

Интересно, что будет правильным способом изящного разрыва соединений?

Я думаю, что в будущем у кластера появится решение Pub-Sub. Это решит и другие вопросы.

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

Ответы [ 2 ]

0 голосов
/ 04 мая 2018

Управление кластером ASF может перетасовать узлы, что может привести к разрыву соединений с ASB.

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

На данный момент я могу сохранить соединение в надежной коллекции службы с отслеживанием состояния

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

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

Я думаю, вы неправильно поняли идею по этой теме.

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

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

0 голосов
/ 04 мая 2018

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

...