9

現在、最終的に Windows Azure に移行したいアプリケーションを設計しています。ただし、短期的には、私が自分でホストするサーバーで実行されます。

このアプリケーションには、多数の個別の Web アプリケーションが含まれます。これらのアプリケーションの一部は本質的にデータを受信する WCF サービスであり、一部はユーザーがデータを管理するためのサイトです。さらに、さまざまな方法でデータを処理するワーカー サービスをバックグラウンドで実行する必要があります。

私は、このために分離アーキテクチャを使用することに非常に熱心です。理想的には、コンポーネント (つまり、Web アプリとワーカー サービス) がお互いをできるだけ認識しないようにしたいと考えています。ここでは、メッセージ キューを使用することが最善の解決策であるように思われます。Web アプリはワーク ユニットを含むメッセージをキューに入れることができ、ワーカー サービスはそれらを取り出して必要に応じて処理することができます。

ただし、最終的には Azure に移行することを念頭に置いて、これを行うための優れた一連のテクノロジを検討したいと考えており、クラウドに移行するときに必要な再作業の量を最小限に抑えたいと考えています。 . Azure には、私のニーズに最適な Queue コンポーネントが組み込まれています。私がやりたいのは、これを可能な限り模倣するものを自分で作成することです.

いくつかのオプションがあるようです (私は Windows で .NET を使用し、SQL Server 2005 バックエンドを使用しています) - これまでに見つかったものは次のとおりです。

  • MSMQ
  • SQL Server サービス ブローカー
  • データベース テーブルといくつかのストアド プロシージャを使用して独自のロールを作成する

誰かがこれについて何か提案があるかどうか、または誰かが同様のことをして、やるべきこと/避けるべきことについてアドバイスを持っているかどうか疑問に思っていました. すべての状況が異なることは承知していますが、この場合、私のキューイング要件はかなり一般的だと思うので、これを行う最善の方法について他の人の考えを聞きたいです.

前もって感謝します、

ジョン

4

3 に答える 3

18

Azure を念頭に置いている場合は、Azure キューと MSMQ または SSB のいずれかとの間で API とセムナティクスが大きく異なるため、おそらく Azure から直接開始する必要があります。

MSMQ と SSB の 3048 メートルの簡単な比較 (実装方法に大きく依存するため、キューとしてのカスタム テーブルは比較対象外にします...)

  • 配置: MSMQ は Windows コンポーネントで、SSB は SQL コンポーネントです。SSB はメッセージを格納するために SQL インスタンスを必要とするため、切断されたクライアントはインスタンス (Express の場合もある) にアクセスする必要があります。MSMQ では、クライアントに MSMQ を展開する必要があります (OS の一部ですが、インストールはオプションです)。
  • プログラマビリティ : MSMQ は、本格的なサポート対象の WCF チャネルを提供します。SSB は、 http: //ssbwcf.codeplex.com で実験的な WCF チャネルのみを提供しています。
  • パフォーマンス: SSB は、トランザクション モードで MSMQ よりも大幅に高速になります。非トランザクション モード (ベスト エフォート、非順序、配信) で動作させると、MSMQ はより高速になります。
  • クエリ可能性 : SSB キューは選択可能 (任意のメッセージを表示、完全な SQL JOIN/WHERE/ORDER/GROUP パワー)、MSMQ キューはピーク可能 (次のメッセージのみ)
  • 回復可能性: SSB キューはデータベースに統合されているため、データベースと一緒にバックアップおよび復元され、アプリケーションの状態と一貫した状態を維持します。MSMQ キューは NT ファイル バックアップ サブシステムにバックアップされるため、バックアップの同期 (一貫性) を維持するには、キューとデータベースを一時停止する必要があります。
  • トランザクション(すべてのエンキュー/デキューには常にデータベースの更新が伴うため): SSB は SQL に完全に統合されているため、デキューとエンキューはローカル トランザクション操作です。MSMQ は別個の TM (トランザクション マネージャー) であるため、SQL と MSMQ の両方をトランザクションに登録するには、キュー/デキューを分散トランザクション操作にする必要があります。
  • 管理と監視：どちらも同じように悪い。道具は一切ありません。
  • 相関メッセージの処理: SSB は、組み込みのConversation Group Lockingを介して、並行スレッドによる相関メッセージの処理をブロックできます。
  • イベント ドリブン: SSB にはストアド プロシージャを起動するアクティベーションがあり、MSMQ はWindows アクティベーションサービスを使用します。似ている。ただし、SSB には、WAITFOR(RECEIVE) と MAX_QUEUE_READERS が相互作用する方法により、自己負荷分散機能があります。
  • 可用性: SSB は SQL Server の高可用性の話に便乗しており、クラスター化された環境でもデータベース ミラーリング環境でも機能します。MSMQ は、Windows クラスタリングの話だけに乗ります。データベース ミラーリングは、HA ソリューションとしてクラスタリングよりもはるかに安価です。

さらに、SSB と MSMQ は提供するプリミティブのレベルが大きく異なることを付け加えておきます。SSB プリミティブは会話ですが、MSMQ プリミティブはメッセージです。TCP と UDP のセマンティクスを考えてみてください。

于 2009-08-27T00:27:24.600 に答える
10

自分に合った、または環境により適したキュー バックエンドを選択してください。@Remus は、MSMQ と SSB の優れた比較を行いました。MSMQ は実装が簡単ですが、いくつかの顕著な制限があります。一方、SSB はスペクトルの反対側にあるため、非常に重く感じられます。

アプリケーションのやり直し
を最小限に抑えるために、インターフェイスの背後でキュー アクセスを抽象化し、最終的に使用することを決定したキュー トランスポートの実装を提供します。Azure または別のキュー トランスポートに移行するときは、インターフェイスの新しい実装を提供するだけです。

アプリケーションから一貫して使用可能な API を提供するために、キューとやり取りする方法のセマンティクスを制御できます。

大まかなアイデアは次のとおりです。

interface IQueuedTransport
{
  void SendMessage(XmlDocument);
  XmlDocument ReceiveMessage();
}

public class MSMQTransport : IQueuedTransport {}
public class AzureQueueTransport : IQueuedTransport {}

あなたのニーズを満たすものだけで、すべてのキューイングトランスポートを構築しているわけではありません。Xml を使用する場合は、xml を渡します。バイト配列で作業する場合は、バイト配列を渡します。:)

幸運を！
Z

于 2009-08-27T01:13:51.663 に答える
0

Win32メールスロットを使用します。それらは単一のサーバー上で信頼性が高く、実装が簡単で、追加のソフトウェアを必要としません。

于 2011-03-02T23:28:16.200 に答える