升级不遵守Cancellation Token的Service Fabric有状态服务问题

好的，针对你遇到的这个问题——旧版本有状态服务副本不遵守Cancellation Token，升级时可能卡住导致服务中断，我有一套循序渐进的方案，能帮你把影响降到最低：

1. 提前手动转移故障节点上的主副本 #

因为主副本是处理用户请求的核心，先把它转移到健康节点，就能彻底避免后续操作影响服务可用性：

• 使用PowerShell命令Move-ServiceFabricPrimaryReplica精准转移目标服务的主副本：

  Move-ServiceFabricPrimaryReplica -ServiceName fabric:/YourApp/YourStatefulService -NodeName FaultyMainNode -TargetNodeName HealthyNode01
  

• 执行完后，用Get-ServiceFabricReplica确认主副本已经切换到健康节点，原故障节点上的副本变为次要副本。这时候即使旧副本卡住，也不会影响正常流量。

2. 配置保守的升级策略，控制升级范围 #

在启动升级时，通过参数限制升级的影响范围，避免批量替换副本引发的问题：

• 启动升级时设置以下关键参数：

  Start-ServiceFabricApplicationUpgrade `
    -ApplicationName fabric:/YourApp `
    -ApplicationTypeVersion 你的新版本号 `
    -MaxPercentUnhealthyPartitionsPerService 0 `
    -MaxPercentUnhealthyReplicasPerPartition 5 `
    -HealthCheckStableDurationSec 60 `
    -UpgradeDomainTimeoutSec 3600
  

  • MaxPercentUnhealthyPartitionsPerService设为0，确保任何分区都不能处于不健康状态再继续升级；
  • MaxPercentUnhealthyReplicasPerPartition设为较低值，限制每次升级的副本数量；
  • 延长HealthCheckStableDurationSec和UpgradeDomainTimeoutSec，给系统足够时间完成健康检查和副本替换。

3. 分阶段升级：先处理健康节点，再清理故障节点 #

• 第一阶段：只升级健康节点上的副本。可以通过NodeFilter参数指定要升级的健康节点列表：

  Start-ServiceFabricApplicationUpgrade `
    -ApplicationName fabric:/YourApp `
    -ApplicationTypeVersion 你的新版本号 `
    -NodeFilter @("HealthyNode01", "HealthyNode02", "HealthyNode03") `
    -其他参数同上
  

• 等所有健康节点的副本都升级完成且状态健康后，再单独处理故障节点：
  这时候因为主副本已经在健康节点，你可以安全地执行Restart-ServiceFabricDeployedCodePackage或Restart-ServiceFabricNode重启故障节点上的卡住副本。这个过程只会影响次要副本，几乎不会对用户请求造成中断。

4. 升级完成后的验证与收尾 #

• 用Get-ServiceFabricApplicationHealth和Get-ServiceFabricReplica检查所有副本的状态，确认全部运行在新版本且无异常；
• 如果需要，可再用Move-ServiceFabricPrimaryReplica把主副本移回原节点（如果业务有需求的话）。

额外提示：如果你的服务开启了EnableAutoInstanceMove（默认是开启的），系统会自动检测卡住的副本并转移主角色，但手动转移能更精准地控制时机，避免不必要的等待。

内容的提问来源于stack exchange，提问作者Sam Schneider