如果 Azure 应用服务计划是专用于其中定义的 Web、API、逻辑和移动应用程序的虚拟机,这是否意味着应用服务计划中的 Web 应用程序是该虚拟机上 IIS 中的虚拟 Web 服务器实例?
假设是这种情况,并且每个虚拟网站都有自己的应用程序池,是否存在 Azure 扩展策略或方案,其中该应用程序池中的多个工作进程将运行,从而创建一个网络花园?我对 Web 应用横向扩展的理解是,它会导致分配额外的虚拟机,而不是额外的工作进程。
如果 Azure 应用服务计划是专用于其中定义的 Web、API、逻辑和移动应用程序的虚拟机,这是否意味着应用服务计划中的 Web 应用程序是该虚拟机上 IIS 中的虚拟 Web 服务器实例?
假设是这种情况,并且每个虚拟网站都有自己的应用程序池,是否存在 Azure 扩展策略或方案,其中该应用程序池中的多个工作进程将运行,从而创建一个网络花园?我对 Web 应用横向扩展的理解是,它会导致分配额外的虚拟机,而不是额外的工作进程。
扩展策略将取决于您选择的定价层。
基本上,每个服务计划都将包含 Web、API、逻辑、移动应用程序的集合。这些将在您选择的服务计划服务器中形成一个网络花园。
如果您最初选择一个 B1 基本服务计划,您将获得一个虚拟机,所有应用程序都在该虚拟机上运行。随着该服务器上的负载增加,您可以将其扩展到更大的服务器,但它仍将在单个服务器上运行。
如果您随后选择创建第二个实例(以及第 3 个、第 4 个、第 5 个...),则第二个服务器将是第一个服务器的副本,负载在两者之间平衡。(3,4...)
虽然我没有看到这方面的文档,但我想每个 Web、API 等应用程序都在其自己的应用程序池/工作进程下运行,并且横向扩展只是重复的实例。
我不确定虚拟服务器是什么,但每个应用程序都在其自己的专用应用程序池和 w3wp.exe 进程中运行。每个应用程序池只有一个 w3wp.exe 进程,因此没有网络花园。
您认为需要这些来扩展您的应用程序是否有特定的原因?在大多数情况下,使用网络花园是错误的扩展方式,因为添加更多进程会导致不必要的开销(以及其他问题 - 您可以在网络上找到一些有用的资源)。您几乎总是希望使用线程而不是进程来提高并发性。如果您的物理资源(CPU、内存等)用完了,那么正确的扩展方法是添加额外的虚拟机。