azure-web-app-service - Azure Web Apps 上的网页设计机构/创意机构的标准设置是什么？

Question

背景

我们公司设计和托管网站约。 500个客户，每个客户有一个网站。每个网站都建立在 ASP.net 上。我们当前的托管基础​​架构建立在虚拟机管理程序上，虚拟机运行 Windows。我们有 3 个运行相同规范的虚拟机(8 个内核，24 GB RAM)。 500 个客户端站点分布在这三个 Web 服务器上，没有负载平衡或容错——该网站仅存在于一个位置。

因此，随着我们积累客户端，每个 Web 服务器的站点数量都会增加。当我们最大化每台服务器时，我们将另一台服务器联机并重新启动，然后一旦该服务器已满，我们就会启动另一台 VM，等等。

目标

我们希望(最终)将我们的站点迁移到 Azure，但是我们不想在 Azure 上复制我们当前的设置，而是希望将每个网站迁移到 Azure Web 应用程序，而不是利用缩放的优势。

我们还希望在将其他网站上线时更精细地控制我们的成本。目前，我们将虚拟机联机并花费 X(对于空服务器)，我们可能需要 3 个月的时间来填充它。我们希望稳步增加我们的托管主机，而不是大步。

我的问题

我已经对此进行了很多天的调查，但找不到有关托管 100 个网站时 Azure Web 应用程序上的理想设置是什么样子的教程或指南。几乎所有教程都假设您只会拥有一个网站，因此网站和底层资源之间存在 1:1 的关系。他们从不谈论您应该如何将您的应用程序组织成应用服务计划等。

我理解添加网站、选择适当的定价层和设置规模设置的概念，但我不明白的是为什么网上人们谈论扩展 Azure 应用程序——当然如果 ASP.net 网站消耗一定数量的 RAM一个系统，通过使另一个 VM 联机，您所做的就是立即在另一个系统上再次消耗该数量的 RAM。因此，从这个意义上说，向外扩展只是为了提高可用性——这是正确的吗？

如果有人能够在处理 Azure 上的大量网站时提供一些自己的经验(如果他们拥有一家在 Azure 上托管的网页设计公司就更好了)，我们将不胜感激。

Answer 1

将 AppService 计划视为同时运行相同应用程序并共享相同数据磁盘的 VM 或 VM 池(如果您运行多个实例)。如果向外扩展，则会向池中添加一个新 VM，如果向上扩展，则会更改 VM 的大小(实际上它们不是 VM，但从用户的角度来看是相似的)。

所以基本上在像你这样的情况下，你运行许多应用程序(可能)较小的应用程序，按比例放大/缩小建立基线 - 你可以运行多少网站，你可以在内存中容纳多少应用程序。然后横向扩展为您提供更好的可靠性和更多的 CPU 能力，帮助您应对高流量。

我们公司比你们小得多，我们托管了几十个网站，而不是几百个。但是我们的经验告诉我们一些要点:

至少使用具有 2 个内核的 S2 实例，对于 S1 实例，单个应用程序很容易降低同一 AppService 计划中其他应用程序的性能

使用流量管理器。如果有需要(例如您所在地区的服务中断)，您可以轻松移动到另一个地区

在更小的 AppService 计划之间拆分网站，并搭配使用模式与 AppService 计划相似的应用程序。这样，您可以在流量较低时运行一个实例，并在流量激增时启动新实例。