1

我们想知道是否有一种内置方法可以在 Service Fabric 中作为服务升级的一部分来预热服务，类似于在请求命中之前可以预热的各种方法，例如基于 IIS 的应用程序池。理想情况下，我们希望各个服务在被视为已启动并可供其他服务联系之前执行一些预热任务，作为其初始化的一部分（可能是缓存加载、恢复等）。此预热应该是升级域处理的一部分，因此升级过程应该等待预热完成并且服务报告为 OK/Ready。

其他人如何处理此类场景，控制向服务结构发出特定服务已完全启动并准备好与其他服务联系的信号的过程？

4

2 回答 2

2

在卫生政策中有这样一个概念：

HealthCheckWaitDurationSec在升级域上完成升级后，Service Fabric 评估应用程序的运行状况之前等待的时间（以秒为单位）。这个持续时间也可以被认为是应用程序在被认为是健康的之前应该运行的时间。如果健康检查通过，则升级过程继续到下一个升级域。如果运行状况检查失败，Service Fabric 会等待一段时间（UpgradeHealthCheckInterval），然后再次重试运行状况检查，直到达到 HealthCheckRetryTimeout。默认和推荐值为 0 秒。

资源

这是一个固定的等待期。

您也可以自己发出 Health 事件。例如，您可以在热身时报告健康状况“未知”。并调整您的健康政策 (HealthCheckWaitDurationSec) 来检查这一点。

于 2016-06-14T06:22:10.857 回答
1

报告健康状况会有所帮助。您不能报告未知，您必须尽早报告错误，然后在您的服务准备好时清除错误。警告和确定不影响升级。要清除错误，您的服务可以报告健康状态 Ok，RemoveWhenExpired=true，低 TTL（阅读有关如何报告的更多信息）。

您必须根据最大预热时间增加 HealthCheckRetryTimeout。否则，如果执行了运行状况检查并且集群被评估为错误，则升级将失败（并根据您的策略回滚或暂停）。

所以，事件的顺序是：

  • 您的服务报告错误 - “正在预热”
  • 升级等待固定的 HealthCheckWaitDurationSec（您可以将其设置为最小预热时间）
  • upgrade 执行健康检查：如果服务尚未预热，则健康状态为错误，因此升级重试，直到达到 HealthCheckRetryTimeout 或您的服务不再处于错误状态（预热完成并且您的服务清除了错误）。
于 2016-07-08T16:45:08.723 回答