本章可帮助您在开发 Google Chat 应用时选择实现架构。
架构样式
本部分介绍一些用于创建应用的最常用架构方法。如需帮助确定哪种方法最适合您的应用，请参阅选择服务架构。
服务架构
Google Chat 支持与应用集成，但不实现应用逻辑。此逻辑需要在代码中使用适合您的应用的任何库或服务来实现。
在哪里实例化代码以及代码如何与 Google Chat 交互，共同形成服务架构。下面介绍了最常用的方式。
网络服务
应用实现的最常见方式之一是在本地服务器中使用网络服务或其他 HTTP 实现。在此设计中，您将 Google Chat 配置为通过 HTTP 与远程服务集成：
这样，实现便可以利用系统中已存在的现有库和组件。
Cloud Pub/Sub
如果设备实现位于防火墙后面，Google Chat 可能无法对其发起 HTTP 调用。解决此问题的一种方法是使用 Google Cloud Pub/Sub，即应用订阅的主题包含 Google Chat 中的消息：
在这种安排下，应用实现仍必须使用 HTTP 向 Google Chat 发送消息。
Apps 脚本
您可以完全在 Apps 脚本中创建应用逻辑。这对也与 Google Workspace 服务集成的应用尤其有用。此类应用可以使用 Google 表格、幻灯片、日历、云端硬盘等读取和写入数据。
考虑实现在 Apps 脚本中不实现是什么样子的。与 Google Chat 和 Google Workspace 服务集成的 HTTP 聊天机器人将如下所示：
使用 Apps 脚本及其内置的 Google Workspace 服务和隐式身份验证模型来实现此类应用要简单得多（尤其是在身份验证方面）。
传入的网络钩子
您可以使用 Google Chat API 调用来创建仅向聊天室注入消息的应用。此方法已“硬编码”到特定的聊天室，并且不允许用户互动，而且此类应用无法共享或发布。
传入的 webhook 最适合报告一次性提醒或状态的应用，或者某些类型的应用的原型设计。
应用逻辑实现
Google Chat 不会限制应用逻辑的实现方式。您可以创建简单的固定语法命令解析器，使用高级 AI 和语言处理库或服务，或其他任何适合您的特定目标的内容。
命令解析器
命令驱动型应用会检查来自 Google Chat 的事件的消息内容，然后从此内容中提取命令和参数。
一种简单的方法是对消息进行令牌化，提取命令，然后引用将命令映射到每个命令的处理程序函数的字典。
自然语言处理
许多应用实现都使用自然语言处理 (NLP) 技术来确定要的用户请求的内容。实现 NLP 的方法有很多，Google Chat 并不关注您使用的方法。
您可以在应用实现中使用一项强大且常用的服务，那就是 Dialogflow。借助该服务，您可以使用意图/操作模型创建智能代理。
选择服务架构
本部分将帮助您确定应用的服务架构。
一般注意事项
在决定服务架构时，您应该考虑多种因素。以下各部分将对此进行说明。做出选择部分可帮助您根据这些方面选择架构。
- 应用适合哪些人使用？
- 应用将访问哪些资源？
- 您会采用哪些对话模式？
以下各部分将对此进行说明。做出选择部分可帮助您根据这些方面选择架构。
应用的受众群体
一个应用可能有许多潜在受众群体。以下是此类情况的一些示例：
- 您自己的个人应用
- 只有您团队中少数人
- 在整个组织范围内安装
- 在 Marketplace 上分发
访问资源
您应确定应用需要访问的资源；这些资源可能包括：
- Google Workspace 资源
- 其他 Google API 和系统
- 外部（非 Google）资源
对话模式
此外，还应考虑您希望应用如何与用户互动。下面几段将介绍您的应用可能会实现的一些对话模式。
通话和响应（同步）
在此模式中，应用以一对一的方式响应用户的消息。 一条发送给应用的用户消息将导致应用产生一条响应。
多个响应（异步）
这种模式的特点是用户与应用之间进行双向通信，应用会生成任意数量的其他消息。例如，用户可能从应用请求内容（应用应发送初始回复来确认请求），然后应用将一条或多条消息发送回发出请求的聊天室。
单程距离应用
有时，创建将消息注入聊天室但从不接收用户事件的应用很有用。这真的不是对话式，但对于闹钟报告等操作非常有用。
单向应用
虽然可以创建仅接收和处理消息的应用，而无需向其提供任何响应或消息，但这会导致用户体验不佳，我们强烈建议不要这种做法。
做出选择
那么，您应该为自己的应用实现选择哪种服务架构？当然，如果您有要集成到 Google Chat 中的现有应用，则很可能需要使用或调整现有实现。
如果您正在开发新应用，下图显示了针对各种用例建议的架构选择。
