在评估 Temporal Cloud 等托管服务时，延迟会影响决策。许多开发者认为，从自托管 Temporal 集群迁移到 Temporal Cloud 时，应用程序的延迟会增加。但我们观察到的情况恰恰相反：Temporal Cloud 提供的性能优于大多数自托管集群，延迟更低。
这些性能改进源于我们的团队对 Temporal Cloud 的有效管理和扩展，以及 Temporal Cloud 的自定义持久化层。这种架构有助于我们的托管服务处理高吞吐量，同时提供更低、更稳定的请求延迟。
本文概述了 Temporal Cloud 的自定义持久化层。
构建自定义持久化层的原因#
Temporal Cloud 是多租户的：多个命名空间共享相同的计算和持久化层。客户为实际使用量付费，而不是整个硬件集合，这是一种经济高效的解决方案。多租户确保在流量高峰期间为所有客户提供额外的容量。多租户也意味着处理“吵闹邻居”问题，即高流量租户消耗过多的资源，导致其他租户的性能变慢。
在数据库中解决“吵闹邻居”问题尤其困难。因为数据库是有状态的，并且扩展需要更长的时间，因此无法快速添加容量来处理负载峰值。Temporal 使用重写工作负载；执行状态的更改会不断写入持久化层。这使得工作流即使在发生故障时也能持久执行。Temporal Cloud 的数据库必须能够可靠地支持多个客户并发且公平地进行高吞吐量和低延迟。
为了应对这些挑战，我们的团队在 Temporal Cloud 现有的架构之上构建了一个自定义持久化解决方案。我们的设计包含三大支柱
- 更好的分片
- 预写日志 (Write-Ahead Log)
- 工作流事件历史的分层存储
Temporal Cloud 中的更好的分片#
我们为提高 Temporal Cloud 的可扩展性所做的第一件事是将持久化状态分片并将其存储在多个数据库中。我们可以根据不同命名空间的需求动态添加数据库并独立调整其大小。这种架构有助于 Temporal Cloud 每天处理高规模，并为 Black Friday 等高流量事件扩展命名空间。
Temporal Cloud 中的预写日志#
Temporal 的重写特性意味着每个事件都必须写入数据库。高写入速率会导致高延迟并需要更大的数据库来支持。我们通过构建预写日志 (WAL) 来解决这个问题。
我们的预写日志将写入存储在仅追加日志中。这允许服务器在将单个聚合更新写入数据库之前，在 WAL 中积累多个更新。如果更新在写入数据库之前发生故障，则可以从日志中读取和恢复更新。
实施预写日志后，我们立即看到了 Temporal Cloud 的影响。这项增强功能显著降低了延迟和 Temporal Cloud 中数据库的大小。
工作流事件历史的分层存储#
Temporal 持久化层存储每个工作流中每个事件的持续写入以及工作流事件历史。事件历史对于 Temporal 中的恢复和重放过程至关重要。它还允许开发者调试过去的执行或导出数据以进行合规性和进一步分析。事件历史会消耗数据库中的存储空间，并可能降低性能。
为了解决这个问题，我们构建了一个系统，在相应的 Workflow 执行完成后，将 Workflow 事件历史移动到对象存储。客户仍然可以像往常一样访问事件历史，而在后端，我们减少了对数据库的需求，提高了效率并降低了启动和运行 Workflow 的延迟。
结果：更高的可扩展性和更低的延迟#
我们帮助许多客户从自托管 Temporal 集群迁移到 Temporal Cloud。我们经常观察到由于自定义持久化层而导致的延迟降低。当您以大规模运行时，我们始终建议评估 Temporal Cloud，以获得最佳性能。从小型到大型，Temporal Cloud 都能为您节省时间和资源，并为您提供更可靠的服务。
有关更多详细信息，请观看我们的网络研讨会录像：Temporal Cloud 的自定义持久化层。您可以了解更多关于 Temporal Cloud 的延迟服务级别目标 (SLO)。
此外，请查看去年 Replay 大会上的演讲：云与 Temporal 有什么关系？Temporal Cloud 的新型持久化层。
本文是关于 Temporal Cloud 的系列文章的一部分。请查看下面的其他文章