私のシナリオでは、複数の（不明な）サブスクライバーを持つServiceBusトピックを作成する予定です。トピックフィルターを使用できるため、トピックからの各メッセージを処理しません。
すべてのハンドラーがワークフローを続行するための作業を完了するまで、特定のメッセージ（Id）が待機する必要があります。当然、各ハンドラーは完了時にメッセージを生成します。たとえば、Durable Functionを使用してイベントのリストを待つことができます。
しかし、問題は、サブスクリプションメッセージのリストが送信された/送信されることをどのようにして知ることができるかです。
Microsoft.Azure.ServiceBus.Management.ManagementClient.GetSubscriptionsAsync()私は私のトピックのすべてのサブスクリプションのリストを取得することができます。しかし、特定のメッセージを受け取るかどうかをフィルターに従って評価する方法を見つけることができません。
ServiceBusでそれを実現できない場合、この種のシナリオを実装するための代替手段はありますか（Pub / Subのカスタム実装でホイールを再発明する以外に）？
サブスクリプションを複数のトピックに分割できますか？あなたがやろうとしていることの全体像を説明できますか？（たとえば、何をする必要があるのかではなく、なぜそれをする必要があるのかを説明してください。）
—
Slothario
@Slotharioトピックを複数のストリーム（サブスクライバーごとに1つ）に分割すると、パブリッシャーはサブスクライバーから独立しているという全体的な考えが崩れます。パブリッシャーのコードを変更せずに新しいサブスクライバーを動的に追加することはできません...
—
Sasha
最終的に何をしようとしていますか？負荷に基づいてシャーディングなどを実行しようとしているようですが、これは非常に一般的なシナリオです。Service Busがそのようなことをすぐに実行できることは間違いありません。Kafkaのようなものがそれを処理できると思います。しかし、あなたが解決しようとしている問題を私が知らなければ、言うのは難しいです。meta.stackexchange.com/questions/66377/what-is-the-xy-problem
—
Slothario
わかった。しかし、マイクロサービスについて私が学んだことは、マイクロサービスは実装が非常に簡単ですが、分散コンピューティングは見かけよりも難しいため、非常に複雑になるということです。マイクロサービスは、コードを整理するためではなく、組織内のコミュニケーションの行を減らすための戦略です。コードを整理するには、優れたデザインパターンを使用します。私は本当のことを納得させるためにいくつかの読書をすることを強くお勧めします。ただし、組織内に変更を加えるための影響力がない場合は、それも理解しています。
—
Slothario、
イベントをリッスンし、残りの処理を介して「プラグイン」呼び出しを調整する1つのコアサービスがあります。また、一部のプラグインは、コアで「登録」する必要があります（これは、azure devopsの一部として簡単に行うことができます）。この場合、マイクロサービスの柔軟性があるため、各チャンクを個別にデプロイできますが、イベントを誰がいつ処理するかを制御できます。さらに、イベント処理を注文したり、必要に応じて実行を中断したりして、他のプロセッサを呼び出さないようにしたり、ルールを追加したりできます。
—
Volodymyr Bilyachat