在我公司，我们的主要产品是基于 Web 的，每个客户都有自己的网站。每个客户都通过 customer.domain.com 访问他们的网站。目前，在 IIS 中，每个客户都设置了自己的网站，并为该网站中的所有应用程序分配了一个应用程序池。我们的许多客户都使用相同的代码库，但有些客户使用的是较新的版本（beta 测试人员）。
我们还使用负载平衡，以便每个请求都可以到达任何一个 X 服务器。
这是最理想的设置吗？主要问题之一是我们的服务器上只有大约 8 GB 的 RAM，但客户端数量也大约为 200 个，因此对于每个应用程序池，我们必须将其可使用的内存量限制为 300MB 左右，以免内存耗尽，但这也会导致应用程序池频繁回收。
我们希望向外扩展，而不是向上扩展，但随着我们添加越来越多的客户端，我们可用的 RAM 就会越来越少，或者我们将不得不开始向服务器添加大量 RAM。
如果您有类似的设置，您是如何解决问题的？
答案1
我们在同一台机器上为不同的客户设置了多个不同的网站，这些网站使用不同的域名。我们从一个文件夹和一个应用程序池运行它们，因为它们都共享一个代码库。
对于想要查看测试版代码的客户，我们还设置了一个临时站点，他们可以登录并查看（如果该站点上已为他们设置了帐户），该站点具有一组不同的 FQDN。因此，我们最终拥有两个网站和两个应用程序池。
基本上，您需要做的就是设置 IIS 以监听多个 IP，并根据需要为每个 IP 设置证书。这样，数据只会缓存一次。
答案2
这将取决于您的环境，具体来说，我们谈论的服务器数量、服务器是否为 64 位，以及应用程序的稳定性如何。
我看到三种选择：
- 继续在独立的应用程序池中运行所有内容，在所有服务器上保持平衡，并添加更多 RAM。
优点：强大。
缺点：成本（但如今 RAM 已经变得相当便宜） - 整合到更少的应用程序池中，在所有服务器上实现平衡，并且不添加额外的 RAM。优点：无需额外费用。
缺点：如果应用程序存在稳定性问题，将 200 个客户端整合到 2 个或 3 个应用程序池中可能会引发灾难。如果您的负载平衡器可以正确检测应用程序的可用性并将状态更改应用于所有 URL，则可以减轻此风险。此外，如果这些计算机是 32 位的，在单个应用程序池中运行 100 多个客户端可能会使您接近进程内存限制。 - 继续在独立的应用程序池中运行所有内容，将您的服务器场分成子服务器场，即不是让 6 台服务器服务 200 个客户端，而是让 2 组 3 台服务器每组服务 100 个客户端，以减少内存负载，并且不添加额外的 RAM。
优点：强大，无需额外成本（只要您有足够的服务器！）。
缺点：如果您没有至少 4 台服务器，这将是一个昂贵/没有吸引力的选择。此外，您还会引入新的问题，例如必须跟踪哪些特定客户端的使用率高，并在多个服务器场之间平衡这些客户端。
答案3
最简单的解决方案是首先将您的 Beta 站点移动到自己的一组服务器上，然后研究将当前用户分成几组的方法。
客户 1、2、3、4 均访问服务器 a、b、c 客户 5、6、7、8 均访问服务器 d、e、f
等等，这样你就有了冗余，你的客户也得到了负载平衡
如果你想更详细地了解可视化效果，可以使用类似VMware ESX 操作系统因此，您可以在集群中拥有 3 台服务器，然后根据需要构建任意数量的 Web 服务器，甚至可以为每个客户创建一个专用的虚拟服务器，但这更像是一种纵向扩展解决方案