当你在尝试构建可靠应用程序具备以下功能的时候：
不妨学习一下这个框架：Temporal
runtime
platform
它让开发人员可以构建高度可靠的应用程序，而无需担心所有的边界情况。
Workers 是运行 Temporal 应用程序代码的计算节点。你将工作流程和活动编译为可执行的 workers。接下来，你可以在后台运行 worker 的可执行文件，它将侦听需要处理的新任务。
你的第一个开发环境可能只需要一个 wokrer，在单个进程中同时运行工作流和活动。worker 可以托管在你希望的任何地方：可以作为笔记本电脑上的本地进程，也可以作为 AWS Fargate 任务，可以是 Kubernetes 中的 pod，等等。
emporal 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 设计用于可靠地处理数以百万计的工作流，并提供高性能保证，同时，它还是开源的，可以在不同的基础设施选项之间移植。这就要求使用多层方法。、、、
你可以根据入门指南将所有内容部署到开发机器上。然后，你可以将组件移到你喜欢的云环境中。
| 留言与评论（共有 0 条评论） “” |
