azure停滞和生产环境的主要区别是什么，特别是对于启动任务？

有谁能告诉我，当我们将暂存切换到生产环境时，内部发生了什么

问这个的原因,， 当我在登台环境中进行测试时，一切正常。 但是，当我在web.config和在后台运行的exe（启动任务）的配置文件中进行更改，然后切换到生产时，它无法正常工作

例如： 我有一个邮件设置，在暂存中它类似于 Mystaging.cloudapp.net 我将其更改为MyLive.cloudapp.net，然后切换，当我收到邮件时，它是display mystaging.cloudapp.net

---

基本上，我想知道，当您切换时，web.config和Bin目录会发生什么？

只会发生一件事-部署接受传入HTTP请求的URL更改。没有其他内容-没有重新启动，没有配置更改，什么都没有。这只是请求路由的更改

---

生产部署和登台部署是无法区分的（除非您非常努力）-它们存在，这样您就不会在需要升级时关闭服务。您可以创建一个暂存部署，运行基本检查，然后在暂存和生产之间切换—服务一直在运行并接受请求。这是分段部署的唯一真正目的。它们不是用于测试，而是用于无缝更新您的服务。

当您切换时，只会发生一件事—部署接受传入HTTP请求的URL更改。没有其他内容-没有重新启动，没有配置更改，什么都没有。这只是请求路由的更改

---

生产部署和登台部署是无法区分的（除非您非常努力）-它们存在，这样您就不会在需要升级时关闭服务。您可以创建一个暂存部署，运行基本检查，然后在暂存和生产之间切换—服务一直在运行并接受请求。这是分段部署的唯一真正目的。它们不是用于测试，而是用于无缝更新您的服务。

除了一件事之外，环境是相同的：它们有不同的VIP地址（在loadbalancer上公开的IP地址）。当您交换VIP时，负载平衡器将被重新编程，以便在临时部署和生产部署之间切换VIP—仅此而已。DNS没有任何变化

还有一些细微差别。例如，现有的连接没有（应该）被切断。所以，如果您有一个长时间运行的开放连接，它将在VIP交换期间继续。这可能会导致以下情况：a.）交换后，连接正在访问“较旧”的环境；b.）在某些情况下，这也会导致VIP交换操作本身持续一段时间（通常速度相当快）

这两个环境的初衷是简化升级部署。您将在staging中启动另一个更新的部署，进行一些测试，然后切换。大部分用户都不会注意到任何东西。但是，您不使用此模式有一些原因：

如果更改外部端点（例如，在暂存中添加端口443），则不能使用此模式。在这种情况下，您必须删除/new deploy-记住负载平衡器刚刚被重新编程，因此端点必须匹配。这一限制可能会在未来消失，谁知道呢

如果您有长期运行的、有状态的服务。VIP交换显然会将整个部署转移到生产中。如果你在一个工人岗位上工作了一个小时，需要以某种方式与客户前端进行沟通，那么你可能会在这里遇到问题

版本控制约束。想象一下，如果您在staging中启动另一个环境，该环境可以处理与生产相同/相似的数据。现在，当您准备制作交换机时，请将连接字符串连接起来，以便环境处于“生产就绪”状态。当您这样做时，您将有两个不同的部署开始处理相同的数据。例如，当使用同一队列时，这一点变得非常明显。在前端更改以更新消息格式或某些其他不兼容之前，暂存中的工作角色开始处理生产消息。当较新的部署开始处理较旧的数据和错误时，会出现版本控制问题。这不是无法克服的，只是一个你需要思考的问题

如果您有（非常）大型部署。想象一下，如果您有几百个实例。在这种情况下，很难进行VIP交换，因为a.）在登台过程中需要花费很长时间才能完成这么多VIP交换，b.）因为运行的实例是2倍，所以成本很高，c.）由于订阅配额限制，您可能无法进行VIP交换。您的配额必须至少是正在运行的实例的2倍。当您查看数千个实例时，这是不切实际的。不过，对于凡人来说，配额可以让你得到更多

---

除了一件事之外，这些环境是相同的：它们有不同的VIP地址（在loadbalancer上公开的IP地址）。当您交换VIP时，负载平衡器将被重新编程，以便在临时部署和生产部署之间切换VIP—仅此而已。DNS没有任何变化

还有一些细微差别。例如，现有的连接没有（应该）被切断。所以，如果您有一个长时间运行的开放连接，它将在VIP交换期间继续。这可能会导致以下情况：a.）交换后，连接正在访问“较旧”的环境；b.）在某些情况下，这也会导致VIP交换操作本身持续一段时间（通常速度相当快）

这两个环境的初衷是简化升级部署。您将在staging中启动另一个更新的部署，进行一些测试，然后切换。大部分用户都不会注意到任何东西。然而，也有这样的情况