4

私はこのシナリオを持っています、みんな-

次のビジネス トランザクションが表示される典型的な大規模 CMS アプリケーション:

  • ユーザーはすぐにコンテンツを公開します。
  • ユーザーはコンテンツの公開をスケジュールします。
  • 自動プロセスは、たとえば 10 分間隔で実行され、スケジュールされた準備完了(単に BO のステータス) のコンテンツを収集し、公開に送信します。

これは、実際のシステムの単純化された説明です。パブリッシュとは、呼び出し引数の構築、別の Web アプリ (asp.net) の実行による html コンテンツの生成、トランザクション パーティのコミット、およびパブリッシュ結果に関するユーザーへの通知という4 つの主要なサブシステムで構成される複雑なプロセスを意味します。したがって、システムはプロセス全体を単一のメガトランザクションで実行する能力を失います。つまり、可能ですが、スケーラビリティ/パフォーマンスの観点からは実用的ではありません。

サブシステムが相互に通信するためのオプションがいくつかあります。たとえば、MSMQ、SQL Service Broker、NServiceBus、プレーンな WCF の一方向呼び出しのチェーン (現在実装されています) を利用するなどです。ユーザー数の増加に伴い、システムがより忙しくなり、より多くのコンテンツが生成されるように見えるため、この処理のためのより信頼性が高くスケーラブルなソリューションを探しています。特に、クライアントからモバイル版のサポートが要求されたことがあります。

私の考慮事項の 1 つは、専用の WCF サービスがコンテンツ生成モジュール (Web アプリ) の隣にディスパッチする MSMQ を使用して、すべてのユーザーの即時要求をキューに入れることです。Windowsのスケジュールされたタスクも同様です。これらのメッセージング プラットフォームがどのように役立つかはわかりませんが、html 生成の前にそれらが存在するわけではありません。これは本当に私を混乱させます。

どのテクノロジーがこれに最適かを自分で判断することはできません.どんな助け、考慮事項、あなたの経験を共有することも私を助けます.

4

3 に答える 3

3

ビジネスプロセスの処理が必要になることは間違いありません。

あなたの即時の要求は、コマンドメッセージに変換されます。コマンドが処理されると、プロセスの次のステップがプロセスを続行するために取得できるイベントメッセージを発行できます。したがって、スケジュールを立てる必要さえないかもしれません。

私は似たようなことをしました:

電子メール -> コンテンツ エンジン -> ドキュメント変換 -> ワークフロー エンジン -> インデックス作成 -> ワークフロー エンジン

スケジューリングは関与しませんでした。何かを行うには、コマンドを送信します。コマンド処理が完了すると、エンドポイントがパブリッシュとイベントを発行し、そのイベントにサブスクライブされているエンドポイントはコピーを受け取り、続行する方法を認識します。プロセスのデータと適切なステータスを追跡する単純なテーブル構造がありました。

システムの一部については、より迅速な対応が必要な場合があります処理。これに遭遇した場合、エンドポイント サービスを複数回インストールして、1 つを「優先」エンドポイントとして機能させることができます。例として。ドキュメント コンバーター エンドポイントでは、各電子メール本文を変換する必要があります。1 日に数千件の注文があったため、かなりの数の列ができていました。これはバックグラウンドで行われ、いつ発生したかは気にしませんでした。一方、インデックス Web アプリケーションのユーザーは、特定のドキュメントを Web サイトからすぐに変換する必要があります。同じ変換エンドポイントに送信すると、アドホック コンバージョンが数千もの他のコンバージョン リクエストの背後で待機することになりました。そのため、応答はありませんでした。解決策は、単純に別のコンバーター インスタンス (同じバイナリ) をインストールし、エンドポイントに個別のキューを構成して、Web サーバーからのすべての変換要求メッセージをアドホック エンドポイントにルーティングすることでした。問題が解決しました :)

補足として: Web サービス インターフェイスまたは WCF を使用する場合でも、エンドポイントがかなりの負担を負うため (再試行/ポイズン キューなど)、サービス バス エンドポイントの背後に配置することをお勧めします。

あなたは評価段階にあるようですので、私の FOSS サービスバスを見てみたいかもしれません: http://shuttle.codeplex.com/

これは、説明したシステムで使用したものです。必要に応じて別のスケジューラ コンポーネントがあります (ただし、プロジェクトでは使用しませんでした)。

于 2012-11-27T04:28:21.953 に答える
3

すべてのプレイヤーが SQL Server インスタンスである (またはそのようなインスタンスに支えられている) 場合、Service Broker には大きな利点があります。SQL エンジンに統合されているため、データベースとメッセージ ストア間でローカル分散トランザクションを実行する必要がある場合 (つまり、メッセージをキューに入れたりキューから取り出したりするたびに) は、データベースがメッセージストアですこれは、データとメッセージの両方の一貫したバックアップ(データベース バックアップにはすべてのメッセージのバックアップが含まれます)を保持できるため、バックアップ/復元を検討する場合にも利点があります。データベース ソリューション (クラスタリング、ミラーリング) は、メッセージングの HA/DR ストーリーでもありますメッセージストア。また、組み込みのアクティベーションにより、外部アクティベーション メカニズムを構成する必要がなくなります (さらに重要なのは、HA/DR フェイルオーバーの場合の監視とフェイルオーバー)。ビルトインのアクティベーションにはレイテンシーがなくスパイクにも適応できることは言うまでもありません。外部のスケジュールされたアクティベーションでは、達成に問題が生じる可能性があります (外部タスクはプールする必要があり、プールの頻度と望ましいレイテンシーのバランスを取り、スパイクを考慮する必要があります)。

于 2012-11-25T17:21:01.040 に答える
3

NServiceBus の saga 機能を使用して、スケジューリング部分を含む公開プロセスをモデル化できます。これは、一定の遅延の後に実質的にオーバーヘッドなしでアクションを確実に実行する機能があるためです。

ユーザーの即時要求をキューに入れることができれば、MSMQ、WCF、および Windows スケジュール タスクを自分で組み合わせる代わりに、NServiceBus を API として簡単に使用できます。

于 2012-11-23T15:01:13.727 に答える