ServiceBus do Azure: aguarde até que todos os assinantes processem uma mensagem

Meu cenário é que estou planejando criar um tópico do ServiceBus com vários números (desconhecidos) de assinantes. Eles podem usar filtros de tópicos, portanto, não processam cada mensagem do tópico.

Preciso que uma determinada mensagem (ID) aguarde até que todos os manipuladores tenham feito seu trabalho para continuar o fluxo de trabalho. Naturalmente, cada manipulador produzirá uma mensagem após a conclusão e eu posso usar, por exemplo, a Função Durável para aguardar uma lista de eventos.

Mas a questão é: como posso saber se a lista de assinaturas que a mensagem foi / será enviada?

Com Microsoft.Azure.ServiceBus.Management.ManagementClient.GetSubscriptionsAsync()posso obter a lista de todas as assinaturas do meu tópico. Mas não consigo descobrir como avaliar se a mensagem será aceita ou não de acordo com os filtros.

Se isso não for possível com o ServiceBus, existem alternativas (além de reinventar a roda com a implementação personalizada de Pub / Sub) para implementar esse tipo de cenário?

c# .net azure servicebus

— Sasha
fonte

Você poderia dividir suas assinaturas em vários tópicos? Você pode explicar a imagem mais ampla do que você está tentando fazer? (Por exemplo, por favor, explique por que você precisa para fazê-lo, não o que você precisa fazer.)

— Slothario

@ Slothario Se dividirmos o tópico em vários fluxos: um para cada assinante, quebraremos toda a ideia de que o editor é independente dos assinantes. Não seremos capazes de adicionar novos assinantes dinamicamente sem modificar o código do editor ...

— Sasha

O que você está tentando finalmente fazer? Parece que você está tentando fazer algo como sharding com base na carga, e esse é um cenário extremamente comum. Não duvido que o Service Bus faça algo assim imediatamente, e sei que algo como Kafka provavelmente poderia lidar com isso. No entanto, é difícil dizer, a menos que eu saiba qual problema você está tentando resolver. meta.stackexchange.com/questions/66377/what-is-the-xy-problem

— Slothario

Entendi. Mas o que aprendi sobre os microsserviços é que eles são muito fáceis de implementar, mas se tornam muito complicados rapidamente porque a computação distribuída é mais difícil do que parece. Os microsserviços são uma estratégia para reduzir as linhas de comunicação dentro de uma organização, não para organizar o código. Para organizar o código, use bons padrões de design. Eu recomendo fazer algumas leituras para se convencer de que é verdade. No entanto, se você não tem a influência de sua organização para fazer a alteração, eu também entendo isso.

— Slothario

Eu teria um serviço principal que escuta eventos e coordena chamadas de "plug-ins" por meio do resto para processar. Também é parte disso que cada um dos plug-ins precisaria "registrar" (você pode facilmente fazer isso como parte do azure devops) no núcleo para dizer que eu posso processar eventos de algum tipo. Nesse caso, você terá flexibilidade de microsserviços para poder implantar cada parte separadamente, mas ainda assim poderá controlar quem e quando processar o seu evento. Ainda mais, agora você pode solicitar o processamento de eventos, também pode interromper a execução, se necessário, para não ligar para outros processadores, adicionar regras e assim por diante.

— Volodymyr Bilyachat

Eu começaria removendo a capacidade de filtrar.

Crie tópicos do servidor (não um tópico por assinante) que sejam uma aproximação dos filtros.

Todo assinante que assina um tópico deve processar todas as mensagens desse tópico. Mesmo que seja assim, diga que eles não fizeram nada com isso.

Então você sabe quem se inscreveu em cada tópico e quem processou cada mensagem em cada tópico.

— Shiraz Bhaiji
fonte

Eu pensei que a idéia do ServiceBus é que são os assinantes que decidem quais mensagens eles querem ouvir. E é difícil fazê-los não usar filtros quando conseguem usar a API padrão para a assinatura ... E foram introduzidos filtros para economizar custos - se alguma Função do Azure precisar processar 1% do milhão de solicitações por hora, isso seria uma boa economia de custo para aplicar o filtro. Mas, na verdade, cheguei à mesma conclusão de que não parece ser suportado no momento e todos os assinantes precisarão responder a todas as mensagens, infelizmente.

— Sasha

O problema surge quando você precisa diferenciar as mensagens que eles desejam e que não leram e as mensagens nas quais eles não estavam interessados e foram filtrados.

— Shiraz Bhaiji