构建具有多个角色的Azure解决方案

我很好奇其他人是如何构造（或建议构造）具有多个角色的Azure应用程序的。我特别好奇的是，你是如何让它们打破订阅和托管服务之间的界限的

在我的特殊情况下，我们有一个web角色托管一个webapp和API。这种情况变化很快，有时每天会发生多次。我们还有几个不同的员工角色来完成视频处理、电子邮件发送和报告/分析等工作。工人们很少变动，有时每月变动不到一次。我们在一个订阅中运行所有这些。每个角色都在其自己的托管服务中

此设置允许我们轻松部署一个角色，而不会影响其他角色。它还避免了不必要地中断工人角色，因为它们有时处于必须重启的长（10分钟）处理任务的中间。p> 你们是怎么做到的

---

我问这个问题的部分原因是，微软似乎希望您将所有内容都放在一个托管服务中。例如，预览中的新缓存功能仅在单个托管服务中可见，这使得它对于我当前的布局几乎毫无用处

这是一点意见，但我认为你有权这么做。为所有角色（原子更新、版本控制等）部署单个包肯定有好处。然而，在更复杂的场景中，我发现拆分成不同的部署和托管服务效果很好。如果您想要地理冗余，您必须有不同的部署

如果您小心地进行版本控制（假设您的部署可以通信），您可以轻松地进行不同的部署，并从更快的部署中获益。我们发现我们的工作者角色比我们的web角色具有更高的部署率，因此将web角色分开是有意义的。有了新的针对网站的Windows Azure功能，我们正在认真考虑将其进一步拆分，并从中运行我们应用程序的web部分。我们的API可以部署到那里，甚至可以部署到其他专用实例

---

我们唯一没有做的就是在订阅之间进行拆分。我认为这样做没有技术上的理由。也许有一种商业模式可以绕过配额，但现实是，订阅并不重要。但是，如果您使用Mgmt API为不同的托管服务使用不同的订阅ID，那么以后可能会非常痛苦。为了管理的目的，我还真不愿意混合和匹配来自不同订阅的存储和托管服务。这是一个好主意，可以将所有内容都放在同一个子模块中。

我在征求意见，谢谢你的建议！我绝对同意不在订阅之间拆分。我们很早就意外地这么做了，这让人很痛苦。不幸的是，这是一个很难恢复的错误，因为无法在订阅之间移动数据存储。