Question

我有一个.NET Core Console应用程序，我需要将其部署到Azure并安排每天运行一次。该应用程序正在创建TCP Socket以获取市场数据。我需要安排它在早上运行，应用程序将在当天结束时从市场收到一条关闭消息并自动关闭。大约运行时间估计为每周5天，每天16小时。

以下是我研究过的选项：

Cloud Service，可能已被弃用（我很难验证我已经阅读过的评论）
Service Fabric - 但这看起来非常适合无状态应用程序，可以按比例缩小规模。在我的情况下，它应该始终是一个单独的实例（我喜欢自我＆＃34;愈合＆＃34;，如果我的服务确实失效，如果它自动重启或新的旋转会很好）
Azure Web作业和azure调度程序。 It looks like I could set this to "always on" and add a settings file that has cron configuration，但它似乎是浪费资源，而且总是在＆＃34;。此选项似乎也受限于其部署选项 - 我无法设置（我看到）git集成和自动部署。 This does seem like the way to g 0

我正在为我的用例或我可能错过的任何其他选项寻找以上这些选项中的专业人士和其他选项。

Answer 1

这里有一件事似乎被忽略了。这部分：

应用程序正在创建TCP套接字以获取市场数据。

是80 / TCP还是443 / TCP？它是否通过其中一个端口与HTTP通信？因为如果您的应用程序通过任意TCP端口谈论自定义协议，则无法使用 WebJobs 。 App Service沙箱不允许任意端口绑定。这适用于入口。出口（出境），没有限制。您可以将原始TCP请求从 WebJob发送到任何目标和端口。

来自https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#network-endpoint-listening：

网络端点监听

通过互联网访问应用程序的唯一方法是通过已经公开的HTTP（80）和HTTPS（443）TCP端口;应用程序可能无法在其他端口上侦听来自Internet的数据包。

无需涉及Azure Scheduler服务。 WebJobs有built-in cron implementation，完全免费。

此外， Always On 功能实际上意味着每隔几分钟使用合成请求访问此站点，因此它可以提供200 OK，从而防止应用程序池从内存中卸载不活动。

我会使用 tank 。如果可以pick your tank size，那么坦克找不到任何问题。坦克的维护也很少。

Size (id)     Cores   Ram       Net Bandwidth   Total disk size
---------------------------------------------------------------
ExtraSmall    1       0.75 GB   Low             19 GB
Small         1       1.75 GB   Moderate        224 GB
...

ServiceDefinition.csdef如果您需要在套接字上收听：

<Endpoints>
  <InputEndpoint name="aRawTCPEndpoint" protocol="tcp" port="54321" localPort="54321" />
</Endpoints>

您的申请在哪里保持状态？内存/磁盘/现成的数据库？云服务角色本质上是无状态的，如果一个实例生病，那么它就是barbecued，并且新的一个实体就会生成。在持久存储中保持开箱即用状态至关重要 - Blob / Table存储，Azure SQL，DocumentDB等。

想象一下，你在6年前建造了自己的房子。并且您在结构中使用了名为 ClassicBrick 的材料。它是一种很好的材料，坚固，防水，防刮。但是最近这个更新更好的材料 - 让我们称之为 Armritis （顺便设计用于BRIDGES而不是房子，但我离题）出来了，每个人都告诉你在各方面都更好。你拆掉房子了吗？云服务不会被弃用，直到我看到微软的官方路线图告诉相反的情况我不会以任何方式接受这一点。

关于 Service Fabric 的主题，它可以做有状态的，它实际上是它最大的卖点之一：

来自https://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-quick-start/：

创建有状态服务

Service Fabric引入了一种有状态的新服务。有状态服务可以在服务本身内可靠地维护状态，与使用它的代码位于同一位置。 Service Fabric高度提供State，而无需将状态持久保存到外部存储区。

如果您可以通过标准端口说HTTP，那么

Azure Functions 也值得一看。

Answer 2

首先，如果您不想浪费资源，我们需要比较Cloud Service，Service Fabric，Web job＆amp; Scheduler之间的定价。 Here是定价计算器。因为您的控制台应用程序作业将具有特殊的调度程序时间。如果工作不起作用，最好省钱。因此，Web作业（如果您有Web应用程序）和＆amp; Scheduler将是实现您目的的不错选择。

Answer 3

使用云服务完成这么小的工作就像使用坦克去上班

Service Fabric主要用于构建微服务样式应用程序，而不是每天运行一次的控制台应用程序或作业

Web Jobs需要一个Web应用程序，因此您有剩余的选项，这是Web作业的基础。

您可以创建计划程序并使其在特定时间每天运行或按需手动执行

Answer 4

我会选择一个解决方案，优先考虑：

App Service: Web Apps (Web Job)
Virtual Machine
Cloud Service

App Service: Web Apps (Web Job)提供免费计划。它开始在免费计划中支持Web Jobs。如果需要，您将能够处理文件。正如其他答案中所提到的，只需设置scheduler即可。如果您怀疑并认为它不是 Kosher 在网站上进行，那么可以将其视为获得免费网站（如果您使用付费计划）作为奖励。无论哪种方式，一切都在一台机器上运行 - 无论是web服务器还是没有。也许你甚至会开始一些很久以前被遗忘的网络项目？

Cloud Service和Virtual Machine既简单又简单。说实话，我还没有使用Cloud Service，但我认为你可以通过Remote Desktop连接它，就像普通的虚拟机一样。你将完全控制。我会选择Virtual Machine而不是Cloud Service，只是因为它更便宜。

不起作用的解决方案：

Azure Scheduler不适合您，因为它只允许HTTP / S请求，并且将消息发布到Azure存储队列，Azure Service Bus队列或Azure Service Bus 。

Answer 5

就个人而言，我会使用没有AlwaysOn的WebJob，并使用Azure Scheduler使用HTTPS在所需的时间触发WebJob。然后WebJob可以执行获取数据所需的调用。这不需要AlwaysOn，因为调度程序调用无论如何都会唤醒它。

Azure功能也可能值得一看，但它们并不适用于长时间运行的任务。

这也可能是最便宜的选项，因为Web App可能在Free层上运行（取决于作业需要多长时间），而Scheduler也可以是Free tier。

用于长时间运行的计划作业的Azure资源类型

5 个答案: