服务使用最佳实践

本指南介绍了使用 Dialogflow 服务的最佳做法。这些指导准则旨在提高操作效率和准确性，同时保证服务的合理响应时间。

您还应该查看所有代理类型的一般代理设计指南以及专门用于设计语音代理的语音代理设计指南。

生产化

在生产环境中运行代理之前，请确保实现以下最佳做法：

启用审核日志

在您的项目中为 Dialogflow API 启用数据访问审核日志。这有助于跟踪与此项目关联的 Dialogflow 代理中的设计时更改。

代理版本

您应始终使用代理版本来处理生产流量。如需了解详情，请参阅版本和环境。

创建代理备份

保持已导出的最新代理备份。如果您或您的团队成员不小心删除了代理或项目，您可以快速恢复。

客户端重复使用

您可以在应用的执行生命周期内重复使用 *Client 客户端库实例，从而提高应用性能。

最重要的是，您可以通过重复使用 SessionsClient 客户端库实例来提高检测意图 API 调用的性能。

请参阅会话数参考。

如需了解详情，请参阅客户端库最佳做法指南。

批量更新代理

如果您在短时间内发送多个单独的代理更新 API 请求，您的请求可能会受到限制。这些设计时 API 方法不能用于处理更新速率较高的单一代理。

为此，某些数据类型提供了批处理方法：

  • 使用 batchUpdate 或 batchDelete 方法，而无需发送多个 EntityTypes create、patch 或 delete 请求。
  • 使用 batchUpdate 或 batchDelete 方法，而无需发送多个 Intents create、patch 或 delete 请求。

API 错误重试

调用 API 方法时，您可能会收到错误响应。有些错误应该重试，因为这些错误通常是暂时性问题所致。错误分为以下两种类型：

此外，您还应该重试执行指数退避算法。这样，您的系统就可以在 API 服务负载过重时找到一个可接受的速率。

Cloud API 错误

如果您使用的是 Google 提供的客户端库，则系统会为您执行采用指数退避算法的 Cloud API 错误重试。

如果您已使用 REST 或 gRPC 实现自己的客户端库，则必须为您的客户端实现重试。 如需了解哪些错误应重试或哪些错误不应重试，请参阅 API 改进建议：自动重试配置。

网络钩子错误

如果 API 调用触发了网络钩子调用，则您的网络钩子可能会返回错误。即使您使用 Google 提供的客户端库，系统也不会自动重试网络钩子错误。您的代码应该重试从网络钩子接收到的 503 Service Unavailable 错误。如需了解网络钩子错误类型以及如何检查这些错误，请参阅网络钩子服务文档。

负载测试

在将代码发布到生产环境之前，最好对系统执行负载测试。在实现负载测试之前，请考虑以下几点：

摘要 详细信息
提升负载。 负载测试必须增加应用于 Dialogflow 服务的负载。该服务的目的不是处理突然的负载突发事件，这在实际流量中很少见。该服务需要一段时间才能根据负载需求进行调整，所以需缓慢提高请求速率，直到测试达到所需负载。
系统会对 API 调用收费。 在测试期间，您需要支付 API 调用费用，且调用次数会受到项目配额的限制。
使用 test doubles。 在负载测试期间，您可能不需要调用 API。如果负载测试的目的在于确定系统如何处理负载，那通常最好使用 test double代替对 API 的实际调用。您的 test double 可以模拟 API 在负载下的行为。
使用重试。 负载测试必须使用退避算法执行重试。

从最终用户设备安全地调用 Dialogflow

切勿将用于访问 Dialogflow API 的私钥存储在最终用户设备上。这适用于直接在设备上存储密钥以及在应用中对密钥进行硬编码。当您的客户端应用需要调用 Dialogflow API 时，它应该将请求发送到安全平台上的开发者拥有的代理服务。代理服务可以进行经过身份验证的实际 Dialogflow 调用。

例如，您不得创建直接调用 Dialogflow 的移动应用。执行此操作需要您将私钥存储在最终用户设备上。您的移动应用应改为通过安全的代理服务传递请求。