Совместное использование надежных очередей Azure Service Fabric между службами

Я погружаюсь в Service Fabric (из мира облачных сервисов) и сталкиваюсь с некоторыми проблемами, связанными с работой ReliableQueues.

Допустим, у меня есть 2 службы с отслеживанием состояния: StatefulService1 и StatefulService2.

Если мне нужно, чтобы StatefulService1 отправлял сообщение в очереди, которое StatefulService2 выбирает и читает, могу ли я использовать ReliableQueues или ReliableQueues изолированы внутри службы, в которой они созданы ?

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

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

ОБНОВИТЬ

Просто хочу уточнить, что я пытался удалить сообщение, созданное в StatefulService1, из StatefulService2, и оно оказалось пустым. Удаление из StatefulService1 работало нормально, как и ожидалось.


azure azure-service-fabric service-fabric-stateful
person INNVTV    schedule 05.03.2017    source источник

Ответы (4)


arrow_upward
3
arrow_downward

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

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

person Sean Feldman    schedule 05.03.2017
comment
Спасибо, Шон. Можете ли вы помочь мне понять, как тогда следует использовать ReliableQueue? Как я уже сказал, ReliableDictionary имеет смысл, поскольку он заменяет кеш. Но если у вас есть служба, отправляющая сообщения в очередь, в каком сценарии у вас будет эта же служба, читающая из очереди? Для меня очередь - это способ заставить другие процессы обрабатывать задачи посредством развязки, спасибо! - person INNVTV; 06.03.2017
comment
Надежная очередь отлично подходит для постановки рабочих элементов в очередь. Это не механизм связи между сервисами, а структура данных в памяти для одного процесса. Например, получите рабочие элементы и поставьте их в очередь, чтобы другой поток (в рамках этой службы) мог получить к ним доступ для фактической обработки. - person Sean Feldman; 06.03.2017
comment
Спасибо. В этом есть смысл. Таким образом, вместо (например) наличия WorkerRole, который запускает задачи для многих служб, теперь я могу заставить службу запускать эти задачи в отдельном потоке. - person INNVTV; 06.03.2017
comment
Помните, что для связи между сервисами все равно что-то потребуется. - person Sean Feldman; 06.03.2017

arrow_upward
4
arrow_downward

Надежные коллекции находятся в структурах данных памяти, которые не предназначены для обмена данными между службами. Если вы хотите установить канал связи между StatefulService1 и StatefulService2, у вас есть следующие возможности:

  1. Используйте слушателей общения. У вас могут быть собственные прослушиватели для протокола по вашему выбору, включая HTTP, WCF или ваш собственный протокол. Вы можете узнать больше об этом в этом раздел. Например, StatefulService2 может открыть конечную точку HTTP, к которой StatefulService1 может выполнять POST / GET.

  2. Используйте внешнюю систему очередей, например Servicebus, EventHub или Kafka, где StatefulService1 может отправлять события. StatefulService2 может быть службой потребителя, которая принимает события из очереди и обрабатывает их.

person Sujay S Kumar    schedule 21.09.2017

arrow_upward
1
arrow_downward

Я не понимаю, почему служба не может разместить надежную коллекцию / очередь, а другие службы могут получить к ней доступ через один из трех транспортов: удаленное взаимодействие, WCF и HTTP.
Очевидно, надежная служба должна будет раскрыть коллекцию / queue через API или реализовать интерфейс IService

https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-connect-and-communicate-with-services

person LastTribunal    schedule 10.11.2017

arrow_upward
0
arrow_downward

Вам необходимо добавить в вызывающий код шаблон повтора обработки ошибок, см. https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-communication, в этом случае вам не нужно очередь для хранения данных между вызовами службы.

person Robert    schedule 20.09.2017