2

QueueTrigger新しいメッセージがキューで利用可能になったときに呼び出されるものがあることを知っています。ただし、この「フレームワーク スタイル」の Web ジョブにより、環境を正しく初期化することが複雑になります。

これが、自分でキューをポーリングしたい理由です。基本的なパターンは次のとおりです。

var account = CloudStorageAccount.Parse("connectionString");
var client = account.CreateCloudQueueClient();

// Per application initialization stuff goes here

while(true) {
    var queue = client.GetQueueReference("myqueue");
    var message = queue.GetMessage();

    if (message != null) {
        // Per message initialization stuff goes here
        // Handle message

        queue.DeleteMessage(message);
    }
    else {
        Thread.Sleep(10000); // Or some exponential back-off algorithm
    }
}

私の質問は、WebJob で継続的に実行する場合、このアプローチに潜在的な問題はありますか? もしそうなら、「フレームワーク スタイル」の Web ジョブを回避するための可能な代替手段は何ですか?

編集

QueueTriggerビクターからのリクエストに応じて、このアプローチを使用したくない理由についての詳細を以下に示します。基本的に2つの理由があります。

1 つ目は既に上で述べたように、フレームワークがQueueTrigger属性を持つメソッドを呼び出すという事実です。これは、すべての初期化をそのメソッドに入れる必要があることを意味します。

Web アプリには 2 段階の IoC コンテナー (アプリケーションごとおよび要求ごと) があり、Web ジョブをできるだけ Web アプリに近づけたいので、その 2 段階の IoC を使用したいと考えています。 Web ジョブでも同様です (アプリケーションごとの IoC は、すべての要求で再利用される重い初期化を行います)。この結果、静的QueueTriggerメソッドからアクセスできるように、アプリケーションごとのコンテナーを静的変数またはシングルトンに配置する必要があります。これは、私が作りたくない設計上の癖です (IMO、Microsoft はこれをやりすぎています。たとえばThread.CurrentCulture、それHttpContext.Currentは本当にアンチパターンであり、テスト容易性を損ないます)。

上記の状況に最適な WebJobs SDK は、インフラストラクチャ (バックオフ タイマー、ポイズン処理など) をサービスとして利用できるようにし、メインの制御フローが常にアプリケーションに残るようにします。これは、SDK のすべての機能で可能である場合とそうでない場合があります。私はそれを判断するのに十分なほど SDK を知りません。

2 つ目の理由は、開発者の利便性です。オフライン環境で作業することもある分散型チームがあります。私がこことここで読んだことから、ストレージ エミュレーターを使用して WebJob アプリケーションをローカルで実行し、メッセージをデキューする可能性はありません。私が今取っている自己ポーリングのアプローチでは、これは魅力のように機能します。

4

1 に答える 1

1

あなたのアプローチには何も問題はありません。これは機能し、WebJobs SDK が内部で行うことと非常によく似ています (指数バックオフ アルゴリズムがあります)。

SDK で複雑な環境の初期化はどのようなものですか?

于 2015-04-11T16:29:55.707 に答える