发布于: Oct 30, 2022
如今，众多 Amazon Web Services 客户利用 Amazon Lex 智能对话机器人在电话及其他多种渠道之上增强 Amazon Connect 自助服务的对话体验。借助 Amazon Lex，呼叫方（用 Amazon Connect 术语描述，即客户）能够快速获取问题的答案，几乎不需要人工客服的介入。但这同时也给服务可用性提出了更高的要求，因此引发了新的问题：我们该使用哪种架构模式提升机器人可用性？在本文中，我们将探讨一种跨区域方法，通过在多个区域中部署 Amazon Lex 机器人以提高服务可用性。
在这套解决方案中，一旦 Amazon Lex 出现服务可用性问题，Amazon Connect 流能够将中断影响控制在最低程度，借此实现业务连续性。此架构模式使用以下组件：
- 两个 Amazon Lex 机器人，各自处于不同的区域内。
- 两个机器人由负责区域检查的 Amazon Lambda 函数进行触发，并集成至 Amazon Connect 流内。
- 用于检查机器人运行状况的 Lambda 函数。
- 为 Amazon Connect 区域中的主机器人创建一套 Amazon DynamoDB 表，并通过 Lambda 函数进行读取。
- 使用 DynamoDB 表保存 Amazon Connect 与 Amazon Lex 之间的区域映射。由之前提到的运行状态检查函数负责更新此表。区域检查函数读取此表，以获取 Amazon Connect 与 Amazon Lex 的最新主区域映射。
之所以要在两个区域内设置完成相同的 Amazon Lex 机器人，是为了能够随时在辅助区域中启动该机器人，进而在主区域发生故障时及时替换。
随后的两节，主要描述集成有 Amazon Lex 机器人的 Amazon Connect 流如何在主区域发生服务故障或中断的情况下，快速实现恢复并使用辅助区域内的 Amazon Lex 正常响应客户呼叫。
运行状况检查函数将根据 TEST_METHOD Lambda 环境变量对两个 Amazon Lex 运行时 API 之一进行调用（PutSession 或 PostText）。您可以根据自己的喜好及用例要求选择其中一个。PutSession API 调用不会产生任何额外的 Amazon Lex 关联费用，但无法测试 Amazon Lex 提供的自然语言理解（NLU）功能。PostTextAPI 则允许您检查 Amazon Lex 的 NLU 功能，且额外成本不高。
运行状况检查函数会将通过测试的区域名称，更新至 DynamoDB 表（lexDR）中的 lexRegion 列。如果主区域正常通过运行状况检查，则 lexRegion 将被更新为主区域名称。如果运行状况检查失败，则该函数将基于辅助区域内的 TEST_METHOD 环境变量向相应的运行时 API 发出调用。如果测试成功，则 DynamoDB 表中的 lexRegion 列将被更新为辅助区域；如果测试仍然失败，则更新为 err，代表两个区域皆已发生服务中断。
相关文章