1

Windows Azure ワーカー ロールで実行されるシステム内で定期的なタスクを実行する必要があることがわかりました。強調したいのは、Azure、Amazon、社内ソリューションのいずれのプラットフォームでもよいということです。通常のシステムに関しては、タスクをどのように行うかは問題ではありませんが、私たちはクラウドにいて、私の役割のインスタンスがいくつかある可能性があるため、ある時点で問題になる可能性があります.

だからここに私が考えることができるいくつかのアプローチがあります：

  1. タスクを何度も実行しないように、Azure ストレージを介して同期される通常のタイマー。自分で実装することも、たとえば Lokad から取得することもできます。タイマーイベントでタスクをインラインで実行するか、コマンドをキューに送信できます。

    長所：

    • 一般的なアプローチ、誰もがタイマーとその調理方法を知っています
    • 状態を持つ必要はありません。インスタンスが起動すると、タイマーも起動して実行されます

    短所：

    • キューからのコマンドとイベントの処理のみを担当する主要部分のすぐ隣に、タイマーを初期化して実行する追加のロジックがあります。

  2. タスクを開始するコマンドを取得したら、コマンド StartTask(30 秒) を送信します。コマンドハンドラーがそれを受け取ると、実行する必要があるものを実行し、30 秒の遅延で同じコマンドを再スローします。

    長所：

    • CQRS 設計に完全に適合
    • タイマーに関連する追加ロジックなし、純粋な原子炉

    短所：

    • パラダイム ブレイク、CQRS 自体を扱い、最初から使用するのは非常に困難です。設計に適合しない場合でも (通常のタイマー)、人々は既知のテクノロジ (通常のタイマー) を使用する傾向があり、その結果、複雑な融合が発生します。
    • 別の壊れたパラダイム。システムの再起動時にステートレスまたはステートフルですか? 保存された状態は、仲介されたメッセージング環境にあると言えます。メッセージ処理ルールに従うだけです。

それに関する私の意見：

個人的には、私は 2 番目のアプローチを支持しており、そのすべての短所は長所の部分に移動する必要があります。

質問：

ここでのベストプラクティスは何ですか? 何か不足していますか？

4

4 に答える 4

1

私のお勧めは、期間タスクの実行を担当する別のコンポーネントを選択することです。このようにして、どのように動作するかを決定し、CQRS ワーカーとは別にスケーリングすることができます。

Azure でこれらのタスク (定期的なタスクと CQRS) の両方を 1 つのインスタンスで処理する場合は、それらを Windows サービスに変換し、Worker ロールをインストーラーおよびオブザーバーとして使用できます。ここに私のソリューションで構築された例があります。

ところで、Lokad.Cqrs を使用する場合、メイン コンポーネントから分離されていれば、2 番目のアプローチは問題ないように思えます。

于 2013-04-07T18:20:55.970 に答える
1

Windows Mobile ServicesのスケジューラーやAditiの Windows Azure Store Scheduler アプリのようなものを使用するのはどうでしょうか? それらを使用して、ほぼすべてを開始することができ、システムにコマンドを送信させることができます。

オプション 1 を実行した場合は、はい、同期に対処する必要がありますが、そこには冗長性が組み込まれています。オプション 2 を実行し、コマンドを処理するインスタンスに障害が発生した場合は、タスクが停止していないことを確認してください。それは、コマンドの再試行の設定方法によって異なります。

于 2013-04-06T12:06:18.690 に答える