持续每分钟网页抓取至Azure SQL托管实例：选Azure Functions还是VM？

一、针对每分钟1MB数据抓取任务的选择 #

优先选Azure Functions（Timer Trigger），原因很直接：

• 完美适配定时需求：用CRON表达式0 * * * * *就能实现每分钟自动执行，不用自己在VM上搭建cron/任务计划，Azure自带的调度可靠性拉满。
• 成本碾压VM：你的任务每次执行时间极短（抓取1MB数据+写入SQL，撑死几秒），Functions按执行时长和资源用量计费，每月成本几乎可以忽略；而VM需要24小时持续运行，哪怕是最低配，成本也比Functions高一大截。
• 运维省心：不用管VM的系统补丁、服务器监控、启停故障，平台全托管，你只需要写抓取和入库的Python代码就行。
• 弹性足够：如果以后抓取量变大，Functions会自动扩缩容，不用手动升级VM配置。

至于VM，只有当你有复杂的依赖环境（比如需要特定版本的系统库、持续运行的代理服务）才需要考虑，但你的场景完全不沾边，用了纯纯浪费资源。

二、结合后续Dash实时展示应用的架构建议 #

Dash应用需要持续运行的Web服务，建议和抓取任务做解耦架构：

1. 抓取任务：继续用Azure Functions，把数据写入Azure SQL托管实例。
2. Dash应用：部署到Azure App Service（Web Apps），用Dash的dcc.Interval组件设置每分钟触发回调，直接从Azure SQL读取最新数据更新页面。

这种方案的好处：

• 两个服务独立运维，抓取任务出错不会影响Dash展示；Dash需要扩容也不用动抓取任务。
• 技术栈统一（全Python），代码复用性高，比如读取SQL的逻辑可以在Functions和Dash里共用。

如果非要硬凑到VM上，也可以在VM上同时跑定时脚本和Dash服务，但缺点很明显：VM必须24小时运行，成本高；抓取脚本的资源占用可能影响Dash的响应速度；还要自己负责VM的稳定性，完全没必要。

额外细节提示 #

• Functions里连接Azure SQL时，把连接字符串存在应用密钥里，别硬编码在代码里，安全又好维护。
• Dash的实时更新可以调整dcc.Interval的interval参数，和抓取频率匹配就行，避免不必要的SQL查询。

内容的提问来源于stack exchange，提问作者micoconnell