对讲机平台最基本的要素之一是它如何处理用户数据——对于我们和我们的客户来说，访问、跟踪和过滤用户数据的能力使对讲机成为一个强大的解决方案。一些重要的功能取决于根据特定的标准匹配用户数据，例如，这允许我们向特定用户发送自动消息。这意味着更新用户状态的过程非常重要，单个用户每天可以更新数千次。我们主要使用DynamoDB来存储最新的用户状态。然而，我们意识到，我们的客户支持团队需要更深入地了解用户在特定时间点的历史状态，特别是当他们需要排除问题或验证特定用户以前为什么匹配某些消息标准时。"我们希望让我们的客户支持团队在挖掘历史用户状态时能够自助服务"考虑到大量的用户数据，这并不容易做到。它要求我们的工程师挖掘日志，及时地将用户对象在任何给定时刻发生的所有相关信息组合起来。Grepping日志是不可伸缩的，需要大量的手动工作，这很容易出错。我们认为可能有一种更好的方法，通过更有效地显示用户状态中的历史变化，来自动化这里涉及的大量调查工作。我们希望让我们的客户支持团队在挖掘历史用户状态时能够自助服务。利用现有技术在探索如何更好地帮助我们的客户支持团队时，我们有两个主要要求：允许可靠、快速地访问历史用户状态更改以易于理解的方式显示此信息自助服务工具需要针对写操作进行优化。用户经常更新，但很少需要对其进行故障排除。历史用户状态每天最多需要检索几次，但通常在几天内根本没有活动。为了支持这一点，我们希望能够获得用户的实时更新。在DynamoDB流事件中捕获用户的每个更新。这是一个自然的解决方案，我们可以利用它来开发我们的内部工具，称为用户历史工具，简称UHT。构建用户历史工具当我们接收到表活动的DynamoDB Stream事件时，我们会存储用户的更新。我们需要保存这些实时更新，而不必存储用户对象的所有中间状态，因为对用户状态的更新太多，数据库表会增长得太快。为响应每个事件，将触发lambda函数，我们在其中进行处理。此操作有两个主要职责：计算流中旧用户状态和新用户状态之间的差异将计算出的差异存储在专用的用户历史记录DynamoDB表中因为DynamoDB流中的记录是JSON格式的，所以我们得到两个JSON对象的diff。生成的diff是JSON补丁格式的。补丁看起来像：[{"op"："replace"，"path"："/baz"，"value"："boo"}，{"op"："add"，"path"："/hello"，"value"：world"]}{"op"："delete"，"path"："/foo"}]与计算出的diff一起，我们存储了user_id和序列生存时间（TTL）值。在记录上设置TTL可以减少存储的数据量。为了安全起见，它还允许我们清理超过30天的记录。TTL功能由DynamoDB提供，无需额外费用。在管理员方面，一旦管理员请求用户历史记录，就会发生以下几件事：从主用户存储器读取当前用户状态。存储的用户差异从用户历史表中加载，一次按30个状态分页。从当前用户状态开始，通过对每个先前状态应用JSON diff补丁来生成先前用户状态的列表。通过比较两个相邻的状态，我们生成用户更改的HTML表示。生成的HTML看起来很像Github PR的更改，旧值用红色突出显示，而新值用绿色突出显示，因此更改立即明显。端到端体系结构如下：

处理和存储diff补丁的流程是无服务器的。awslmdba负责以高可用性运行和扩展代码所需的一切。自动化重复任务DynamoDB流是用来捕获表活动的，它们集成的AWS Lambda触发器使我们能够轻松地可视化对象中的更新。"简单思考和利用通用技术是我们工程哲学的一部分"UHT现在由我们的客户支持团队内部使用，减少了调查与历史用户状态相关的问题的时间。自动化这种手动重复性任务可以让我们在解决客户问题时更高效，并消除在过程中出错的风险。简单思考和利用我们知道并经常使用的通用技术是我们免运行软件理念的一部分。我们通过选择合适的、可靠的技术来实现这一目标，使我们能够构建一个简单、优雅、无服务器的解决方案，很好地满足了我们的需求。