3

デュプレックス サービスを分割する必要があり、大量の転送を 1 つのサービスにカプセル化し、他のサービスから取得したいと考えています。以前はすべてを 1 つのサービスにまとめていましたが、サイズ/メモリの調整を考慮して、バッファリングからストリーミングに切り替える必要があります。こことここでいくつかの質問を見てきましたが、それらはかなり古いものです

サービス間の IPC、namedPipe には何を使用しますか?

サービス Aは 2 つのメソッドGuid Upload(stream)を公開Stream Download(Guid)し、net.tcp ストリーミングを使用します。これはうまく機能しています。

今、私はService Bに固執したいですか? これは namedPipe WCF でしょうか?

サービス C --> ビジネス レイヤー -->サービス B with Guid、アイテムの取得と計算、B への永続化

私の質問は、永続性/サービスBに何を使用するかです

クライアントの視点から

  1. クライアントの呼び出しServiceA_Proxy.Upload(someLargeItem)が返されますGuid
  2. その後、クライアントが呼び出しますServiceC_Proxy.DoSomeWork(GuidFromCall_1)
  3. その後、クライアントが呼び出しますServiceA_Proxy.Download(GuidFromCall_1)
  4. クライアントがエンドユーザーに表示する
4

1 に答える 1

0

はい、通信プロセスが同じサーバー上で実行されている限り、名前付きパイプをWCF バインド として使用できます。基本的に、TCP/IP などの他のバインディングを使用しているかのように WCF サービスを作成しますが、エンドポイントを使用するように構成する必要があります。netNamedPipeBinding

データを永続化/保存する場合は、要件に応じてファイルまたはデータベースに保存できます。ServiceC が要求するまでデータを保持したいだけであれば、それでDictionary<Guid, SomeLargeItem>十分です。

したがって、フローは次のようになります。

  1. クライアントが ServiceA_Proxy.Upload(someLargeItem) を呼び出して Guid を返す
  2. ServiceA は ServiceB_Proxy.Upload(GuidFromCall_1, someLargeItem) を呼び出します
  3. 次にクライアントが ServiceC_Proxy.DoSomeWork(GuidFromCall_1) を呼び出します (最初にアップロードが完了していることを確認する必要があります)
  4. ServiceC は ServiceB_Proxy.Download(GuidFromCall_1) を呼び出します
  5. ServiceC は DoSomeWork(GuidFromCall_1) を呼び出します (内部的に)
  6. ServiceC は ServiceB_Proxy.Upload(GuidFromCall_1, someLargeItemProcessed) を呼び出します
  7. その後、クライアントは ServiceA_Proxy.Download(GuidFromCall_1) を呼び出します (ここでも、処理が完了していることを確認する必要があります)
  8. ServiceA は ServiceB_Proxy.Download(GuidFromCall_1) を呼び出し、Client に戻ります。
  9. クライアントがエンドユーザーに表示する

何かを台無しにしていないかどうかはわかりません。ご覧のとおり、これはかなり複雑になっています。これが進むべき道であり、この方法でサービスを分割することで本当にスケーラビリティが向上するかどうかを自問する必要があります。NamedPipes を使用する予定であるため、すべての処理は引き続き同じマシン上で行われます。

あなたは本当にあなたのデザインを考えるべきです。機能をいくつかの *.dll に分割し、それらを直接呼び出すだけで十分でしょうか? このようにして、レイヤーを論理的に分離できます。 バッファー通信からストリーミング通信に切り替えるために、ロジックをより多くのサービスに分割する必要はありません。

また、真のスケーラビリティが必要な場合は、サービスごとにキュー( MSMQなど) と個別のマシンを使用することを検討してください。

于 2012-04-03T23:15:03.350 に答える