如何防止 azure 在其他实例准备好之前横向扩展它们？答案

【问题标题】：how to prevent azure from scaling out additional instances until they are ready?如何防止 azure 在其他实例准备好之前横向扩展它们？
【发布时间】：2018-04-12 00:13:35
【问题描述】：

我们遇到了 Azure 应用程序服务问题。我们的 Web 服务 (MVC) 之一在启动时缓存数据库中的数据 (Application_Start) - 这大约需要 3 分钟。在这准备好之前，我们无法处理请求。

这是已知的，因此我们将其设置为“始终开启”，并且旨在仅在必要时在非高峰时间重新启动它。

但是，我们预计下个月服务器的负载会很重，在我们对自动缩放的测试中，我们发现当它添加额外的实例时，这些实例中的每一个都会经历相同的启动延迟 - 但流量是在当前运行的实例和正在预热的新实例之间拆分，例如在这 3 分钟内，一半的请求开始失败。

我们如何配置 Azure 以延迟使用新实例，直到它准备好？（或者我们应该使用 AWS 等代替吗？）。

一些文档指出使用自定义负载均衡器探针，但它主要讨论的是虚拟机，而我们使用的是 PAAS。

【问题讨论】：

你能在缓存完成之前做一些类似于 302 重定向到主实例的操作吗？
它们都有相同的 url - 额外的实例对最终用户是不可见的
当然。我唯一能想到的另一件事是在网站前使用流量管理器，并在端点上线时启用/禁用端点。但这当然会给位于单个应用服务实例后面的多个实例带来问题。然后提出了其他问题——缓存了什么？如果它对于实例不是唯一的，是否可以将其移至 redis 之类的东西中？这样，您就拥有了一个数据缓存实例，并且网站将在大规模事件中立即可用
我花了很多时间试图让它与 REDIS 一起工作，但数据不适合键/值匹配（因为我正在做一个模糊匹配 - levenschtein distance over a large number键），所以在 RAM 中直接工作的速度要快得多，这很重要
我也尝试过使用 web.config 中的初始化，在加载数据之前我的预热不会返回，但它根本不会触发

标签： azure azure-web-app-service azure-app-service-plans

【解决方案1】：

请尝试减少您需要在 app_start 上加载的数据，并尝试在第一次请求时将数据延迟加载到缓存中。有时，即使在完成所有这些操作之后，我们最终还是会得到一开始就需要的大量数据。

我们有两种方法可以解决这个问题。

第一个，假设您正在使用内存缓存，并且应用程序的每个实例都需要在 App_Start 上填充其内存缓存。尝试使用像 Azure Cache for Redis 这样的外部缓存提供程序，您的新实例可以直接指向这个外部缓存，而无需重新加载数据。

二，您可以依赖 IIS 7.5 中引入的 Application Initialization Module（安装在 Azure App Services 的 IIS 上）。要使用此功能，您需要在 web.config 的 web.server 部分下添加 applicationInitialization 部分。这将帮助您在预热过程完成之前不使实例可用。有关如何使用 ApplicationInitialization 的更多信息，请访问this blog post

最好的情况是使用两者的组合，applicationInitialization 将指向您应用程序中的一个页面，该页面检查外部缓存是否可用并已补足，如果是，则完成，否则补足外部缓存。

【讨论】：

【解决方案2】：

我的建议是使用带有运行状况探测的 Azure 负载均衡器

【讨论】：

【解决方案3】：

其中一个 cmets 中包含的链接 https://www.jan-v.nl/post/warming-up-your-app-service 中有很多很好的信息。

根据该信息，您需要的功能在免费层中不可用。

我会以不同的方式处理这个问题。为什么从数据库加载数据需要 3 分钟？由于它仅在启动时加载，因此应该是不经常更改的数据。

你能：

优化从数据库中读取数据？
减少从数据库读取的数据量？
将数据导出到文件，然后从文件中读取？

【讨论】：

【解决方案4】：

您可以在 Azure 中使用除经典 VM 之外的其他资源类型（如应用服务）来执行此操作。应用服务通过共享相同内存池和线程池的实例进行扩展和缩减。

【讨论】：