本文最初发布于 Mikhail Shilkov 的个人博客,经原作者授权由 InfoQ 中文站翻译并分享。
Temporal让开发人员可以构建高度可靠的应用程序,而无需担心所有的边界情况。如果你刚开始接触 Temporal,那么可以读一下我的文章《开源工作流即代码》。接下来,我将介绍如何安装和运行 Temporal。
Temporal 包含多个组件。在本文中,我想概要地介绍下其主要的构建模块及它们之间的交互。最终,你将对 Temporal 以及部署到开发环境、过渡环境和生产环境的注意事项有一个总体了解。
Workers 是运行 Temporal 应用程序代码的计算节点。你将工作流程和活动编译为可执行的 workers。接下来,你可以在后台运行 worker 的可执行文件,它将侦听需要处理的新任务。
你的第一个开发环境可能只需要一个 wokrer,在单个进程中同时运行工作流和活动。worker 可以托管在你希望的任何地方:可以作为笔记本电脑上的本地进程,也可以作为 AWS Fargate 任务,可以是 Kubernetes 中的 pod,等等。
Temporal worker 执行工作流和活动
生产部署通常运行大量负载较大的工作流,因此,你可能需要并行运行多个工作者。确保节点分布在一个计算集群上,从而实现弹性和可伸缩性。
工作负载扩展到多个 Temporal workers
Workers 独立操作,每一个负责处理各自的负载。从逻辑上讲,Workers 是“无状态的”:它们不关心过去和未来。Workers 之间不直接通信,但它们通过一个 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 命令行接口tctl
,也可以在使用 SDK 或原始 gRPC 编写的任何自定义代码中通过调用发起一个工作流。
每个客户端都必须连接到一个 Temporal 服务,以启动或终止工作流、等待完成、列出历史记录里的结果,等等。例如,Web 应用程序可以在每次处理特定 HTTP 端点时启动工作流执行。
下图将上面提到的所有部分组合在一起。
Temporal 高层架构
如你所见,要使 Temporal 工作起来需要相当多的组件。Temporal 设计用于可靠地处理数以百万计的工作流,并提供高性能保证,同时,它还是开源的,可以在不同的基础设施选项之间移植。这就要求使用多层方法。
你可以根据入门指南将所有内容部署到开发机器上。然后,你可以将组件移到你喜欢的云环境中。
原文链接:
https://mikhail.io/2020/10/practical-approach-to-temporal-architecture/
领取专属 10元无门槛券
私享最新 技术干货