Service Fabric 应用程序升级:高级主题Service Fabric application upgrade: Advanced topics

在升级应用程序期间添加或删除服务类型Add or remove service types during an application upgrade

如果在升级过程中向已发布的应用程序添加新的服务类型,则该新的服务类型将添加到已部署的应用程序。If a new service type is added to a published application as part of an upgrade, then the new service type is added to the deployed application. 这样的升级不会影响已经是应用程序一部分的任何服务实例,但是,必须创建所添加的服务类型的实例,新的服务类型才会处于活动状态(请参阅 New-ServiceFabricService)。Such an upgrade does not affect any of the service instances that were already part of the application, but an instance of the service type that was added must be created for the new service type to be active (see New-ServiceFabricService).

类似地,在升级过程中还可以从应用程序中删除服务类型。Similarly, service types can be removed from an application as part of an upgrade. 但是,必须删除待删除服务类型的所有服务实例,然后才能继续进行升级(请参阅 Remove-ServiceFabricService)。However, all service instances of the to-be-removed service type must be removed before proceeding with the upgrade (see Remove-ServiceFabricService).

避免在无状态服务计划内停机期间断开连接Avoid connection drops during stateless service planned downtime

对于计划内无状态实例停机(例如,应用程序/群集升级或节点停用),由于实例关闭后公开的终结点被删除,因此连接可能会断开,从而导致强制关闭连接。For planned stateless instance downtimes, such as application/cluster upgrade or node deactivation, connections can get dropped due to the exposed endpoint is removed after the instance goes down, which results in forced connection closures.

若要避免此问题,请通过在服务配置中添加“实例关闭延迟持续时间”来配置 RequestDrain(预览)功能,以便在接收来自群集中其他服务的请求时允许排出,并使用反向代理或使用带有通知模型的解析 API 来更新终结点。To avoid this, configure the RequestDrain (preview) feature by adding an instance close delay duration in the service configuration to allow drain while receiving requests from other services within the cluster and are using Reverse Proxy or using resolve API with notification model for updating endpoints. 这可确保在延迟开始之前删除无状态实例播发的终结点,然后再关闭实例。This ensures that the endpoint advertised by the stateless instance is removed before the delay starts prior to closing the instance. 此延迟可使现有请求在实例实际关闭之前正常排空。This delay enables existing requests to drain gracefully before the instance actually goes down. 在开始延迟时,客户端通过回调函数获取有关终结点发生更改的通知,因此它们可以重新解析终结点,并避免向正在停止的实例发送新请求。Clients are notified of the endpoint change by a callback function at the time of starting the delay, so that they can re-resolve the endpoint and avoid sending new requests to the instance which is going down.

服务配置Service configuration

可通过多种方式在服务端配置延迟。There are several ways to configure the delay on the service side.

  • 创建新服务时指定 -InstanceCloseDelayDurationWhen creating a new service, specify a -InstanceCloseDelayDuration:

    New-ServiceFabricService -Stateless [-ServiceName] <Uri> -InstanceCloseDelayDuration <TimeSpan>`
    
  • 在应用程序清单的 defaults 节中定义服务时分配 InstanceCloseDelayDurationSeconds 属性:While defining the service in the defaults section in the application manifest, assign the InstanceCloseDelayDurationSeconds property:

          <StatelessService ServiceTypeName="Web1Type" InstanceCount="[Web1_InstanceCount]" InstanceCloseDelayDurationSeconds="15">
              <SingletonPartition />
          </StatelessService>
    
  • 更新现有服务时指定 -InstanceCloseDelayDurationWhen updating an existing service, specify a -InstanceCloseDelayDuration:

    Update-ServiceFabricService [-Stateless] [-ServiceName] <Uri> [-InstanceCloseDelayDuration <TimeSpan>]`
    

客户端配置Client configuration

若要在终结点更改后收到通知,应让客户端注册回调,详见 ServiceNotificationFilterDescriptionTo receive notification when an endpoint has changed, clients should register a callback see ServiceNotificationFilterDescription. 如果收到更改通知,则表明终结点已更改,客户端应重新解析终结点,而不要使用不再播发的终结点,因为这些终结点即将关闭。The change notification is an indication that the endpoints have changed, the client should re-resolve the endpoints, and not use the endpoints which are not advertised anymore, as they will go down soon.

可选的升级替代方法Optional upgrade overrides

除了为每个服务设置默认延迟持续时间以外,还可以使用相同的 (InstanceCloseDelayDurationSec) 选项替代应用程序/群集升级期间的延迟:In addition to setting default delay durations per service, you can also override the delay during application/cluster upgrade using the same (InstanceCloseDelayDurationSec) option:

Start-ServiceFabricApplicationUpgrade [-ApplicationName] <Uri> [-ApplicationTypeVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

Start-ServiceFabricClusterUpgrade [-CodePackageVersion] <String> [-ClusterManifestVersion] <String> [-InstanceCloseDelayDurationSec <UInt32>]

延迟持续时间仅应用于调用的升级实例,而不会更改单个服务延迟配置。The delay duration only applies to the invoked upgrade instance and does not otherwise change individual service delay configurations. 例如,可以使用此方法指定 0 延迟,以跳过任何预配置的升级延迟。For example, you can use this to specify a delay of 0 in order to skip any preconfigured upgrade delays.

Note

用于排出请求的设置不适用于来自 Azure 负载均衡器的请求。The setting to drain requests is not honored for requests from Azure Load balancer. 如果调用服务使用基于投诉的解析,则此设置不起作用。The setting are not honored if the calling service uses complaint based resolve.

Note

当群集代码版本为 7.1.XXX 或更高版本时,可以如上所述使用 Update-ServiceFabricService cmdlet 在现有服务中配置此功能。This feature can be configured in existing services using Update-ServiceFabricService cmdlet as mentioned above, when the cluster code version is 7.1.XXX or above.

手动升级模式Manual upgrade mode

Note

对于所有 Service Fabric 升级,建议使用 Monitored 升级模式。The Monitored upgrade mode is recommended for all Service Fabric upgrades. 只有对于失败或暂停的升级,才应考虑使用 UnmonitoredManual 升级模式。The UnmonitoredManual upgrade mode should only be considered for failed or suspended upgrades.

Monitored 模式下,Service Fabric 应用运行状况策略来确保应用程序在升级过程中正常运行。In Monitored mode, Service Fabric applies health policies to ensure that the application is healthy as the upgrade progresses. 如果违反了运行状况策略,则升级将暂停或自动回滚,具体取决于指定的 FailureActionIf health policies are violated, then the upgrade is either suspended or automatically rolled back depending on the specified FailureAction.

UnmonitoredManual 模式下,应用程序管理员对升级进度具有完全控制权。In UnmonitoredManual mode, the application administrator has total control over the progression of the upgrade. 当应用自定义运行状况评估策略或执行非常规升级来完全绕过运行状况监视时(例如,当应用程序已经丢失数据时),此模式非常有用。This mode is useful when applying custom health evaluation policies or performing non-conventional upgrades to bypass health monitoring completely (e.g. the application is already in data loss). 在此模式下运行的升级在完成每个 UD 后会将其自己暂停,并且必须使用 Resume-ServiceFabricApplicationUpgrade 显式使其继续执行。An upgrade running in this mode will suspend itself after completing each UD and must be explicitly resumed using Resume-ServiceFabricApplicationUpgrade. 当升级暂停并且就绪可供用户继续执行时,其升级状态将显示 RollforwardPending(请参阅 UpgradeState)。When an upgrade is suspended and ready to be resumed by the user, its upgrade state will show RollforwardPending (see UpgradeState).

最后,UnmonitoredAuto 模式非常适用于在开发或或测试服务期间执行快速升级迭代,因为不需要提供用户输入并且不会评估应用程序运行状况策略。Finally, the UnmonitoredAuto mode is useful for performing fast upgrade iterations during service development or testing since no user input is required and no application health policies are evaluated.

使用差异包升级Upgrade with a diff package

还可以通过预配仅包含更新后的代码/配置/数据包以及完整的应用程序清单和完整的服务清单的差异包(不需要预配完整的应用程序包)来执行升级。Instead of provisioning a complete application package, upgrades can also be performed by provisioning diff packages that contain only the updated code/config/data packages along with the complete application manifest and complete service manifests. 只有首次将应用程序安装到群集时,才需要完整的应用程序包。Complete application packages are only required for the initial installation of an application to the cluster. 后续升级可以使用完整的应用程序包或差异包执行。Subsequent upgrades can either be from complete application packages or diff packages.

如果差异包的应用程序清单或服务清单中的任何引用无法在应用程序包中找到,则会自动将该引用替换为当前预配的版本。Any reference in the application manifest or service manifests of a diff package that can't be found in the application package is automatically replaced with the currently provisioned version.

使用差异包的方案有:Scenarios for using a diff package are:

  • 拥有一个引用了多个服务清单文件和/或多个代码包、配置包或数据包的大型应用程序包时。When you have a large application package that references several service manifest files and/or several code packages, config packages, or data packages.
  • 当部署系统直接在应用程序生成过程中产生生成布局时。When you have a deployment system that generates the build layout directly from your application build process. 在这种情况下,即使代码未发生任何更改,新生成的程序集也会获得不同的校验和。In this case, even though the code hasn't changed, newly built assemblies get a different checksum. 使用完整的应用程序包要求更新所有代码包上的版本。Using a full application package would require you to update the version on all code packages. 使用差异包时,只需提供更改的文件和其中的版本已更改的清单文件。Using a diff package, you only provide the files that changed and the manifest files where the version has changed.

如果应用程序是使用 Visual Studio 升级的,则会自动发布差异包。When an application is upgraded using Visual Studio, a diff package is published automatically. 若要手动创建差异包,必须更新应用程序清单和服务清单,只在最终应用程序包中包含更改的包。To create a diff package manually, the application manifest and the service manifests must be updated, but only the changed packages should be included in the final application package.

例如,让我们从以下应用程序开始(为便于理解,这里提供了版本号):For example, let's start with the following application (version numbers provided for ease of understanding):

app1           1.0.0
  service1     1.0.0
    code       1.0.0
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

假设你想要使用差异包仅更新 service1 的代码包。Let's assume you wanted to update only the code package of service1 using a diff package. 更新后的应用程序有以下版本更改:Your updated application has the following version changes:

app1           2.0.0      <-- new version
  service1     2.0.0      <-- new version
    code       2.0.0      <-- new version
    config     1.0.0
  service2     1.0.0
    code       1.0.0
    config     1.0.0

在本例中,你将应用程序清单更新为 2.0.0,并更新了 service1 的服务清单来反映代码包更新。In this case, you update the application manifest to 2.0.0 and the service manifest for service1 to reflect the code package update. 应用程序包的文件夹具有以下结构:The folder for your application package would have the following structure:

app1/
  service1/
    code/

换句话说,就是照常创建完整的应用程序包,然后删除其版本未更改的任何代码/配置/数据包文件夹。In other words, create a complete application package normally, then remove any code/config/data package folders for which the version has not changed.

独立于版本升级应用程序参数Upgrade application parameters independently of version

有时,需要更改 Service Fabric 应用程序的参数,而无需更改清单版本。Sometimes, it is desirable to change the parameters of a Service Fabric application without changing the manifest version. 可以通过将 -ApplicationParameter 标志与 Start-ServiceFabricApplicationUpgrade 一起使用来方便地完成此操作。This can be done conveniently by using the -ApplicationParameter flag with the Start-ServiceFabricApplicationUpgrade Azure Service Fabric PowerShell cmdlet. 假设 Service Fabric 应用程序具有以下属性:Assume a Service Fabric application with the following properties:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "1"; "NewParameter" = "testBefore" }

现在使用 Start-ServiceFabricApplicationUpgrade cmdlet 升级该应用程序。Now, upgrade the application using the Start-ServiceFabricApplicationUpgrade cmdlet. 此示例显示了受监视的升级,但也可以使用不受监视的升级。This example shows an monitored upgrade, but an unmonitored upgrade can also be used. 若要查看此 cmdlet 接受的标志的完整说明,请参阅 Azure Service Fabric PowerShell 模块参考To see a full description of flags accepted by this cmdlet, see the Azure Service Fabric PowerShell module reference

PS C:\> $appParams = @{ "ImportantParameter" = "2"; "NewParameter" = "testAfter"}

PS C:\> Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/Application1 -ApplicationTypeVers
ion 1.0.0 -ApplicationParameter $appParams -Monitored

升级后,确认应用程序具有已更新的参数和相同的版本:After upgrading, confirm that the application has the updated parameters and the same version:

PS C:\> Get-ServiceFabricApplication -ApplicationName fabric:/Application1

ApplicationName        : fabric:/Application1
ApplicationTypeName    : Application1Type
ApplicationTypeVersion : 1.0.0
ApplicationStatus      : Ready
HealthState            : Ok
ApplicationParameters  : { "ImportantParameter" = "2"; "NewParameter" = "testAfter" }

回滚应用程序升级Roll back application upgrades

虽然升级可以通过三种模式之一(MonitoredUnmonitoredAutoUnmonitoredManual)进行前滚,但它们只能在 UnmonitoredAutoUnmonitoredManual 模式下进行回滚。While upgrades can be rolled forward in one of three modes (Monitored, UnmonitoredAuto, or UnmonitoredManual), they can only be rolled back in either UnmonitoredAuto or UnmonitoredManual mode. UnmonitoredAuto 模式下进行回滚与进行前滚时行为相同,唯一的例外是 UpgradeReplicaSetCheckTimeout 的默认值不同 - 请参阅应用程序升级参数Rolling back in UnmonitoredAuto mode works the same way as rolling forward with the exception that the default value of UpgradeReplicaSetCheckTimeout is different - see Application Upgrade Parameters. UnmonitoredManual 模式下进行回滚与进行前滚时行为相同 - 回滚在完成每个 UD 后会将其自己暂停,并且必须使用 Resume-ServiceFabricApplicationUpgrade 显式继续执行回滚。Rolling back in UnmonitoredManual mode works the same way as rolling forward - the rollback will suspend itself after completing each UD and must be explicitly resumed using Resume-ServiceFabricApplicationUpgrade to continue with the rollback.

当违反了在 Monitored 模式下进行的升级的运行状况策略并且 FailureActionRollback 时,可以自动触发回滚(请参阅应用程序升级参数);也可以使用 Start-ServiceFabricApplicationRollback 显式触发回滚。Rollbacks can be triggered automatically when the health policies of an upgrade in Monitored mode with a FailureAction of Rollback are violated (see Application Upgrade Parameters) or explicitly using Start-ServiceFabricApplicationRollback.

在回滚期间,可以随时使用 Update-ServiceFabricApplicationUpgrade 更改 UpgradeReplicaSetCheckTimeout 的值和模式。During rollback, the value of UpgradeReplicaSetCheckTimeout and the mode can still be changed at any time using Update-ServiceFabricApplicationUpgrade.

后续步骤Next steps

Upgrading your Application Using Visual Studio (使用 Visual Studio 升级应用程序)逐步讲解了如何使用 Visual Studio 进行应用程序升级。Upgrading your Application Using Visual Studio walks you through an application upgrade using Visual Studio.

使用 Powershell 升级应用程序逐步讲解了如何使用 PowerShell 进行应用程序升级。Upgrading your Application Using Powershell walks you through an application upgrade using PowerShell.

使用升级参数来控制应用程序的升级方式。Control how your application upgrades by using Upgrade Parameters.

了解如何使用数据序列化,使应用程序在升级后保持兼容。Make your application upgrades compatible by learning how to use Data Serialization.

参考对应用程序升级进行故障排除中的步骤来解决应用程序升级时的常见问题。Fix common problems in application upgrades by referring to the steps in Troubleshooting Application Upgrades.