迁移含同名IIS站点的Azure服务器（不同DNS）的最佳实践

场景背景 #

当前有一台Classic VM，DNS子域名app.mydomain.com和api.mydomain.com指向该VM的IP，IIS服务器已配置对应名称的站点，互联网用户可正常访问这两个站点。目标是迁移至新VM，先设置DNS子域名app2.mydomain.com和api2.mydomain.com指向新VM IP完成测试，体验一致后将原域名DNS指向新VM。但新VM当前IIS站点仍使用原域名，会与测试域名产生冲突，以下是这类迁移的最佳实践：

1. 优化IIS站点绑定配置 #

• 给新VM的IIS站点添加多主机头绑定：保留原app.mydomain.com、api.mydomain.com绑定的同时，新增app2.mydomain.com、api2.mydomain.com作为额外主机头。这样新VM可同时响应原域名和测试域名的请求，既满足测试需求，也不影响后续DNS切换后的生产服务。
• 若使用HTTPS，确保SSL证书覆盖所有需要的域名（原域名+测试域名），或直接使用通配符证书*.mydomain.com，避免证书不匹配导致的访问报错。

2. 标准化配置管理 #

• 从原VM导出IIS站点配置：使用命令appcmd.exe list site /config /xml > siteconfig.xml将站点配置导出为XML文件，在新VM导入时修改或添加测试域名绑定，减少手动配置的错误率。
• 借助配置管理工具（如Ansible、PowerShell DSC）批量同步新旧VM的IIS配置，确保配置一致性，同时能灵活切换测试/生产域名绑定。

3. 测试阶段的流量隔离方案 #

• 单人测试可修改本地hosts文件，强制将app.mydomain.com、api.mydomain.com解析到新VM IP，无需修改公共DNS即可验证生产域名在新VM上的可用性，避免影响真实用户。
• 多人测试时，临时在DNS服务器添加app2.mydomain.com、api2.mydomain.com的A记录指向新VM，测试完成后再调整或删除该记录。

4. 平滑DNS切换策略 #

• 切换前降低原域名的DNS TTL值（例如从24小时调整为5分钟），缩短DNS缓存的生效时间，减少切换后流量残留到原VM的时长。
• 切换DNS后，持续监控新VM的访问日志和服务状态，同时保留原VM至少一个TTL周期，确保出现异常时能快速回滚DNS指向。

5. 站点管理与标识优化 #

• 给新VM的IIS站点设置明确的名称（如App-生产环境(新VM)、API-生产环境(新VM)），与原VM站点区分开，避免管理时混淆。
• 启用IIS的分域名日志记录，分别跟踪原域名和测试域名的访问请求，便于测试阶段排查问题。

内容的提问来源于stack exchange，提问作者daniel p