Azure ServiceBus: Warten Sie, bis alle Abonnenten eine Nachricht verarbeitet haben

Mein Szenario ist, dass ich vorhabe, ein ServiceBus-Thema mit mehreren (unbekannten) Abonnenten zu erstellen. Sie können Themenfilter verwenden und verarbeiten daher nicht jede Nachricht aus dem Thema.

Ich muss für eine bestimmte Nachricht (ID) warten, bis alle Handler ihre Arbeit erledigt haben, um den Workflow fortzusetzen. Natürlich wird jeder Handler nach Abschluss eine Nachricht erzeugen und ich kann zum Beispiel Durable Function verwenden, um auf eine Liste von Ereignissen zu warten.

Aber die Frage ist, woher kann ich wissen, dass die Liste der Abonnementnachrichten an gesendet wurde / wird?

Mit Microsoft.Azure.ServiceBus.Management.ManagementClient.GetSubscriptionsAsync()kann ich die Liste aller Abonnements für mein Thema erhalten. Aber ich kann nicht herausfinden, wie ich beurteilen kann, ob eine bestimmte Nachricht nach Filtern aufgenommen wird oder nicht.

Wenn dies mit ServiceBus nicht möglich ist, gibt es Alternativen (außer die Neuerfindung des Rads mit der benutzerdefinierten Implementierung von Pub / Sub), um diese Art von Szenario zu implementieren?

c# .net azure servicebus

— Sasha
quelle

Könnten Sie Ihre Abonnements möglicherweise in mehrere Themen aufteilen? Können Sie das Gesamtbild dessen erklären, was Sie versuchen zu tun? (ZB bitte erklären Sie, warum Sie es tun müssen, nicht was Sie tun müssen.)

— Slothario

@Slothario Wenn wir das Thema in mehrere Streams aufteilen: einen für jeden Abonnenten, brechen wir die gesamte Idee auf, dass der Publisher von Abonnenten unabhängig ist. Wir können keine neuen Abonnenten dynamisch hinzufügen, ohne den Publisher-Code

— Sasha

Was versuchst du letztendlich zu tun? Es hört sich so an, als würden Sie versuchen, etwas wie Sharding basierend auf der Last zu tun, und das ist ein äußerst häufiges Szenario. Ich bezweifle nicht, dass Service Bus so etwas sofort macht, und ich weiß, dass Kafka wahrscheinlich damit umgehen kann. Es ist jedoch schwer zu sagen, wenn ich nicht weiß, welches Problem Sie lösen möchten. Meta.stackexchange.com/questions/66377/what-is-the-xy-problem

— Slothario

Ich verstehe das. Was ich jedoch über Microservices gelernt habe, ist, dass sie sehr einfach zu implementieren sind, aber schnell sehr kompliziert werden, da verteiltes Computing schwieriger ist, als es scheint. Microservices sind eine Strategie, um Kommunikationswege innerhalb einer Organisation zu reduzieren, nicht um Code zu organisieren. Verwenden Sie zum Organisieren von Code gute Entwurfsmuster. Ich empfehle dringend, etwas zu lesen, um sich davon zu überzeugen, dass dies wahr ist. Wenn Sie jedoch nicht die Schlagkraft in Ihrer Organisation haben, um die Änderung vorzunehmen, verstehe ich das auch.

— Slothario

Ich hätte einen Kerndienst, der auf Ereignisse wartet und "Plugins" -Aufrufe über Rest to Process koordiniert. Außerdem müsste sich jedes der Plugins im Core "registrieren" (das können Sie einfach als Teil von Azure-Devops tun), um zu sagen, dass ich Ereignisse irgendeiner Art verarbeiten kann. In diesem Fall haben Sie die Flexibilität von Mikrodiensten, sodass Sie jeden Block separat bereitstellen können, aber dennoch steuern können, wer und wann Ihre Veranstaltung verarbeitet. Darüber hinaus können Sie jetzt die Ereignisverarbeitung bestellen. Bei Bedarf können Sie auch die Ausführung unterbrechen, damit Sie keine anderen Prozessoren aufrufen, Regeln hinzufügen und so weiter.

— Volodymyr Bilyachat

Ich würde damit beginnen, die Fähigkeit zum Filtern zu entfernen.

Erstellen Sie mehrere Themen (kein Thema pro Abonnent), die eine Annäherung an die Filter darstellen.

Jeder Abonnent, der ein Thema abonniert, muss alle Nachrichten für dieses Thema verarbeiten. Auch wenn es so heißt, dass sie nichts damit gemacht haben.

Dann wissen Sie, wer jedes Thema abonniert und wer jede Nachricht zu jedem Thema verarbeitet hat.

— Shiraz Bhaiji
quelle

Ich dachte, die Idee von ServiceBus ist, dass Abonnenten entscheiden, welche Nachrichten sie abhören möchten. Und es ist schwierig, sie dazu zu bringen, keine Filter zu verwenden, wenn sie die Standard-API zum Abonnieren verwenden können ... Und Filter wurden eingeführt, um Kosten zu sparen - wenn eine Azure-Funktion 1% der Millionen Anforderungen pro Stunde verarbeiten muss, wäre dies der Fall Eine gute Kostenersparnis beim Auftragen von Filtern. Aber wirklich, ich bin zu dem gleichen Schluss gekommen, dass es im Moment nicht unterstützt zu werden scheint und jeder Abonnent leider auf jede Nachricht antworten muss.

— Sasha

Das Problem tritt auf, wenn Sie zwischen Nachrichten unterscheiden müssen, die sie lesen möchten und die sie nicht gelesen haben, und Nachrichten, an denen sie nicht interessiert waren und die weggefiltert wurden.

— Shiraz Bhaiji