Temporal 框架研究：一种实用的 Temporal 架构方法

本文最初发布于 Mikhail Shilkov 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享。

Temporal让开发人员可以构建高度可靠的应用程序，而无需担心所有的边界情况。如果你刚开始接触 Temporal，那么可以读一下我的文章《开源工作流即代码》。接下来，我将介绍如何安装和运行 Temporal。

Temporal 包含多个组件。在本文中，我想概要地介绍下其主要的构建模块及它们之间的交互。最终，你将对 Temporal 以及部署到开发环境、过渡环境和生产环境的注意事项有一个总体了解。

Workers

Workers 是运行 Temporal 应用程序代码的计算节点。你将工作流程和活动编译为可执行的 workers。接下来，你可以在后台运行 worker 的可执行文件，它将侦听需要处理的新任务。

你的第一个开发环境可能只需要一个 wokrer，在单个进程中同时运行工作流和活动。worker 可以托管在你希望的任何地方：可以作为笔记本电脑上的本地进程，也可以作为 AWS Fargate 任务，可以是 Kubernetes 中的 pod，等等。

 

Temporal worker 执行工作流和活动

生产部署通常运行大量负载较大的工作流，因此，你可能需要并行运行多个工作者。确保节点分布在一个计算集群上，从而实现弹性和可伸缩性。

工作负载扩展到多个 Temporal workers

Workers 独立操作，每一个负责处理各自的负载。从逻辑上讲，Workers 是“无状态的”：它们不关心过去和未来。Workers 之间不直接通信，但它们通过一个 Temporal 中央服务——系统的大脑——进行协调。

Temporal 服务

Temporal 服务是 Temporal 提供的一个组件。它的目的是跟踪工作流、活动和任务，并协调工作者的执行。

你的早期环境可能只有一个在后台运行的服务实例。worker 知道服务的域名（IP）和端口，并通过 gRPC 连接到服务。

 

Worker 与 Temporal 服务交互

Temporal 服务本身由多个组件组成：前端、匹配、历史记录等。不过现在，我们可以将其视为黑盒“服务”。

一旦工作负载开始增加，就需要将服务组件扩展到多个实例，以获得高弹性和高吞吐量。因此，现在有多个 workers 在与多个服务实例对话。

运行多个组件的 Temporal 集群

Temporal 服务可以容忍节点故障，因为它将其状态存储在外部存储器中。

数据存储

所有工作流数据——任务队列、执行状态、活动日志——都存储在一个持久化数据存储中。持久性技术是可插拔的，目前官方支持两个选项：Cassandra 和 MySQL。更多的可选方案，包括 PostgreSQL，正在开发之中。

MySQL 数据库补全了最简单的 Temporal 部署图。

MySQL 作为 Temporal 的数据存储

对于会遇到高负载的高度分布式应用程序，使用 Cassandra 可能更好。这个数据库可以是你自己管理的集群，也可以是托管的云服务（比如 Azure Cosmos DB）：

 

Cassandra 作为 Temporal 的数据存储

你的代码永远不会直接与数据存储交互。基本上，它是 Temporal 服务的一个（相当重要的）实现细节。

Temporal Web 控制台

Temporal 提供了一个方便的 Web 控制台来查看命名空间、工作流和活动历史。从技术上讲，它不是必备组件——但是你可能希望使用它手动检查和排除故障。

你可能有其他客户端组件，举例来说，来启动工作流执行。

外部客户端

你需要一个客户端来启动你的第一个工作流执行。它可以是 Temporal 命令行接口tctl，也可以在使用 SDK 或原始 gRPC 编写的任何自定义代码中通过调用发起一个工作流。

每个客户端都必须连接到一个 Temporal 服务，以启动或终止工作流、等待完成、列出历史记录里的结果，等等。例如，Web 应用程序可以在每次处理特定 HTTP 端点时启动工作流执行。

合而为一

下图将上面提到的所有部分组合在一起。

Temporal 高层架构

如你所见，要使 Temporal 工作起来需要相当多的组件。Temporal 设计用于可靠地处理数以百万计的工作流，并提供高性能保证，同时，它还是开源的，可以在不同的基础设施选项之间移植。这就要求使用多层方法。

你可以根据入门指南将所有内容部署到开发机器上。然后，你可以将组件移到你喜欢的云环境中。

原文链接：

https://mikhail.io/2020/10/practical-approach-to-temporal-architecture/