我在 Azure 上有一个 REST Web 服务，其负载非常高但可变，它全部设置为使用 Paraleap 自动扩展，以便它可以处理高峰时段，但在较为安静时降低成本。
我从来没有找到一种方法，使用任何指标来预测服务器何时会开始达到极限前它实际上已经达到最大值！所以我现在的解决方案是一个单独的程序，它会不断检查服务器是否启动，如果它开始返回错误，那么它会告诉服务器开始向一定比例的用户返回错误消息，返回一个简单的错误会占用较少的服务器资源，从而使大多数用户仍然可以使用服务，然后它会告诉 Paraleap 增加实例数量。增加实例通常需要 10-15 分钟，因此在此期间情况并不理想，一些用户会遇到错误，但最终，新实例会启动并恢复正常服务。
我希望 Azure Traffic Manager 能解决我的问题，我希望我可以使用故障转移模式，当检测到我的主要 Web 服务出现故障时，我可以将 x% 的请求转移到备份，这将使主服务恢复到工作状态。同时，我会独立地告诉主 Web 服务进行扩展，当扩展完成后，流量管理器会将所有内容转移回主 Web 服务。换句话说，我会得到一个立即的增加容量，这将填补我启动新实例时的空白。
不幸的是，我似乎找不到办法做到这一点！看起来，流量管理器在检测到故障时，会将 100% 的流量转移到备份。因此，我需要将服务器容量增加一倍以上，以便应对这些情况，即为主 Web 服务配备 X 个实例，并在备份中等待 x+1 个实例，主服务器发生故障会将 100% 的请求转移到容量更大的备份，然后我会为主服务器启动更多实例，最终流量管理器会将所有请求发送回备份，此时我需要向备份添加更多实例并让它再次等待。这将是巨大的过度杀伤，会花费我一大笔钱！
有人对我如何更好地处理此事有什么建议吗？
谢谢！
答案1
史蒂文 - 听起来你需要花一点时间看看你的设置，你还需要考虑成本与可用性。
Azure VM 支持通过部署到的云服务进行自动缩放，并使用云服务自动缩放功能来驱动新实例的配置（这些实例必须能够自动配置）。可以在Azure 文档网站。
如果您发现在扩展之前返回错误，则需要为扩展触发器设置较低的阈值（例如较低的 CPU 阈值）或运行 N+1 配置，其中 N 是非负载使用场景的最小 VM 数量。这是为了减少特遣队你的 API。
如果您没有可用的正在运行的单元，那么您将永远无法达到瞬时规模。
最后，Traffic Manager 只能在您使用最低延迟路由的地方帮助分散负载，这意味着在不同的 Azure 地理位置运行 API 的不同实例。如果这不是您所需要的，那么 Traffic Manager 并不是解决方案。
答案2
全面披露：我是 Lars Larsson，Elastisys AB 的软件架构师。
你所描述的正是 Elastisys 云平台可以帮助你做的事情：它收集监控数据，并可以预测性地扩大规模以满足需求，而不是在服务已经受到影响时才做出反应。这些算法基于瑞典于默奥大学分布式系统小组进行的扎实研究。
然而，目前还不支持与 Azure 交互（我们的GitHub 页面）。
请联系 Elastisys如果您愿意在我们将 Azure 支持构建到我们软件的未来版本中时作为我们的用例。