在没有任何第三方的情况下自行扩展的 Azure 应用程序的模式是什么？答案

【问题标题】：What's the pattern for an Azure application that scales itself without any third party?在没有任何第三方的情况下自行扩展的 Azure 应用程序的模式是什么？
【发布时间】：2012-02-16 20:44:46
【问题描述】：

我想让我的 Azure Web 角色以独立的方式进行扩展。

到目前为止，我看到的所有扩展解决方案都包括一些第三方 - 它可以是监视 Azure 角色并对其进行扩展的特殊服务，也可能是用于手动扩展的应用程序。我想要的是我角色中的额外代码，用于决定何时扩展和启动扩展。

我预见到以下问题。首先，在每个时间点应该只有一个角色实例来决定何时扩展以及如何扩展，这样两个或更多实例就不会造成扩展混乱。其次，如果该特定实例由于某种原因死亡，则必须在某个合理的时间内选择另一个实例。最后，所有的东西都不应该引入太多的开销。

是否有任何模式可以实现这种独立的缩放？

【问题讨论】：

标签： windows performance azure monitoring scaling

【解决方案1】：

我们已经在 Windows Azure 上运行 autoscaled apps 和我们自己的 provisioning lib 有一段时间了，甚至在 WASABi 发布之前。

目前为止最适合我们的模式包括以下几个方面：

不要相信任何低级指标（例如内存或 CPU 使用率）来定义您的扩展指标，制定一个简单但高度相关的指标来定义您的工作负载（以及所需的 VM 数量）。李>
在所有虚拟机之间保持严格的对称性（无主虚拟机或从属虚拟机）：每个虚拟机都可能负责更改正在配置的虚拟机数量。
每个 VM 都有一个处理自动缩放的后台线程。 99.999% 的时间，这个线程什么都不做。每分钟，线程都会尝试获取blob lease，然后运行配置逻辑。如果无法立即获得 blob 租约，请放弃，其他 VM 已经在上面了。
通过 Azure 实例化 VM 大约需要 5 分钟，并且会立即向您收取 1 小时的费用。我建议在去实例化时稍微懒惰，然后等待 30 分钟左右，10 分钟后去实例化没有任何好处。
配置 API 缓慢，请确保调用线程在此期间没有阻塞 VM 上的任何内容。
将 VM 的最小数量保持为 2 以延长正常运行时间。

【讨论】：

我要补充一点，您通常只希望在时钟小时结束时按比例缩小，因为您按时钟小时收费（意思是从下午 2 点到下午 3 点，从下午 3 点到 4 点），等等）。提出相关的扩展指标绝对是一个好主意，而不是使用 CPU 或 RAM。（队列非常适合后台处理器）。总体来说，落实。维护和监控自己的扩展是一个巨大的痛苦，每月花费 20-30 美元并将其外包 - 相信我，我会知道 :)

【解决方案2】：

您当然可以在您的网络角色中放置自动缩放代码。为了防止多个实例执行缩放逻辑，一种技术是使用 blob 租约形式的“互斥锁”（您只能有一个 blob 写入器）。

在每个实例中，都有代码尝试获取已知 blob 的租约。
获得租约的人都会运行缩放代码（可能是某种类型的计划检查，可能使用提到的自动缩放应用程序块 @tjrobinson）。
遇到异常的人会休眠并定期重试。如果持有租约的实例由于某种原因死亡，另一个实例将能够获得即将丢失的租约，并开始执行自动缩放代码。

【讨论】：

【解决方案3】：

最接近官方 Microsoft 解决方案的是 The Autoscaling Application Block，它是 Microsoft Enterprise Library 5.0 Integration Pack for Windows Azure 的一部分

Microsoft 企业库自动缩放应用程序块 (WASABi) 允许您向 Windows Azure 添加自动缩放行为应用程序。您可以选择将块托管在 Windows Azure 或本地应用程序。自动缩放应用程序块可以是未经修改即可使用；它提供了所需的所有功能在 Windows Azure 中定义和监控自动缩放行为应用。

企业库自动缩放应用程序块包括以下特点：

它允许您使用图形企业库配置工具来管理配置设置。

它允许您配置块使用的存储位置和日志记录机制。

它允许您通过添加自定义自动缩放规则和行动。

【讨论】：

如果没有第三方代理，这个东西会扩展吗？
@sharptooth 我不知道，抱歉。
是的。只需自己以非常小的角色甚至在本地进行托管即可。