微服务

该服务由以下无状态微服务组成：

• Analytics：记录助手与客户之间发生的交谈。 这些用户交谈日志可在产品的“分析”页面中使用，也可通过 /logs API 端点使用。 在 1.5.0 发行版中引入。 “分析”功能依赖于仅在 Red Hat OpenShift 4.5 和更高版本上支持的微服务。

• CLU：Conversational Language Understanding 接口，也称为 Natural Language Understanding (NLU)，这是语言理解管道的入口点，将在其中分析文本以查找意向和实体提及项。 Store 微服务使用 LiteLinks 协议来调用此微服务，以启动机器学习训练。 NLU 微服务可控制机器学习模型的生命周期。 它将Store微服务使用的工作区ID映射到机器语言，以理解管道的内部ID。 NLU 微服务将机器学习模型的训练数据上载到 MinIO 对象存储器。 需要训练语言模型时（例如，编辑意向后），NLU 微服务会调用 Master 微服务。 更新的模型可用时，NLU 会调用 TAS 微服务来分析客户提供的用户输入。 工作空间标识采用 UUID 格式。 语言理解流程中模型的内部ID通常遵循正则表达式模式 vn-[0-9a-f]*-[0-9a-f]*。

• CLU Embedding：为语言理解管道中的其他微服务提供词嵌入项。 TAS、ED-MM 和训练 pod 都使用 gRPC 协议来调用 CLU Embedding 微服务。

• Dialog：处理在对话技能中定义的对话树，以生成对用户输入的响应。 根据上下文（从前一轮交谈中传递的变量）以及在用户输入中识别到的意向和实体，此服务可沿着技能中的对话树来查找相应的响应。 Dialog 还负责对其他服务或程序发起程序化调出。 此微服务（有时称为 Dialog 运行时）是由 Store 微服务调用的 LiteLinks 服务器。 它有一个用于对话技巧的内存缓存，并使用 Redis 作为对话技巧的缓存。

• ED-MM：识别用户输入中的上下文实体。 此微服务是语言理解管道的一部分。 ED-MM 是 Entities Distro model mesh（Entities Distro 模型网）的首字母缩写。 该服务基于模型-网格模式实现ED-MM微服务。 （有关更多信息，请参阅模型网。） 仅当正在处理的对话技能在其训练数据中具有上下文实体时，TAS 微服务才会调用 ED-MM 微服务来对用户输入求值。 上下文实体绑定到上下文。 ED-MM微服务从 MinIO 加载模型。 在运行时，这些模型用于查找实体并验证上下文。 ED-MM 微服务还可访问 CLU Embedding 服务以获取词嵌入项。

• 网关：与 IBM Cloud Pak for Data API交互并模拟公共 IBM Cloud 行为的适配层。 此层的 pod 名为 ${release-name}-addon-assistant-gw-deployment。

  ${release-name} 为 watson-assistant。

  此层提供的功能如下：

  • 将服务安装注册到 IBM Cloud Pak for Data中。
  • 对于 API 请求，添加 Store 微服务所需的认证数据。
  • 在创建或删除服务实例时通知 Store 微服务。
  • 在用户通过 Web UI 来请求实例详细信息时，模拟 IBM Cloud 接口，以便 UI 微服务可以返回信息。

  API 请求到达时，首先由 IBM Cloud Pak for Data Ingress Nginx 服务器进行处理。 Nginx 服务器配置为调用 Gateway 微服务来检查请求的授权并获取其认证数据。 Nginx 服务器会向原始请求添加头，然后调用 Store 微服务。 但是，初始步骤不会生成任何日志。 要查看来自入局 API 请求的第一个日志，请查看 Store 微服务中的日志。

• Integrations：支持内置集成（例如 Web 聊天和预览链接）的服务。 在 1.5.0 发行版中引入。

• Master：控制底层意向和实体模型的生命周期。 此微服务是语言理解管道的一部分。 NLU 微服务使用 LiteLinks 向 Master 微服务发送请求，以训练新模型。 创建对话技能或更新现有对话技能时，会发生此类型的请求。 在成功训练模型之后，将调用 TAS 微服务来装入该模型。

• 数字系统实体：管理系统实体（如 @sys-date 或 @sys-number ）使用的数值识别。 在 1.5.0 发行版中引入。

• Recommends：支持来自 Watson 的建议，例如基于字典的实体同义词和意向冲突。 仅在 Web UI 中进行编写时使用。 例如，用户请求实体的同义词建议时，UI 微服务会调用 Store 微服务。 Store 微服务将请求转发给 Recommends 微服务。 Recommends 微服务使用存储在 MongoDB 中的嵌入项来查找当前词的同义词，并将其存储在 Redis 高速缓存中。 然后，此微服务会向 Store 微服务发送包含同义词列表的响应。 类似的工作流程可用于识别对话技能中的意向冲突。

• Skill-search：管理对同一集群中启用的 Discovery 服务实例的 API 调用。 V2 /message API 调用到达 Store 微服务时，Store 会从 Redis 中检索会话状态信息，并开始处理技能。 正在处理的助手具有搜索技能时，Store 微服务会通过 HTTPS REST 调用此微服务。 该微服务查询 Discovery 实例，并将 Discovery 返回的输出转换为 v2 /message API架构。

• Spellchecker：更正使用 /message 请求提交的用户输入中所犯的拼写错误。 对于英语对话技能，会自动启用此自动更正功能；对于法语技能，可以开启此功能。 此微服务使用更正方法（例如，距离词汇表中词的编辑距离）和通用语言模型来提供基本的拼写检查功能。 如果启用，TAS微服务会在识别用户输入中的意图和实体之前，使用 gRPC 调用拼写检查器。 拼写检查器不依赖于数据存储，也不调用任何其他微服务。

• Store：处理所有助手 API 调用。 该微服务要么自行处理请求，要么调用处理请求所需的其它微服务。 例如，如果客户通过 v1 /message API调用提交用户输入，请求将发送到商店并由商店处理。 对于有状态 V2 /message API 调用，Store 会首先从 Redis 中检索会话状态信息。 然后，Store 会调用 NLU 微服务来分析用户输入，并识别输入中的任何意向和实体引用。 接下来，Store 会调用 Dialog 微服务来生成相应的响应以返回给客户。 Store 微服务会将助手、技能和工作空间定义存储在 PostgreSQL 数据库中。 Store 微服务会将会话状态（来自 V2 API）保存在 Redis 数据存储中。

• TAS：执行模型推断，即用于识别用户输入中的最佳匹配意向和实体。 TAS 是 Train and Serve（训练和服务）的首字母缩写，但主要服务于现有模型。 TAS 微服务将模型从 MinIO 存储器装入到内存中，并运行模型来查找意向。 TAS 微服务通过使用 LiteLinks 从 NLU 微服务进行调用。 TAS 和 ED-MM 微服务基于模型网模式。 （有关更多信息，请参阅模型网。） 如果需要，TAS 会调用语言理解管道中的其他微服务。 具体而言，TAS 调用 SireG 进行记号化，调用 ED-MM 来识别上下文实体（使用 gRPC），以及调用 Spellchecker 来更正拼写错误。 为了识别意图，TAS微服务需要词嵌入数据，该数据由CLU嵌入微服务提供。

• TF-MM：张量流模型网微服务用于管理通用语句编码器和自动编码器模型，以改进偏离主题和不相关的意向识别。 在 1.5.0 发行版中引入。

• UI：虚拟助手构建者用于创建技能和助手的 Web 应用程序。

数据源

微服务使用以下资源：

• Elastic：弹性数据存储用于存储客户消息。 这些用户对话记录可以从“分析”页面查看，也可以通过 /logs API端点搜索。 在 1.5.0 发行版中引入。

• Etcd：常用的分布式键/值存储解决方案。 Litelinks 客户机和服务器（Store、Dialog、NLU、Master、TAS 和 ED-MM）使用 Ectd 来发现服务。 语言理解管道中的微服务（NLU、Master、TAS 和 ED-MM）使用 Etcd 来存储元数据。 有关更多信息，请参阅 Etcd 存储。

• Kafka：用于入局客户消息的排队系统。 在 1.5.0 发行版中引入。

• PostgreSQL：常用的关系数据库。 此数据库仅由 Store 微服务使用，这是用于工作空间、技能和助手的主存储。 与 PostgreSQL 相关的部署和 pod 名称以 ${release-name}-store-postgres 为前缀。 有关更多信息，请参阅 PostgreSQL 数据存储。

• Multicloud Object Gateway: Multicloud Object Gateway 是实现 Amazon S3 API 的对象存储服务。 语言理解管道微服务（clu-controller、clu-serving、clu-training、tf-mm、ed-mm和dragonfly）使用它来存储和加载经过训练的意图和实体分类模型。 它由编写和运行时服务 (商店) 用于存储技能的版本化数据，还用作编写体验的异步上载的临时存储器。 在 Watson Assistant中，Multicloud Object Gateway 通常称为 Cloud Object Storage。 有关更多信息，请参阅 Multicloud Object Gateway。

• Redis：内存内部数据存储，通常用于对会话状态进行高速缓存或共享。 Store 微服务使用 Redis 来存储助手的当前交谈状态。 UI 微服务在 Redis 中存储会话状态。 Recommends 和 Dialog 微服务使用 Redis 实例作为高速缓存。

1.5.0：从 1.5.0 发行版开始，不再使用以下数据源：

• MongoDB：面向文档的数据库。 Mongo 以只读方式用来存储嵌入项以及 Recommends 微服务用于同义词建议的其他数据。

  MongoDB 是一个基于文档的分布式数据库。 MongoDB 数据库有三个 pod。 MongoDB 数据库以副本集方式运行，即一个 pod 以协调者角色在读/写方式下运行，其余 pod 为只读并以辅助角色运行。 协调者 pod 中的更改会复制到辅助 pod。 在服务安装期间，数据由 Kubernetes 作业装入到 Mongo 数据库中。 在安装服务后，就不会再向 Mongo 数据库写入任何数据。 仅 Recommends 微服务会从 Mongo 中读取数据。 Recommends pod 在创建时会检查 Mongo 是否正在运行，并会等待 Mongo 数据库中装入必需的数据。

  在安装过程中，Recommends 等待数据装入到 Mongo 数据库中的过程可能需要 30 分钟（或更长时间）。

  • MongoDB pod 的名称遵循约定 ${release-name}-ibm-mongodb-server-[0-9]*。 对于发行版名称较长的情况，名称会简写为 ${release-name prefix}-[a-f0-9]{4}-336f-server-*。
  • 在安装服务期间运行的 Kubernetes 作业的名称是 ${release-name}-recommends-load-mongo。

  ${release-name} 为 watson-assistant。

4.7.0：从 4.7.0 版本开始，以下数据源不再使用：

• MinIO：MinIO 是用于实现 Amazon S3 API 的对象存储服务。 语言理解管道微服务（NLU、Master、TAS、ED-MM 和训练 pod）使用 MinIO 来存储和装入经过训练的模型，以用于意向和实体分类。 数据存储在 nlclassifier-icp 存储区中。 在 Watson Assistant 中，MinIO 通常称为 COS，这是 Cloud Object Storage 的首字母缩写。 有关更多信息，请参阅 MinIO。

训练组件

培训新车型是一项一次性、周期短、资源密集的活动。 模型在按需创建的 pod 中进行训练。 训练完成后，会除去这些 pod。 由于其瞬时性，培训组件不被视为标准微服务之一。 只有在需要培训模型时，才会使用培训舱这一组件。 每次在对话技能中添加或更改意向用户示例时，都会启动训练。

需要训练新的机器学习模型时，CLU 微服务会通知 Master 微服务。 Master 微服务将动态创建训练 pod。 如果训练运行失败，Master 微服务负责除去训练 pod 并进行重新训练。 如果模型被删除，它还负责从 MinIO 中移除该模型。 系统根据在 MinIO 存储器中存储的标志来确定训练运行是否成功完成。 Master 微服务必须对存储训练映像的 Docker 注册表具有 API 访问权。 从注册表中获取的映像元数据用于正确启动训练 pod。

由此组件启动的训练 pod 有时称为 SLAD pod。 SLAD 是 Statistical Learning and Discovery（统计学习和发现）的首字母缩写，这是开发了 pod 所用语言分类器的研究组的名称。 训练 pod 的名称以 tr[12]? 开头，后跟内部 vn-… 标识。 训练映像根据 chart 版本命名为 nlclassifier-training 或 clu-training。 ${release-name}-master-config 配置映射包含用于训练 pod 的 JSON 模板。

${release-name} 为 watson-assistant。

数据存储详细信息

以下部分将详细介绍服务如何使用数据存储。 目的是帮助您对安装期间或在数据中心内部署和运行服务后可能出现的问题进行故障诊断。

模型网

TAS 和 ED-MM 微服务使用模型网模式。 在模型网中，每个 pod 都包含一组装入的 NLP 模型。 模型装入位置的管理工作由模型网库负责。 在正常操作期间，只会将模型装入到一个 pod 中。 如果单个 pod 无法处理流至模型的流量，那么还会将该模型装入到其他 pod 中。 有关模型装入位置的元数据存储在 Etcd 中。

TAS 和 ED-MM 属于不同的模型网组。 每个组都有一组独立的 pod 和装入的模型。

下面说明了模型网在 ED-MM 微服务 pod 组中是如何运作的。 对于 ED-MM 微服务，您可能有两个 pod A 和 B。 gRPS 请求通过 Kubernetes DNS 接收上下文实体识别帮助。 请求将转至 pod A，但所需的上下文实体模型将装入到 pod B 中。 Pod A 上的模型网格通过使用 LiteLinks将请求转发到 pod B。 Pod B 使用相应的模型来识别输入中的上下文实体，然后向 pod A 发送响应。 Pod A 将响应中的信息发送回发送初始 gRPC 请求的服务。

对于 TAS 微服务，模型网的运作方式相同。 不同之处在于向 TAS 发出的入局请求是使用 LiteLinks 而不是 gRPC 发送的。 因此，NLU 和 Master 微服务无法了解在哪些 TAS pod 中装入了哪些模型。