2

サービスファブリックを初めて使用しています。サービスファブリック、サービスバスからの継続的なポーリングに最適なマイクロサービス

Azure Service Busにキューがあります。サービスファブリックのキューから引き続きメッセージを処理し(ビジネスロジックを実行する)、DBにデータを保存してから、メッセージをキューから削除したいと考えています。

マイクロサービスは、新しいメッセージを監視するために2秒ごとにキューをチェックする必要があります。

私の質問は、です。データをプルし、ビジネスロジックを処理してDBに保存する予定のマイクロサービスとは何ですか?それは無国籍のサービスか信頼できる俳優ですか?

+0

は、あなたが本当にmicroserviceが必要なのでしょうか?あなたはwebjobを使用することができます、それはより簡単になります。マイクロサービスがキューによってのみトリガされる場合、それは実際にマイクロサービスですか? – Thomas

+0

@Thomasはい、ウェブの仕事は、問題を解決することができますが、システムの残りの部分は、Microservices入っていないだけで、このコンポーネントであるとして、それはそれがあることを考えるとファブリックから何かを使用する方が理にかなっているので、それは、アーキテクチャが複雑になります私たちが探しているものと緊密にマッチする。 – Adam

答えて

3

(編集:解釈の問題間違っ以前)

私はそれはあなたが選択したモデルの個人的な好みの問題だと思います。

ステートレスサービスをすべてのノードで実行し、メッセージを受信して​​ワーカースレッドで処理することができます。

アクターは、Single Entryモデル(マルチスレッドオプションを制限する)のために、多くのメッセージを単独で処理する能力がありません。しかし、俳優たちは数えられる。メッセージを聞く多くの俳優を持つことができます。あなたはそれらのアクターが&が生きているようになるようにする必要があります。


オリジナルの答え:

このnugetパッケージはこの行いは:https://www.nuget.org/packages/ServiceFabric.ServiceBus.Services それは、キュー、トピック、バッチ処理およびセッションをサポートしています。

+0

"ServiceFabricサービスとサービスバスを介して通信する" Adamの質問を解決したり答えることはできないようです。 – cassandrad

+0

@LoekD、この投稿を送信する前にGitHubであなたの解決策を見ました。しかし、私の質問は、このために使用しなければならないマイクロサービスのタイプに固有です。あなたのソリューションは、Azure SBを使用する方法ではなく、Fabric上のサービスバス実装のように見えます。 – Adam

+0

私は両方に謝罪しました。回答が – LoekD

0

いずれも使用できます。ステートレスまたはステートフル。本当に問題ではありません。私の見解で 、あなたは以下のことが可能です。

  1. がICommunicationListener由来する「ServiceBusCommunicationListenerを」と言うカスタムリスナーを作成します。 ICommunicationListenerの "Public Task OpenAsync(CancellationToken cancellationToken)"メソッドでは、サービスバスキューにアクセスするコードを記述できます。
  2. サービスバスキューの読み取りには、 "Microsoft.ServiceBus.Messaging.SubscriptionClient"を使用し、その "OnMessageAsync"メソッドを使用してメッセージを継続的に受信できます。
  3. サービスコード内にStatefulServiceの "CreateServiceReplicaListeners"オーバーライドまたはStatelessServiceの "CreateServiceInstanceListeners"を使用することができます。

    protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners() 
         { 
          return new[] { new ServiceReplicaListener(context => new ServiceBusCommunicationListener(context)) }; 
         } 
    
+0

キューからの連続ピッキングに 'OpenAsync'を使うのは悪い考えです。 'OpenAsync'は初期化のために一度呼び出され、解放されるべきです。待ち行列からのポーリングに 'RunAsync'を使い、' CloseAsync'で待ち行列やその他のリソースを初期化しない方が良いでしょう。 – cassandrad

+0

私の質問は、実装についてではなくサービスの種類に関するものでした。しかし、これを強調してくれてありがとう。 – Adam

+0

@Adam Gopiが言及したように、どんなタイプでも使用できますが、それはあなたには何の影響もありませんが、SFの中にデータを格納する必要がないため、ステートレスサービスを使用する方が良いでしょう。 – cassandrad

1

問題のスペースは、ステートフルモデルまたはステートレスモデルに適合しているようです。いずれかの状態は、状態を維持する必要があるかどうかによっては問題ありません。

  • あなたの問題空間が 、小さな独立した、と孤立状態のユニットと多数の(数千人以上)含まれます場合は一般的な指針として

    は、あなたの問題やシナリオをモデル化するために俳優のパターンを考えます論理。

  • 外部のコンポーネントからの重要な対話(アクターのセット全体で の状態を問い合わせることを含む)を必要としない単一スレッドのオブジェクトで作業する必要があります。
  • あなたの俳優のインスタンスが 発行するI/O操作で予測不可能な遅延で呼び出し元をブロックしません。

参考:https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-actors-introduction

関連する問題