经过对Azure文档的深入研究后，我们仍然遗漏了Azure内置云服务自动扩展如何工作的一些重要细节。我们的云服务是具有单一Web角色的简单ASP.NET应用程序。默认情况下，我们部署到2个实例以获得SLA覆盖率，而不是按CPU使用率逐个扩展或缩小一个实例。我们使用启动任务来配置IIS并在csdef中定义它们。我们使用RoleEntryPoint在OnStart事件中指定自定义预热逻辑。我们确信启动任务和OnStart不会出现错误。
以下问题来自我的观察，旨在澄清这是否是预期的行为。
当云服务向上或向下扩展时，每个实例当前都将从负载均衡器中取出一段短时间，并且不会服务器请求。这是真的吗？
topologyChangeDiscovery =＆＃34;稻瘟病＆＃34;在csdef中，不会更改此行为，并且在扩展操作期间仍会从负载均衡器中取出实例。这是真的吗？
如果云服务中有N个实例，并且它会扩展到N + 1，那么只有N-1个实例可以提供请求。此时间等于N *（单实例配置更改所需的时间）。这是真的吗？
有没有办法设置自动缩放功能，以确保当前处于云服务中的所有实例都能在规模操作期间不间断地处理请求？ （无论如何不仅使用Azure内置自动缩放）
更新
我已执行测试以实际检查在比例事件期间哪些实例正在处理请求。简单的控制台应用程序轮询云服务并记录响应请求的实例。我已将Azure门户中所有更改的屏幕截图添加到日志文件中。
结果如下： 从2个实例扩展到3个实例： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a#file-scaleuplog_withscreens-txt
从3个实例缩小到2个实例： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a#file-scaledownlogs_with_screens-txt
控制台应用源代码和日志格式说明： https://gist.github.com/samfromlv/8029ff0b3fdb3e6bd02a
答案 0 :(得分：0)
当您处理从1个实例缩小到1个实例或从1个实例向上扩展时，您将遇到不愉快的结果，这是因为Azure将现有的“好”实例从负载均衡器中取出。
假设您只处理2个以上的实例而且从不缩减到2个以下的实例，这里有一些基于5年运行Azure的AzureMonix / AzureWatch自动扩展服务的响应
如果只剩下1个奖励，如上所述
爆炸应该对负载均衡器影响不大。但是，如果在发生拓扑事件时所有实例都重新启动，请确保在Web / WorkerRole.cs中的拓扑更改事件期间不小心返回“true”以进行重新启动
如果您有N个实例，其中N＆gt; = 2，并且它可以扩展到N + 1，那么大约需要10分钟才能到达N + 1。在这种情况下，你不应该有N-1个活跃的。有一个来自Microsoft的文档解释了它可以快速扩展到多个实例，但它与启动实例计数无关，但与它旋转的新实例数量相关。我相信有多达100个新实例可以保证在30或60分钟内完成。不要引用我的话。
您可以使用第三方服务，例如我所属的第三方服务CloudMonix。但在所有情况下，当您处理1个实例并尝试向下缩小或向上缩小时，标准缩放问题就适用。
HTH