【Azure Cloud Service(Extended Support)】如何使用外延服务迁移应用?

问题一：迁移到云服务扩展后，之前经典版的云服务的部署槽会变成单一的部署槽，关于两个云服务扩展版之间的部署交换能否提供一个演示？

对于具有双槽的云服务(Classic)，根据文档中的建议，在迁移到云服务(外延支持)时需要先删除过渡槽，将生产槽作为一个独立的云服务进行迁移。

在完成生产槽的迁移后，创建另一个新的云服务(外延支持)来代替之前的过度槽。并将该新创建的云服务与已经迁移的云服务配置为可交换部署。

部署交换的详细步骤如下：

1：将生产槽所迁移的云服务(外延支持)作为第一个云服务(简称为cs1)

2：重新创建一个云服务(外延支持)作为第二个云服务(简称为cs2)。 第二个云服务需要在ARM template内将云服务设置为可交换。

3：设置方法为将NetworkProfile 内SwappableCloudService 的id设置为 cs1的id。

示例如下：

"networkProfile": {
"SwappableCloudService": {
              "id": "[concat(variables('swappableResourcePrefix'), 'Microsoft.Compute/cloudServices/', parameters('cloudServicesToBeSwappedWith'))]"
            },
        }

4：当cs2 部署完成后，就可以对两个云服务进行交换，交换方法有PowerShell, Azure portal和 Rest API calls 三种方法。

• PowerShell ：Switch-AzCloudService -SubscriptionId $subscriptionId -CloudServiceName $sourceCsName -ResourceGroupName $sourceRgName
• Azure portal 请查看本文档：Swap or switch deployments in Azure Cloud Services (extended support) | Microsoft Learn
• Rest API calls 请查看本文档：Swap or switch deployments in Azure Cloud Services (extended support) | Microsoft Learn

问题二：关于迁移到云服务扩展版之后将会出现虚拟网络的概念，这个虚拟网络需要在代码里怎么配置，能否提供一个配置的例子？

在2017年以后创建的云服务(经典)会自动创建默认的虚拟网络，在迁移过程中，该默认虚拟网络也会被自动迁移。

迁移完成后，在云服务(外延支持)的Configuration内可以查看到该虚拟网络的resource id。

示例截图如下

问题三：迁移后新追加的资源是否对性能有影响？

不会

问题四：如何修改VM大小？是否需要重新部署全部包？

与云服务一样，在csdef文件中修改VM的大小，修改完成后需要重新打包部署。

问题五：官方文档显示，在迁移后cscfg和csdef会删除Diagnostics相关内容。但是实际操作后，发现在迁移后的CSES的cscfg内依然存在Diagnostics相内容。此处是否需要手动删除呢？

Diagnostics相关内容属于云服务的extension，所有enabled的支持的extension都会被自动迁移，如果您不再需要该功能，可以进行手动删除，如果您依然需要该功能，则可以保留。

Technical details and requirements for migrating to Azure Cloud Services (extended support) | Microsoft Learn

问题六：cscfg在迁移前，编码格式为utf-8；在迁移后，编码格式为utf-16。以上现象是否需要注意呢？

编码格式从utf-8 到utf-16 并不会对应用造成影响。在博文中有分析解释：https://www.cnblogs.com/lulight/p/17588780.html