为什么更新已停止的 Azure 部署需要这么长时间？答案

【问题标题】：Why does updating a stopped Azure deployment take so long?为什么更新已停止的 Azure 部署需要这么长时间？
【发布时间】：2011-10-12 11:24:19
【问题描述】：

完成 Azure 部署 takes a while for a reason，但这就是我要做的。

我停止部署，然后当它处于“停止”状态时，我单击“升级”并选择服务包。部署进入“升级”状态，最多需要三分钟才能完成，然后进入“停止”状态。我必须点击“开始”并等待几分钟才能开始部署。

我不明白。升级之前不需要停止部署 - 它已经停止。升级后未开始部署。那么什么需要三分钟呢？

【问题讨论】：

【解决方案1】：

为什么要停止部署？升级的重点是获得零停机时间。您只需选择升级，然后在升级域中进行手动或自动滚动升级。只有新部署需要停止/删除。

【讨论】：

这里的场景是：我升级我的部署，看到角色不会启动，并且会在循环中重新启动，将大量错误消息写入日志。我阅读了日志并确定了问题，我需要时间来修复我的代码并重新部署角色。在重新部署之前，我不希望角色重新启动并继续将消息写入日志。因此，一旦我知道该怎么做，我想尽快停止这个角色。
那么您就错过了升级的好处。使用手动升级方法，检查您的日志，如果出现错误，则只需在 1 个升级区域后停止升级。接下来，将原始包重新应用于部分升级的部署（升级区域 1），您将恢复到原始状态。现在您可以修复升级并稍后重试。同样，无需停止。
体力劳动太多了。而且我也不问如何充分利用 Azure 门户。我只是很好奇为什么要花三分钟来完成看似微不足道的事情。
不太确定该说什么。在 6 分钟内跨服务器重新部署整个应用程序...？我想如果你想要更快的东西，你需要投资创建自己的通用工作者角色，从 blob 中提取其二进制文件（我有我自己的）。 Smarx 在某个地方有一个……也许是 smarxrole？这些会在一分钟左右更新。

【解决方案2】：

我认为原因是因为自动升级非常小心，以确保您可以在升级过程中随时重新启动 Azure 服务 - 因此单独升级各个升级区域仍然需要时间。

【讨论】：