Question

我知道当队列中有新消息时，会调用QueueTrigger个东西。但是，这种＆＃34;框架风格＆＃34; WebJobs让我很难正确地初始化我的环境。

这就是我想自己轮询队列的原因，基本模式是这样的：

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中连续运行时，此方法是否存在潜在问题？如果是这样，有什么可能的选择来避免＆＃34;框架式＆＃34; WebJobs吗

编辑

根据Victor的要求，这里有一些关于为什么我不想使用QueueTrigger方法的更多信息。基本上有两个原因。

上面已经提到了第一个，它是框架调用具有QueueTrigger属性的方法的事实。这意味着我必须在该方法中进行所有初始化。

我们的网络应用程序中有一个两阶段的IoC容器（每个应用程序和每个请求），我希望WebJobs尽可能贴近网络应用程序，所以我想使用WebJobs中的两阶段IoC（每个应用程序IoC执行一些繁重的初始化，然后在所有请求中重用）。这样做的结果是我必须将每个应用程序容器放在静态变量或单例中，以便我可以从静态QueueTrigger方法访问它。这是一个我不愿意做的设计怪癖（IMO，微软做得太多，例如Thread.CurrentCulture或HttpContext.Current - 这真的是反模式和伤害可测试性）。

针对上述情况的完美WebJobs SDK将使基础设施（退避计时器，毒物处理等）可用作服务，以便主控制流始终保留在应用程序中。这可能适用于SDK的所有功能，也可能不适用，我不太了解SDK，无法判断它。

第二个原因是开发人员方便。我们有一个分布式团队，有时可以在离线环境中工作。从我读过here和here开始，就不可能在本地使用存储模拟器运行WebJob应用程序并让它出列队列消息。通过我现在采用的自我调查方法，这就像一个魅力。

Answer 1

你的方法没有错。它可以工作，它与WebJobs SDK的工作方式非常相似（我们有一个指数退避算法）。

我很好奇，SDK的环境初始化很复杂？

从WebJob对Azure存储队列进行轮询和休眠

1 个答案: