选择 Google Chat 应用架构

本页面介绍了用于创建 Google Chat 应用的常用服务架构方法。如果您想将现有应用集成到 Google Chat 中，可以使用或调整现有实现。如果您正在构建新的 Chat 应用，此页面通过几种不同的方式提供了类似信息，以帮助您选择适合您使用场景的架构：

按特性和功能概览

下表重点介绍了 Chat 应用的主要特性和功能以及建议的 () 服务架构样式。在某些情况下，可以使用这些功能开发其他架构样式，但并不像其他架构样式 () 那样适合用例。

特性和功能

Web 或 HTTP 服务

Pub/Sub

Webhook

Apps 脚本

AppSheet

Dialogflow

Script

目标观众

您的团队

您所在的组织

公众

用户互动

使用自然语言处理

消息传递模式

发送和接收同步消息

发送和接收同步消息以及发送异步消息

仅发送异步消息

从外部系统向单个 Chat 聊天室发送消息

访问其他服务和系统

与其他 Google 服务相整合

在防火墙后通信

订阅 Google Workspace 活动

编码和部署方式

无代码开发

低代码编写

使用您选择的编程语言进行开发

简化 DevOps

完成 DevOps 和 CI/CD 管理

服务架构样式

本部分介绍用于创建 Chat 应用的一些最常见的架构方法。

Web 或 HTTP 服务

Web 或 HTTP 服务是部署最频繁的架构，因为它为开发者构建公共 Chat 应用提供了最大的灵活性。建议将此架构用于以下使用场景：

  • 该聊天应用已在 Google Workspace Marketplace 中公开发布。
  • Chat 应用可以发送和接收所有消息传递模式：发送和接收同步消息、发送异步消息以及从外部系统发送消息。
  • 该聊天应用采用任何编程语言开发。
  • Chat 应用需要完整的 DevOps 和 CI/CD 管理。
  • Chat 应用服务在云端或本地服务器中实现。

在此设计中，您使用 HTTP 将 Chat 配置为与远程服务集成，如下图所示：

使用本地服务器中的网络服务的 Chat 应用架构。

在上图中，用户与 HTTP Chat 应用互动的信息流如下：

  1. 用户在 Chat 聊天室中向 Chat 应用发送消息。
  2. HTTP 请求会发送到 Web 服务器，该服务器是包含 Chat 应用逻辑的云端或本地系统。
  3. （可选）Chat 应用逻辑可以与外部第三方服务（例如项目管理系统或票务工具）进行交互。
  4. 网络服务器将 HTTP 响应发送回 Chat 中的 Chat 应用服务。
  5. 系统将响应发送给用户。
  6. （可选）Chat 应用可以调用 Chat API 来异步发布消息或执行其他操作。

此架构可让您灵活地使用系统中已有的现有库和组件，因为这些 Chat 应用可以使用不同的编程语言进行设计。您可以通过多种方式实现此架构。在 Google Cloud 上，您可以使用 Cloud Functions、Cloud Run 和 App Engine。如需开始使用，请参阅使用 Cloud Functions 构建 Google Chat 应用。

Pub/Sub

如果聊天应用是在防火墙后实现的，Chat 无法对其发起 HTTP 调用。一种方法是使用 Pub/Sub 启用 Chat 应用实现，以订阅从 Chat 传输消息的主题。Pub/Sub 是一种异步消息传递服务，它将生成消息的服务与处理这些消息的服务分离开来。建议将此架构用于以下使用场景：

  • Chat 应用是在防火墙后构建的。
  • Chat 应用会接收与 Chat 聊天室相关的事件。
  • Chat 应用会在贵组织中部署。
  • Chat 应用可以发送和接收同步消息，并且可以发送异步消息。
  • 该聊天应用采用任何编程语言开发。
  • Chat 应用需要完整的 DevOps 和 CI/CD 管理。

下图显示了使用 Pub/Sub 构建的 Chat 应用的架构：

使用 Pub/Sub 实现的聊天应用的架构。

在上图中，用户与 Pub/Sub Chat 应用互动的信息流如下：

  1. 用户在 Chat 中通过私信或 Chat 聊天室向 Chat 应用发送消息，或者事件发生在 Chat 应用具有有效订阅的 Chat 聊天室中。

  2. Chat 将消息发送到 Pub/Sub 主题。

  3. 应用服务器（包含 Chat 应用逻辑的云端或本地系统）会订阅 Pub/Sub 主题，以便通过防火墙接收消息。

  4. （可选）Chat 应用可以调用 Chat API 来异步发布消息或执行其他操作。

如需开始使用，请参阅将 Pub/Sub 用作 Chat 应用的端点。

Webhook

您可以通过对 Chat 网络钩子网址的调用来创建仅能向特定 Chat 聊天室发送消息的聊天应用。建议将此架构用于以下使用场景：

  • 系统会将 Chat 应用部署到您的团队。
  • Chat 应用会将消息从外部系统发送到单个 Chat 聊天室。

借助此架构，Chat 应用仅限于特定的 Chat 聊天室，并且不允许用户互动，如下图所示：

用于向 Chat 发送异步消息的传入网络钩子的架构。

在上图中，Chat 应用具有以下信息流：

  1. 聊天应用逻辑会从外部第三方服务（例如项目管理系统或票务工具）接收信息。
  2. Chat 应用逻辑托管在云端或本地系统中，此类系统可以使用网络钩子网址向特定 Chat 聊天室发送消息。
  3. 用户可以从该特定 Chat 聊天室中的 Chat 应用接收消息，但无法与 Chat 应用互动。

此类 Chat 应用无法在其他 Chat 聊天室中或与其他团队共享，也无法发布到 Google Workspace Marketplace。建议 Chat 应用使用传入的网络钩子来报告提醒或状态，或者进行某些类型的 Chat 应用原型设计。

如需开始使用，请参阅使用网络钩子向 Chat 发送消息。

Apps 脚本

您可以完全使用 JavaScript 创建 Chat 应用逻辑。Google Apps 脚本是一个适用于 Chat 应用的低代码开发平台。Apps 脚本负责处理授权流程和用于用户身份验证的 OAuth 2.0 令牌。您可以使用 Apps 脚本构建公开聊天应用，但由于存在每日配额和限制，我们不建议使用脚本。

建议将此架构用于以下使用场景：

  • Chat 应用会部署到您的团队或组织中。
  • Chat 应用可以发送和接收所有消息传递模式：发送和接收同步消息、发送异步消息以及从外部系统发送消息。
  • Chat 应用需要简化的 DevOps 管理。

此架构对于也与其他 Google Workspace 和 Google 服务（例如 Google 表格、Google 幻灯片、Google 日历、Google 云端硬盘、Google 地图和 YouTube）集成的聊天应用非常有用，如下图所示：

使用 Apps 脚本实现的 Chat 应用的架构。

在上图中，用户与 Apps 脚本聊天应用互动的信息流如下：

  1. 用户通过私信或在 Chat 聊天室中向 Chat 应用发送消息。
  2. 通过位于 Google Cloud 中的 Apps 脚本实现的 Chat 应用逻辑会接收消息。
  3. （可选）Chat 应用逻辑可以与 Google Workspace 服务（如日历或表格）或其他 Google 服务（如 Google 地图或 YouTube）集成。
  4. Chat 应用逻辑会将响应发回给 Chat 中的 Chat 应用服务。
  5. 系统将响应发送给用户。

如需开始使用，请参阅使用 Apps 脚本构建聊天应用。

AppSheet

您可以使用 AppSheet 创建网域共享聊天应用，且无需使用代码。您可以使用自动配置模式并按照模板构建常见的 Chat 应用操作，从而简化开发流程。但是，某些 AppSheet Web 应用功能在 Chat 应用中无法使用。

建议将此架构用于以下使用场景：

  • 系统会为您和您的团队部署 Chat 应用。
  • Chat 应用可以发送和接收同步消息，并且可以发送异步消息。
  • Chat 应用需要简化的 DevOps 管理。

下图显示了使用 AppSheet 构建的 Chat 应用的架构：

使用 AppSheet 实现的聊天应用的架构。

在上图中，用户与 AppSheet Chat 应用互动的信息流如下：

  1. 用户在 Chat 中通过私信或 Chat 聊天室向 Chat 应用发送消息。
  2. 在 AppSheet 中实现的 Chat 应用逻辑（位于 Google Cloud 中）会接收消息。
  3. （可选）Chat 应用逻辑可以与 Google Workspace 服务（如 Apps 脚本或 Google 表格）集成。
  4. Chat 应用逻辑会将响应发回给 Chat 中的 Chat 应用服务。
  5. 系统将响应发送给用户。

如需开始使用，请参阅使用 AppSheet 构建聊天应用。

Dialogflow

您可以使用 Dialogflow 创建一个 Chat 应用，Dialogflow 是一个用于自动对话和动态响应的自然语言平台。 建议将此架构用于以下使用场景：

  • Chat 应用可以发送和接收同步消息。
  • Chat 应用使用自然语言处理技术来回复用户并与之互动。

下图显示了使用 Dialogflow 构建的 Chat 应用的架构：

使用 Dialogflow 实现的聊天应用的架构。

在上图中，与 Dialogflow Chat 应用互动的用户具有以下信息流：

  1. 用户在 Chat 中通过私信或 Chat 聊天室向 Chat 应用发送消息。
  2. 位于 Google Cloud 中的 Dialogflow 虚拟客服会接收并处理消息以生成响应。
  3. （可选）Chat 应用逻辑可以与外部第三方服务（例如项目管理系统或票务工具）进行交互。
  4. Dialogflow 代理将响应发送回 Chat 中的 Chat 应用服务。
  5. 系统将响应发送给用户。

如需开始集成，请参阅 Dialogflow ES Chat 集成或 Dialogflow CX Chat 集成。

命令行应用或脚本

您可以创建命令行应用或脚本来向 Chat 发送消息或执行其他操作（例如创建聊天室或管理聊天室的成员），但不允许用户在 Chat 中直接调用或响应 Chat 应用。建议将此架构用于以下使用场景：

  • 该聊天应用采用任何编程语言开发。
  • Chat 应用只能发送异步消息。

下图展示了此架构：

使用命令行应用或脚本实现的 Chat 应用的架构。

在上图中，Chat 应用具有以下信息流：

  1. Chat 应用会调用 Chat API 来发送消息或执行其他操作。
  2. Chat 会执行请求的操作。
  3. （可选）Chat 应用会在 CLI 中输出一条确认消息。

Chat 应用逻辑实现

Chat 不会限制您实现 Chat 应用逻辑的方式。您可以创建固定语法命令解析器、使用高级 AI 和语言处理库或服务、订阅和响应事件，或适用于您的特定目标的其他任何工具。

处理用户互动

聊天应用可以通过多种方式接收和响应用户互动。用户互动是指用户为调用 Chat 应用或与 Chat 应用互动而进行的任何操作。

命令解析器

命令驱动型聊天应用会检查 Chat 应用互动事件的载荷，然后从此内容中提取命令和参数。例如，请参阅设置斜杠命令以与 Chat 用户互动。

另一种方法是标记化消息，提取命令，然后引用将命令映射到每个命令的处理程序函数的字典。

基于对话框的界面

基于对话框的应用通过显示基于卡片的对话框（用户可以在其中与 Chat 应用互动，例如填写表单或请求操作）来响应 Chat 应用互动事件。

每当用户在对话框中执行操作时，系统都会向 Chat 应用发送新的互动事件，该应用可以通过更新对话框或发送消息进行响应。

自然语言处理

许多 Chat 应用实现使用自然语言处理 (NLP) 来确定用户请求的内容。实现 NLP 的方式有多种，您可以选择按照自己喜好的方式来实现 NLP。

您可以通过 Dialogflow ES 或 Dialogflow CX Chat 集成，在 Chat 应用中使用 NLP，以创建虚拟客服来实现自动对话和动态响应。

主动向 Chat 发出请求

聊天应用也可以向 Chat 发送消息或其他请求，这些请求不是由 Chat 中的直接用户互动触发的。相反，这些聊天应用可由第三方应用触发，也可通过用户的命令行调用触发，但用户无法直接在 Chat 中与这些 Chat 应用互动。

非交互式聊天应用使用 Chat API 向 Chat 发送消息或其他类型的请求。

对话模式

您应该考虑希望 Chat 应用如何与用户互动。以下部分介绍了 Chat 应用可能实现的对话模式。

调用和响应（同步）

在同步调用和响应模式中，Chat 应用会一对一回复用户发送的消息。用户向 Chat 应用发送的一条消息会导致 Chat 应用发出一条响应，如下图所示：

同步消息的架构。

在上图中，用户与 Chat 应用互动的信息流如下：

  1. 用户向 Chat 应用发送同步消息，例如“我的下一场会议是什么？”。
  2. Chat 应用向用户发送同步消息，例如“Dr. Silva at 2:30”。

对于此类对话模式，您可以使用网络服务、Pub/Sub、Apps 脚本、AppSheet 或 Dialogflow 实现 Chat 应用架构。

多个响应（异步）

多响应模式可包括同步和异步消息。这种模式的特点是用户与 Chat 应用之间存在双向通信，即 Chat 应用会生成任意数量的额外消息，如下图所示：

异步消息的架构。

在上图中，用户与 Chat 应用互动的信息流如下：

  1. 用户向 Chat 应用发送同步消息，例如“监控流量”。
  2. Chat 应用向用户发送同步消息以确认请求，例如“Monitoring on”。
  3. 之后，Chat 应用会通过调用 REST API 向用户发送一条或多条异步消息（例如“新流量”）。
  4. 用户向 Chat 应用发送额外的同步消息，例如“忽略流量”。
  5. Chat 应用向用户发送同步消息以确认请求，例如“关闭监控”。

对于此类对话模式，您可以使用网络服务、Pub/Sub、Apps 脚本或 AppSheet 实现 Chat 应用架构。

订阅事件（异步）

在异步事件驱动型模式中，Chat 应用使用 Google Workspace Events API 订阅事件。事件驱动型 Chat 应用会检查 Chat 订阅事件的载荷，然后根据事件类型做出响应。当 Chat 聊天室中发生事件时，如果 Chat 应用具有有效订阅，那么 Chat 会将事件发送到 Chat 应用。然后，Chat 应用可以选择生成任意数量的异步响应，并使用 Chat API 将其发回到 Chat。

您可以使用此类逻辑更新外部系统（例如工单管理系统），或者异步向 Chat 聊天室发送消息（例如在新用户加入 Chat 聊天室时发送欢迎消息）。

下图显示了事件驱动型对话模式：

事件驱动型消息的架构。

在上图中，Chat 与 Chat 应用之间的交互具有以下信息流：

  1. Chat 应用可订阅 Google Chat 聊天室。
  2. Chat 应用订阅的聊天室会发生变化。
  3. Chat 应用会将事件传送到 Pub/Sub 中的某个主题，该主题将用作订阅的通知端点。该事件包含有关资源中发生了什么更改的数据。
  4. 聊天应用会处理包含事件的 Pub/Sub 消息，并在必要时执行操作。

对于这种对话模式，您可以使用 Pub/Sub 实现 Chat 应用架构。

来自 Chat 应用的单向消息

来自 Chat 应用模式的单向消息允许 Chat 应用向 Chat 聊天室发送异步消息，但不允许用户直接与 Chat 应用互动。这种模式不是对话式的，也不是交互式的，但对于提醒报告等功能非常有用，如下图所示：

单向消息的架构。

在上图中，与 Chat 应用位于同一空间的用户具有以下信息流：

  • Chat 应用通过调用 Chat API 或将消息发布到网络钩子网址（例如“队列溢出提醒”）向用户发送异步消息。
  • （可选）Chat 应用发送其他异步消息。

对于此类对话模式，您可以使用网络服务、网络钩子、Apps 脚本、AppSheet、命令行应用或脚本实现 Chat 应用架构。

向 Chat 应用发送单向消息

通过向 Chat 应用模式发送的单向消息，用户可以向 Chat 应用发送消息，但 Chat 应用不会响应，同时仍在处理请求。 虽然从技术层面来讲，这种架构可行，但会导致用户体验不佳，因此我们强烈建议不要采用这种模式。