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

本页面介绍在 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.需要实现重试逻辑和超时的层是 Client 和 Proxy。

图 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 秒，则 Cloud Healthcare API 会在 0.5 秒内处理 50% 的请求。第 50 百分位的延迟时间也称为“中位数延迟时间”。
  • 第 99 百分位的延迟时间是指，99% 请求的最快延迟时间（以秒为单位）。例如，如果第 99 百分位的延迟时间是两秒，那么 Cloud Healthcare API 会在两秒内处理 99% 的请求。

如果您分析 Cloud Healthcare API 仅在部分请求的基础上处理的百分位延迟时间，则该百分位延迟时间可能无用，或无法指示整体性能，因为离群值请求可能会有很大影响。

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

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