Azure ServiceBus: espere hasta que todos los suscriptores procesen un mensaje

Mi escenario es que estoy planeando crear un tema de ServiceBus con un número múltiple (desconocido) de suscriptores. Pueden usar filtros de tema, por lo que no procesarán cada mensaje del tema.

Necesito que un mensaje (Id) determinado espere hasta que todos los controladores hayan hecho su trabajo para continuar el flujo de trabajo. Naturalmente, cada controlador producirá un mensaje al finalizar y puedo usar, por ejemplo, la función Durable para esperar una lista de eventos.

Pero la pregunta es ¿cómo puedo saber si la lista de suscripciones ha sido / será enviada?

Con Microsoft.Azure.ServiceBus.Management.ManagementClient.GetSubscriptionsAsync()puedo obtener la lista de todas las suscripciones para mi tema. Pero no puedo encontrar cómo evaluar si tomará un mensaje dado o no de acuerdo con los filtros.

Si eso no es posible con ServiceBus, ¿hay alguna alternativa (además de reinventar la rueda con la implementación personalizada de Pub / Sub) para implementar este tipo de escenario?

c# .net azure servicebus

— Sasha
fuente

¿Podría separar sus suscripciones en varios temas? ¿Puedes explicar la imagen más amplia de lo que estás tratando de hacer? (Por ejemplo, explique por qué necesita hacerlo, no lo que debe hacer.)

— Slothario

@Slothario Si dividimos el tema en varias transmisiones: una para cada suscriptor, romperemos la idea de que el editor es independiente de los suscriptores. No podremos agregar dinámicamente nuevos suscriptores sin modificar el código del editor ...

— Sasha

¿Qué estás tratando de hacer en última instancia? Parece que estás tratando de hacer algo como fragmentar en función de la carga, y ese es un escenario extremadamente común. No dudo que Service Bus hace algo así de inmediato, y sé que algo como Kafka probablemente podría manejarlo. Sin embargo, es difícil de decir a menos que sepa qué problema está tratando de resolver. meta.stackexchange.com/questions/66377/what-is-the-xy-problem

— Slothario

Lo entiendo. Pero lo que aprendí sobre los microservicios es que son muy fáciles de implementar, pero se vuelven muy complicados rápidamente porque la informática distribuida es más difícil de lo que parece. Los microservicios son una estrategia para reducir las líneas de comunicación dentro de una organización, no para organizar el código. Para organizar el código, use buenos patrones de diseño. Recomiendo leer un poco para convencerse de que es cierto. Sin embargo, si no tiene la influencia en su organización para hacer el cambio, también lo entiendo.

— Slothario

Tendría un servicio central que escucha los eventos y coordina las llamadas de "complementos" a través del descanso para procesar. También parte de eso cada uno de los complementos necesitaría "registrarse" (puede hacerlo fácilmente como parte de los desarrolladores azules) en el núcleo para decir que puedo procesar eventos de algún tipo. En este caso, tendrá flexibilidad de microservicios para que pueda implementar cada fragmento por separado, pero aún así podrá controlar quién y cuándo procesar su evento. Aún más, ahora puede ordenar el procesamiento de eventos, también puede interrumpir la ejecución si es necesario para no llamar a otros procesadores, puede agregar reglas, etc.

— Volodymyr Bilyachat

Comenzaría eliminando la capacidad de filtrar.

Cree varios temas (no un tema por suscriptor) que sean una aproximación de los filtros.

Cada suscriptor que se suscribe a un tema debe procesar todos los mensajes para ese tema. Incluso si es así, decir que no hicieron nada con él.

Entonces sabrá quién se ha suscrito a cada tema y quién ha procesado cada mensaje sobre cada tema.

— Shiraz Bhaiji
fuente

Pensé que la idea de ServiceBus es que son los suscriptores los que deciden qué mensajes quieren escuchar. Y es difícil hacer que no usen filtros cuando pueden usar API estándar para suscribirse ... Y se han introducido filtros para ahorrar costos; si alguna función de Azure necesita procesar el 1% de millones de solicitudes por hora, eso sería Un buen ahorro de costos para aplicar el filtro. Pero en realidad, llegué a la misma conclusión de que no parece ser compatible en este momento y, por desgracia, todos los suscriptores deberán responder a cada mensaje.

— Sasha

El problema surge cuando necesita diferenciar entre los mensajes que desean y no han leído, y los mensajes en los que no estaban interesados y se filtraron.

— Shiraz Bhaiji