请求延迟时间和错误处理最佳实践

本页介绍了优化 Cloud Healthcare API 中请求延迟时间和处理错误的最佳实践。在规划和设计系统架构时，请实现这些做法。

Google 提供服务等级协议 (SLA)，其中定义了 Cloud Healthcare API 服务的预期正常运行时间以及客户端如何处理错误。如需了解详情，请参阅 Cloud Healthcare 服务等级协议 (SLA)。

实现重试逻辑和超时

如需处理因请求失败而导致的延迟和错误，请实现适当的重试逻辑和超时设置。设置超时时长时，请留出足够的时间来执行以下操作：

  • 让 Cloud Healthcare API 处理请求。
  • 确定错误是源自服务还是客户端。

您可以重试某些错误，但其他错误无法重试，并且会在多次重试后仍然存在。例如，如果请求数据格式不正确，服务器会返回 400 Bad Request 状态代码。在您修正数据之前，请求不会成功。

如需处理这些情况，您需要规划最终错误状态。

如需详细了解重试逻辑和超时，请参阅重试失败的请求。

在多个层级处理错误

当中间件与 Cloud Healthcare API 交互时，请在客户端和中间件中实现重试逻辑和超时。如果客户端在超出重试次数限制后遇到错误，您必须能够确定错误是发生在客户端、中间件还是底层 Cloud Healthcare API 服务中。在规划最终错误状态时，这一点尤为重要。

请考虑以下场景：

  1. 中间件在发送请求时收到 Cloud Healthcare API 发送的 500 Internal Server Error 错误。
  2. 中间件层会再重试请求五次，达到其上限，然后停止重试。
  3. 客户端会收到最终的 500 Internal Server Error 错误。

请务必注意，错误源自 Cloud Healthcare API，而非中间件。为简化调试，请在返回给客户端的错误中提供此信息。

以下图表显示了以下场景：中间件代理在将请求从客户端转发到 Cloud Healthcare API 时收到 500 Internal Server Error 错误。客户端和代理都实现了错误处理和重试。

客户端/中间件/服务器堆栈中处理错误的位置示意图。
图 1. 您需要在客户端和代理层实现重试逻辑和超时。

图 1 显示了以下步骤：

  1. 客户端通过中间件代理向 Cloud Healthcare API 发送有效请求。
  2. 代理会将请求转发给 Cloud Healthcare API。
  3. Cloud Healthcare API 会向代理返回 500 Internal Server Error 错误。代理会再重试五次，直到达到重试次数上限。

  4. 代理会将最终错误状态 500 Internal Server Error 返回给客户端。

    按照前面显示的建议，您可以让代理向客户端返回以下错误，以调试最终错误状态： 

    Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

    添加有关 Cloud Healthcare API 返回的错误的任何其他信息。

有时，客户端或代理会收到超出重试次数限制的 500 Internal Server Error 错误，并且无法再次重试。在这种情况下，可能需要人工干预来诊断错误是来自代理还是来自 Cloud Healthcare API。

选择要重试的错误

根据系统的架构，您可以重试某些错误，并忽略其他错误。以下是可重试的 Cloud Healthcare API 错误代码的非完整列表：

  • 408 Request Timeout
  • 425 Too Early
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

这些错误通常不会以相同的频率发生，有些错误可能永远不会发生。

系统架构影响

系统的架构会影响错误的重试方式和时间。

例如，在客户端直接与服务器通信的架构中，如果客户端收到 Cloud Healthcare API 发出的 401 UNAUTHENTICATED 错误，则可以重新进行身份验证并重试其请求。

假设某个系统在客户端和 Cloud Healthcare API 之间有一个中间件层。如果客户端已正确进行身份验证，但过期的身份验证令牌导致了问题，则中间件必须刷新令牌并重试请求。

分析最终错误状态后，您可以根据调查结果调整客户端重试的错误。

针对最终错误状态进行规划

即使实现了重试逻辑和超时，客户端或中间件在重试次数耗尽之前也可能会收到错误。在重试次数和超时用尽之前返回的最后一个错误是最终错误状态。您可能会遇到数据一致性错误的最终错误状态。

有时，最终错误状态需要人工干预。尝试实现解决方案来解决请求的最终错误状态。否则，请记录最终错误状态，以便人工进行审核。

在规划如何处理最终错误状态时，请考虑以下事项：

  • 如果 FHIR 事务或软件包无法成功完成，是否需要停止处理依赖项。
  • 如果许多虚拟机 (VM) 实例开始永久失败，客户端必须报告失败的请求。问题解决后，客户端必须重试请求。
  • 监控系统、提醒系统和服务等级目标 (SLO) 对确保系统稳定至关重要。如需了解详情，请参阅测试和监控。

规划延迟时间增加

Cloud Healthcare API 是一项可伸缩且高性能的服务，但由于以下原因，请求延迟时间可能仍会有所不同：

  • 请求之间的细微差异（即使看起来不重要）也可能会导致额外的处理时间。
  • 类似的请求可能具有不同的延迟时间。 例如，如果两个类似的请求都会向数据存储空间添加记录，但其中一个请求超出了会触发额外任务（例如分配更多存储空间）的阈值，那么这两个请求的延迟时间可能会有所不同。
  • Cloud Healthcare API 会并发处理多个请求。客户端发送请求的时间（以秒为单位）可能与 Cloud Healthcare API 承受比平时更大负载的时间重合。
  • 如果 Cloud Healthcare API 实体资源（例如磁盘）正在处理许多请求，则需要先完成队列中的任务，然后才能处理其他请求。
  • 有时，Cloud Healthcare API 会重试服务器端错误，这可能会增加客户端的延迟时间。
  • 单区域位置或多区域位置中的数据可能在不同数据中心中有多个副本。如果您的请求在原始请求或重试时被路由到多个数据中心，延迟时间可能会增加。

使用百分位延迟时间进行规划

您可以通过分析请求的百分位延迟时间来为延迟时间增加做好准备。以下示例介绍了第 50 百分位的延迟时间和第 99 百分位的延迟时间：

  • 第 50 百分位延迟时间是指处理速度最快的 50% 请求的最长延迟时间（以秒为单位）。例如，如果第 50 百分位的延迟时间是 0.5 秒，表示有 50% 的请求可以在 0.5 秒内得到处理。第 50 百分位的延迟时间也称为“中位数延迟时间”。
  • 第 99 百分位延迟时间是指所有请求中处理速度最快的 99% 的最长延迟时间（以秒为单位）。例如，如果第 99 百分位的延迟时间为 2 秒，则表示有 99% 的请求可以在 2 秒内得到处理。

如果您分析的是 Cloud Healthcare API 仅处理了少量请求的某个时间段内的百分位延迟时间，则百分位延迟时间可能没有用处，也无法反映整体性能，因为离群请求可能会产生很大影响。

例如，假设 Cloud Healthcare API 中的某个进程在 100 分钟内处理了 100 个请求。100 分钟的第 99 百分位延迟时间将基于单个最慢的请求。使用单个请求进行延迟时间测量不足以了解是否存在性能问题。

在较长的时间段（例如 24 小时）内收集更大的请求样本，可以更深入地了解系统的整体行为。您可以使用这些示例来确定系统如何应对高流量。