【问题标题】:Structuring Azure solution with multiple roles构建具有多个角色的 Azure 解决方案
【发布时间】:2012-06-11 15:16:18
【问题描述】:

我很好奇其他人如何构建(或建议构建)具有多个角色的 Azure 应用程序。特别是我很好奇你是如何让他们在订阅和托管服务之间破坏我们的。

在我的特殊情况下,我们有一个托管 web 应用程序和 API 的 web 角色。这种变化很快,有时每天多次。我们也有几个不同的工作角色来做视频处理、电子邮件发送和报告/分析等工作。工人很少更换,有时一个月不到一次。我们在一个订阅中运行所有这些。每个角色都在其自己的托管服务中。

此设置让我们可以轻松部署一个角色,而不会影响其他角色。它还避免了不必要地中断 Worker 角色,因为它们有时处于必须重新启动的长时间(10 分钟以上)处理作业的中间。

那么你们是怎么做到的呢?

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

【问题讨论】:

    标签: azure azure-worker-roles azure-web-roles


    【解决方案1】:

    这是一些意见,但我认为您有权这样做。为所有角色(原子更新、版本控制等)部署单个包当然有优势。但是,在更复杂的场景中,我发现拆分成不同的部署和托管服务效果很好。如果您想要异地冗余,则无论如何都必须进行不同的部署。

    如果您对版本控制非常小心(假设您的部署进​​行通信),您可以轻松地进行不同的部署并从更快的部署中受益。我们发现我们的工作角色比我们的 Web 角色具有更高的部署率,因此将 Web 角色分开是有意义的。借助用于网站的新 Windows Azure 功能,我们正在认真考虑将它们进一步拆分,并从中简单地运行我们应用程序的 Web 部分。我们的 API 可以去那里,甚至可以部署到其他专用实例。

    我们唯一没有做的是在订阅之间拆分。我认为这样做没有技术上的理由。可能有一个企业可以绕过配额,但现实情况是订阅并不重要。但是,如果您使用 Mgmt API 为不同的托管服务使用不同的订阅 ID,那么以后可能会很痛苦。出于管理目的,我也很犹豫混合和匹配来自不同订阅的存储和托管服务。将所有内容保存在同一个 sub 中可能是个好主意。

    【讨论】:

    • 我在征求意见,谢谢你的意见!我绝对同意不拆分订阅。我们不小心在早期就这样做了,这很痛苦。不幸的是,这是一个很难恢复的错误,因为无法在订阅之间移动数据存储。
    猜你喜欢
    • 2020-06-29
    • 1970-01-01
    • 1970-01-01
    • 2014-09-09
    • 2023-03-17
    • 1970-01-01
    • 1970-01-01
    • 2011-12-24
    • 1970-01-01
    相关资源
    最近更新 更多