你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Service Fabric 应用程序生命周期

与其他平台一样，Azure Service Fabric 上的应用程序通常将经历以下几个阶段：设计、开发、测试、部署、升级、维护和删除。 Service Fabric 为云应用程序的整个应用程序生命周期提供一流的支持：从开发到部署、到日常管理和维护，再到最终解除授权。 服务模型使多个不同角色可以独立参与到应用程序生命周期中。 本文提供了有关 API 的概述，以及在 Service Fabric 应用程序生命周期的各个阶段，它们是如何被不同角色所使用的。

查看此页获取培训视频，了解如何管理应用程序生命周期：

重要

可以使用两个 CLI 实用工具来与 Service Fabric 交互。 Azure CLI 用于管理 Azure 资源，例如 Azure 托管的 Service Fabric 群集。 Service Fabric CLI 用于直接连接到 Service Fabric 群集（不管托管在哪个位置）和管理群集、应用程序与服务。

服务模型角色

服务模型角色如下：

• “服务开发人员”：开发可以用作其他用途或在相同类型或不同类型的多个应用程序中使用的模块和通用服务。 例如，队列服务可用于创建票证应用程序（帮助服务台）或电子商务应用程序（购物车）。
• 应用程序开发人员：通过集成满足某些特定要求或方案的服务集合来创建应用程序。 例如，电子商务网站可能集成“JSON 无状态前端服务”、“拍卖有状态服务”，以及“队列有状态服务”来建构拍卖解决方案。
• 应用程序管理员：针对应用程序配置（填写配置模板参数）、部署（映射到可用资源）以及服务质量做出决策。 例如，应用程序管理员决定应用程序的语言区域设置（例如，美国为英语或日本为日语）。 另一个已部署的应用程序可以具有不同的设置。
• 操作员：基于由应用程序管理员指定的应用程序配置和要求部署应用程序。 例如，操作员设置和部署应用程序并确保它在 Azure 中运行。 操作员监视应用程序运行状况和性能信息，并根据需要维护物理基础结构。

开发

1. 服务开发人员使用 Reliable Actors 或 Reliable Services 编程模型开发不同类型的服务。
2. 服务开发人员在包含一个或多个代码、配置和数据包的服务清单文件中以声明方式描述开发的服务类型。
3. 然后，应用程序开发人员使用不同的服务类型生成应用程序。
4. 应用程序开发人员通过引用各个构成服务的服务清单并相应地重写并参数化各个构成服务的不同配置和部署设置，以声明方式描述应用程序清单中的应用程序类型。

有关示例，请参阅 Reliable Actors 入门和 Reliable Services 入门。

部署

1. 应用程序管理员通过在应用程序清单中指定相应的 ApplicationType 元素的参数，将定制应用程序类型定制为会被部署到 Service Fabric 群集的特定应用程序。
2. 操作员使用 CopyApplicationPackage 方法或 Copy-ServiceFabricApplicationPackage cmdlet，将应用程序包上传到群集映像存储中。 应用程序包包含应用程序清单和服务包集合。 Service Fabric 部署存储在映像存储（可能是 Azure Blob 存储或 Service Fabric 系统服务）中的应用程序包中的应用程序。
3. 然后，操作员使用 ProvisionApplicationAsync 方法、Register-ServiceFabricApplicationType cmdlet 或预配应用程序 REST 操作预配从已上传的应用程序包的目标群集中的应用程序类型。
4. 预配该应用程序后，操作员使用由应用程序管理员通过 CreateApplicationAsync 方法、New-ServiceFabricApplication cmdlet 或创建应用程序 REST 操作所提供的参数，来启动该应用程序。
5. 部署应用程序后，操作员使用 CreateServiceAsync 方法、New-ServiceFabricService cmdlet 或创建服务 REST 操作，来基于可用的服务类型为应用程序创建新的服务实例。
6. 该应用程序现在在 Service Fabric 群集中运行。

有关示例，请参阅部署应用程序。

测试

1. 部署到本地开发群集或测试群集后，服务开发人员使用 FailoverTestScenarioParameters 和 FailoverTestScenario 类或 Invoke ServiceFabricFailoverTestScenario cmdlet 运行内置的故障转移测试方案。 故障转移测试方案在重要转换和故障转移中运行指定的服务，以确保其仍然可用并正在工作。
2. 然后，服务开发者使用 ChaosTestScenarioParameters 和 ChaosTestScenario 类或 Invoke-ServiceFabricChaosTestScenario cmdlet，运行内置的 Chaos 测试方案。 任意混合测试方案会将多个节点、代码包和副本错误包括到群集中。
3. 服务开发人员通过创建围绕群集移动主副本的测试方案，来测试服务之间的通信。

有关详细信息，请参阅故障分析服务简介。

升级

1. 服务开发人员将更新实例化应用程序的构成服务并/或修复 bug，并提供服务清单的新版本。
2. 应用程序开发人员重写并参数化一致服务的配置和部署设置，并提供应用程序清单的新版本。 然后，应用程序开发人员将服务清单的新版本合并到应用程序中，并在更新的应用程序包中提供应用程序类型的新版本。
3. 应用程序管理员通过更新相应的参数，将应用程序类型的新版本合并到目标应用程序中。
4. 操作员使用 CopyApplicationPackage 方法或 Copy-ServiceFabricApplicationPackage cmdlet，将更新的应用程序包上传到群集映像存储中。 应用程序包包含应用程序清单和服务包集合。
5. 操作员使用 ProvisionApplicationAsync 方法、Register-ServiceFabricApplicationType cmdlet 或预配应用程序 REST 操作，在目标群集中预配应用程序的新版本。
6. 操作员使用 UpgradeApplicationAsync 方法、Start-ServiceFabricApplicationUpgrade cmdlet 或升级应用程序 REST 操作将目标应用程序升级到新版本。
7. 操作员使用 GetApplicationUpgradeProgressAsync 方法、Get ServiceFabricApplicationUpgrade cmdlet 或获取应用程序升级进度 REST 操作，来检查升级进度。
8. 如有必要，操作员将使用 UpdateApplicationUpgradeAsync 方法、Update-ServiceFabricApplicationUpgrade cmdlet 或更新应用程序升级 REST 操作，来修改并重新应用当前应用程序升级参数。
9. 如有必要，操作员将使用 RollbackApplicationUpgradeAsync 方法、Start-ServiceFabricApplicationRollback cmdlet 或回滚应用程序升级 REST 操作，来回滚当前的应用程序升级。
10. Service Fabric 对在群集中运行的目标应用程序进行升级，并且不会丢失其任何构成服务的可用性。

有关示例，请参阅应用程序升级教程。

维护

1. 对于操作系统升级和修补程序，Service Fabric 与 Azure 基础结构连接，以确保所有在群集中运行的应用程序的可用性。
2. 对于 Service Fabric 平台的升级和修补程序，Service Fabric 自行升级，并且不会丢失在群集上运行的任何应用程序的可用性。
3. 应用程序管理员在分析历史容量使用率数据与将来需求后，批准从群集中添加或删除节点。
4. 操作员添加和删除由应用程序管理员指定的节点。
5. 当新节点被添加到群集中或从群集中删除现有节点时，Service Fabric 自动负载均衡正在群集中的所有节点上运行的应用程序，以获得最佳性能。

删除

1. 操作员可以使用 DeleteServiceAsync 方法、Remove-ServiceFabricService cmdlet 或删除服务 REST 操作来删除群集中正在运行的服务的特定实例，并且不会删除整个应用程序。
2. 操作员还可以使用 DeleteApplicationAsync 方法、Remove-ServiceFabricApplication cmdlet，或删除应用程序 REST 操作，来删除应用程序实例及其所有服务。
3. 应用程序和服务停止后，操作员可以使用 UnprovisionApplicationAsync 方法、Unregister-ServiceFabricApplicationType cmdlet，或取消预配应用程序 REST 操作来取消预配应用程序类型。 取消预配应用程序类型不会从 ImageStore 删除应用程序包。
4. 操作员使用 RemoveApplicationPackage 方法或 Remove-ServiceFabricApplicationPackage cmdlet 从 ImageStore 中删除应用程序包。

有关示例，请参阅部署应用程序。

在群集映像存储中保留磁盘空间

ImageStoreService 会保留复制和预配的包，这可能会导致文件累积。 文件累积可能会导致 ImageStoreService (fabric:/System/ImageStoreService) 填满磁盘，并增加 ImageStoreService 副本的生成时间。

为避免文件累积，请使用以下预配顺序：

1. 将包复制到 ImageStore，并使用压缩选项

2. 对包进行预配

3. 从映像存储中移除包

4. 升级应用程序/群集

5. 取消预配旧版本

上述过程中的步骤 3 和 5 可防止映像存储中出现文件累积。

自动进行清理的配置

可以使用 PowerShell 或 XML 自动执行上述步骤 3。 这将导致应用程序包在应用程序类型成功注册后自动删除。

PowerShell：

Register-ServiceFabricApplicationTye -ApplicationPackageCleanupPolicy Automatic

XML：

<Section Name="Management">
  <Parameter Name="CleanupApplicationPackageOnProvisionSuccess" Value="True" />
</Section>

可以使用 XML 自动执行上述步骤 5。 这将导致未使用的应用程序类型自动注销。

<Section Name="Management">
  <Parameter Name="CleanupUnusedApplicationTypes" Value="true" />
  <Parameter Name="PeriodicCleanupUnusedApplicationTypes" Value="true" />     
  <Parameter Name="TriggerAppTypeCleanupOnProvisionSuccess" Value="true" />
  <Parameter Name="MaxUnusedAppTypeVersionsToKeep" Value="3" />
</Section>

清理节点上的文件和数据

应用程序文件的复制最终将文件分发到所有节点，具体取决于均衡操作。 这可能产生磁盘压力，具体取决于应用程序的数量及其文件大小。 即使节点上没有活动实例运行，以前的实例中的文件也会保留。 对于有状态服务使用的可靠集合中的数据也是如此。 这提供更高的可用性。 对于同一节点上的新应用程序实例，则无需复制文件。 对于可靠集合，仅必须复制增量。

若要完全删除应用程序二进制文件，必须取消注册应用程序类型。

关于减少磁盘压力的建议：

1. Remove-ServiceFabricApplicationPackage 这会从临时上传位置删除包。
2. Unregister-ServiceFabricApplicationType 通过从映像存储服务和所有节点中删除应用程序类型文件来释放存储空间。 默认情况下，删除管理器每小时运行一次。
3. CleanupUnusedApplicationTypes 会自动清理旧的未使用的应用程序版本。

   {
     "name": "Management",
     "parameters": [
       {
         "name": "CleanupUnusedApplicationTypes",
         "value": true
       },
       {
         "name": "MaxUnusedAppTypeVersionsToKeep",
         "value": "3"
       }
     ]
   }
   

4. Remove-ServiceFabricClusterPackage 删除旧的未使用的运行时安装二进制文件。

注意

一项功能正在开发中，目的是允许 Service Fabric 在应用程序从节点中撤走后删除应用程序文件夹。

后续步骤

有关开发、测试和管理 Service Fabric 应用程序与服务的详细信息，请参阅：

• Reliable Actors
• Reliable Services
• 部署应用程序
• 应用程序升级
• 可测试性概述