首页 > 解决方案 > Azure 应用服务部署槽的用例 - 应用版本的变化

问题描述

我阅读了 Azure App Service 上的 Deployment Slots,所有文档和文章都指出这些可用于应用程序的 Prod 和 Stage 版本之类的东西,在测试后将 Stage 交换为 Prod 以将其提升为 Prod。

但这是唯一的用例吗?例如,我们有一个托管在 Azure 应用服务上的 Web 应用。现在我们需要针对特定​​目的对该应用程序进行变体。它永远不会与生产槽交换。它基本上将作为两个独立的应用程序共存。

可以这样使用部署槽吗?有什么缺点吗?在我看来,这似乎是一种在应用服务中托管两个或多个 Web 应用程序而无需创建多个应用服务(因此成本更低)的方法。

标签: azureazure-web-app-service

解决方案


从技术上讲,我相信可以按照您的建议进行操作,因为每个部署槽都承载您的应用程序的完整功能版本,并且您可以使用 此路由方法访问特定槽。您只需将每个环境部署到其自己的插槽,并且永远不会交换它们。

您可以免费创建其他 Web 应用程序。您只需为 App Service 计划付费,并且您可以在该计划上运行任意数量的 Web 应用程序,因此您最好为每个环境创建单独的 App Service,因为它们都是非生产,您可以在同一个应用服务计划中安全地运行它们。

您可以WebApps在一个App Service Plan. 所有这些 WebApps (/websites) 都将有自己独立的默认域 (FQDN),您还可以为每个 WebApps 设置自定义域。

App Service – 使您能够构建和托管 Web 应用程序、移动后端和 RESTful API 的服务。
应用程序– 您的个人应用程序 (WebApps),这些应用程序在应用服务计划中运行。
应用服务计划 - 应用服务计划 (ASP) 定义一组计算资源以供 Web 应用运行。

由于您为应用服务计划分配的计算资源付费,因此您可以通过将多个应用程序放入一个应用服务计划来潜在地节省资金。只要计划有足够的资源来处理负载,您就可以继续将应用程序添加到现有计划中。但是,请记住,同一应用服务计划中的应用都共享相同的计算资源。

如果它们是单独的 WebApp,则管理单独的 WebApp 比通过虚拟子目录/路径或主机名或子域更容易。使用应用服务计划功能(在层下提供许多应用)以节省成本。

缺点:

  1. 根据您使用的计划层级,在应用程序服务计划中托管应用程序的数量存在限制,例如,如果使用共享计划层级和免费层级,您可以在同一个应用程序服务计划中最多托管 100 个应用程序,您在应用服务计划中按应用重新收费。有关更多详细信息,请参阅
  2. Azure 维护要求服务器至少每月重新启动一次或更多次。如果您的所有应用程序都在共享计划中,则补丁重新启动可能意味着整个系统已关闭,并且所有应用程序在同时启动时竞争资源
  3. 应用程序的部署和重新启动可能会导致计划(即服务器)的 CPU 峰值。如果您的应用程序对性能敏感并且您经常部署,您可能需要更多的分离。

笔记:

  1. 使用单独的计划作为环境边界,因此生产计划与测试计划分开。“测试”应用程序继续测试计划,“产品”应用程序在生产中,以防止测试影响用户。

推荐阅读