VIP交换+CNME如何比IP交换+A记录更好？
作为以上内容的延续-由于我在Azure中遇到CNAME问题，我非常接近恢复到a记录。
从Azure文档中可以看出：
注意，因为IP地址的生存期是相关的对于部署，如果您需要IP地址才能持久存在。方便的是使用时，将持久化给定的部署槽(生产或暂存)Windows Azure中的两种升级机制：VIP交换和就地升级升级。
我有myapp.cloudapp.net，当前指向1.1.1.1的VIP。如果我想将应用程序的某个版本部署到"暂存"，我将使用我的应用程序旋转"暂存"插槽，进行一些测试，然后通过VIP交换进行无缝升级。应用程序现在将使用2.2.2.2——尽管如果我在此时再次进行DNS查找，myapp.cloudapp.net的a记录仍将指向1.1.1.1，因为VIP交换对DNS没有影响，对吧？
如果是这样的话，那么当我为了节省成本而终止阶段部署时会发生什么？1.1.1.1和2.2.2.2都会为我的服务保留吗？我希望如此，因为这意味着我可以让我的A记录一直指向1.1.1.1，通过阶段部署依赖它，而不用担心CNAME的麻烦。但这意味着这个答案是错误的。
如果不是，那么这意味着VIP交换确实对DNS记录有影响，对吧？否则，我可以这样做：
- 1.1.1.1>2.2.2.2，跌落分级，1.1.1.1回收
- 再次启动阶段，2.2.2.2>3.3.3.3，但myapp.cloudapp.net的DNS A记录仍然指向1.1.1.1
最后一位没有任何意义，所以要么DNS记录更新，要么3.3.3.3永远不会出现，1.1.1.1和2.2.2.2总是在一起，只要我的云服务没有被删除。
我对这件事很困惑——任何指导都很好。
更新-我刚刚用以下内容进行了测试：
CHECK DNS - get 1.1.1.1
READ PROD - get 1.1.1.1
DEPLOY STAGING
READ STAGING - get 2.2.2.2
VIP SWAP
READ PROD - get 1.1.1.1
READ STAGING - get 2.2.2.2
CHECK DNS - get 1.1.1.1
KILL STAGING DEPLOYMENT
READ PROD - get 1.1.1.1
因此，似乎可以使用记录-即使在暂存/生产之间切换，PROD VIP也保持不变，但部署会被交换。删除暂存并重新部署暂存将获得一个新的辅助VIP，但主VIP确实保持不变。我会等到比我更可靠的人能在这里插话后再把这个作为答案发布。
VIP交换不会更改您的公共IP。也就是说，如果你的应用程序部署在1.1.1.1的prod插槽中，测试版部署在2.2.2.2的staging插槽中，即使在VIP交换后，你的公共IP仍然是1.1.1.1。这是因为VIP只是一个负载平衡配置更改。您可以安全地从IP为2.2.2.2的暂存槽(最初是prod槽)中删除您的原始应用程序。
希望这能有所帮助，