如何在Azure DevOps中为Azure Service Fabric配置类似App Service的无停机部署能力

1 原生滚动升级（最低改造成本） #

Service Fabric 默认支持增量滚动升级，无需额外部署冗余实例即可实现无停机更新，核心配置如下：

• 确认集群升级域（Upgrade Domain, UD）配置为默认的5个，升级过程中每次仅更新1个升级域内的服务实例，剩余4个升级域的实例持续对外提供服务，全程服务可用率不低于80%
• 部署时选择Monitored监控升级模式，配置健康检查阈值：要求至少90%的服务实例处于健康状态、无系统健康报错，升级过程中一旦健康度低于阈值将自动暂停升级并回滚
• 在Azure DevOps的Service Fabric部署任务中直接选择上述升级模式即可，无需修改业务代码

2 蓝绿部署（类App Service Swap槽体验） #

如果需要完全复刻App Service交换部署槽的使用逻辑，可以采用蓝绿部署方案，切换风险最低：

• 在集群内部署两套独立的应用实例：蓝色实例为当前生产版本（对外提供服务），绿色实例为待发布的新版本
• CI/CD流程先将新版本部署到绿色实例，跑通自动化测试、确认服务健康后，通过前端负载均衡或者Service Fabric反向代理的路由规则，将流量100%切换到绿色实例
• 切换完成后观察一段时间无异常，即可下线旧的蓝色实例；如果新版本出现问题，可秒切回蓝色实例，全程无服务中断
• 该方案和App Service Swap槽逻辑完全一致，适合对可用性要求极高的生产场景

3 灰度发布（更细粒度的流量控制） #

如果需要先切小部分流量验证新版本稳定性，可以采用流量分割方案：

• 对于无状态服务，配置Service Fabric路由规则，将10%~30%的用户流量先导到新版本服务实例，观察无异常后逐步提升流量比例，直到100%流量切完再下线旧版本
• 对于有状态服务，采用分区滚动升级策略，每次仅升级一个服务分区的副本，升级完成确认分区健康后再推进下一个分区的升级，全程不影响其他分区的服务可用性

4 Azure DevOps CI/CD 配置优化点 #

• 部署任务中勾选保留现有应用配置选项，避免升级时覆盖生产环境的自定义配置参数
• 新增自动化健康检查步骤：新版本部署完成后，自动调用服务健康检查接口，确认服务正常后再进入流量切换环节
• 配置自动回滚规则：升级过程中健康检查失败时，无需人工介入自动回滚到上一个稳定版本

内容的提问来源于stack exchange，提问作者Vitaliy Kuzmenko