我对部署槽有一个疑问，因为我试图弄清楚我是否愿意使用部署槽。在我们的团队中，我们倾向于为大多数Web应用程序提供3种环境：
当前，我们仅获得一个应用服务资源。由于我们想维护在上述3个环境中部署的3个版本的应用程序代码，我想知道是否可以利用3个单独的部署插槽，还是要创建3个单独的Web应用程序？
从文档中我知道部署插槽是用于快速测试，然后将其交换到生产中的，但是由于我们目前仅限于Web应用程序的单个实例，因此我正在考虑利用部署插槽。
我想知道您对此的想法，以及是否应该为此类情况选择新的应用程序服务或广告位。
答案 0 :(得分：2)
从技术上讲，我相信您可以按照您的建议进行操作，因为每个部署插槽都托管应用程序的完整功能版本，并且您可以使用this routing method访问特定的插槽。您只需将每个环境部署到其自己的插槽中，而无需交换它们。
但是，没有理由这样做。您可以免费创建其他Web应用程序。您只需支付App Service计划的费用，并且可以根据需要在该计划上运行任意数量的Web应用程序，因此最好为每个环境创建一个单独的App Service，因为它们都不是生产中，您可以安全地在同一App Service计划中运行它们。
答案 1 :(得分：2)
只需添加分隔即可，这是更灵活且可能更安全的方法。如前所述，没有成本差异。但是，我想指出的是，如果Web应用程序确实是3种不同的环境，那么它们应该是3种不同的应用程序服务。这样一来，您就可以在每个环境后都有一个数据库，为每个环境分配一个Identity，为每个环境分配Application registration，并可能为每个环境使用不同的access restrictions规则。
实际上，将它们分离出来可能会节省成本，因为DEV中的应用程序服务可能比PROD中的应用程序更小。或可以在不使用DEV时将其删除，并在进行处理时通过ARM重新部署。
在Microsoft Best Practices on app service slots中，它使用以下广告位进行调用：
- 您可以先在临时部署插槽中验证应用程序更改，然后再将其与生产插槽交换。
- 首先将应用程序部署到插槽中并交换到生产环境中，以确保在插槽中的所有实例均已预热 被交换到生产中。这样可以消除停机时间 部署您的应用。流量重定向是无缝的，并且没有 由于交换操作，请求被丢弃。您可以自动化 通过在预交换时配置自动交换来完成整个工作流程 不需要验证。
- 交换后，具有先前上演应用的广告位现在具有先前的生产应用。如果更改被交换到生产中 插槽不符合您的预期，您可以执行相同的交换 立即获得您的“最后一个知名站点”。
为进一步说明部署，Blue-green deployment or canary releases应使用插槽，此链接用于DevOps部署，但相同的概念适用于应用程序服务插槽。
当然，缺点是可能会增加一些开销和管理。如果单独的应用程序服务可能会分开DNS记录，网络规则，SSL证书等。