22

temporal.io 与 cadenceworkflow.io 有什么关系？如果根据 cadence 工作流服务启动一个新项目，应该使用什么？

4

4 回答 4

64

免责声明：我是 Cadence 项目的原始联合创始人和技术负责人，目前是 Temporal Technologies 的联合创始人/首席执行官。

temporal.io是 Cadence 项目的分支，由 Cadence 项目Maxim Fateev和Samar Abbas的原始创始人和技术负责人组成。该分支在与 Cadence 相同的 MIT（一些 SDK 在 Apache 2.0 下）许可下是完全开源的。我们创办了 Temporal Technologies 并获得了 VC 资金，因为我们相信我们通过AWS Simple Workflow、Durable Task Framework和 Cadence 项目开创的编程模型具有远远超出单个公司的潜力。拥有一个商业实体来推动项目的发展对于项目的寿命至关重要。

temporal.io 分支具有 Cadence 的所有功能，因为它不断地从中融合。它还实现了多个新功能。

以下是 Cadence 和 Temporal 在 Temporal 分叉初始发布时的一些技术差异（预计在 05/2020 达到生产状态）

所有 thrift 结构都被 protobuf 取代

Cadence 的所有公共 API 都依赖于 Thrift。Thrift 对象也以序列化的形式存储在 DB 中。

Temporal 将所有这些结构转换为Protocol Buffers。这包括存储在数据库中的对象。

通信协议从 TChannel 切换到 gRPC

Cadence 依赖于TChannel，这是 Uber 开发的基于 TCP 的多路复用协议。TChannel 有很多限制，例如不支持任何安全性以及语言绑定数量非常有限。即使在优步，它也基本上被弃用了。

Temporal 使用gRPC进行所有进程间通信。

TLS 支持

Cadence 不支持任何通信安全，因为它是 TChannel 的限制。

Temporal 支持双向 TLS，未来将支持更高级的身份验证和授权功能。

简化配置

Temporal 重新设计了服务配置。其中一些最令人困惑的部分已被删除。例如，无需配置成员种子。在时间上，每个主机在启动时都会向数据库注册自己，并使用数据库中的列表作为种子列表。

发布管道

Cadence 不测试任何公开发布的工件，包括 docker 镜像，因为其内部发布管道仅确保内部构建工件的质量。它也不会对 Uber 内部未使用的依赖项执行任何发布测试。例如，除了不完整的单元测试之外，不会对 MySQL 集成进行测试。这同样适用于 CLI 和其他组件。

Temporal 正在对发布过程进行大量投资。包括完整支持的依赖矩阵在内的所有工件都将通过完整的发布管道进行处理，该管道将包括多天的压力运行。

发布过程的另一个重要部分是为生产问题生成补丁的能力。确保此类补丁的质量并及时生成所有必要工件的能力对于在生产中运行 Temporal 的任何人都很重要。

有效载荷元数据

Cadence 将活动输入和输出以及其他有效负载存储为二进制 blob，而没有任何关联的元数据。

时间允许将元数据与每个有效负载相关联。它支持动态可插入序列化机制、无缝压缩和加密等功能。

故障传播

在 Cadence 中，活动和工作流故障被建模为单个二进制有效负载和字符串原因字段。只有 Java 客户端支持跨工作流和活动边界链接异常。但是这种链接依赖于脆弱的 GSON 序列化，并且不适用于其他语言。

临时活动和工作流故障被建模为 protobuf，并且可以在不同 SDK 中实现的组件之间链接。例如，单个故障跟踪可以包含由异常引起的链，该异常源自用 Python 编写的活动，通过 Go 子工作流传播到 Java 工作流，然后传播到客户端。

去 SDK

Temporal 对 Cadence Go 客户端进行了以下改进：

  • Protobuf 和 gRPC
  • 没有活动和工作流类型的全局注册
  • 能够向工作人员注册活动结构实例。它极大地简化了将外部依赖项传递给活动的过程。
  • 允许通过外部配置文件配置超时等功能的工作流和活动拦截器。
  • 活动和工作流类型名称不包括包名称。这使得在不破坏更改的情况下进行代码重构变得更加简单。
  • Cadence 要求的大多数超时现在都是可选的。
  • 工作流.Await 方法

Java SDK

Temporal 对 Cadence Java 客户端进行了以下改进：

  • 工作流和活动注释允许活动和工作流实现对象实现非工作流和活动接口。这对于使用像 Spring 这样的 AOP 框架很重要。
  • 多态工作流和活动接口。这允许在多个活动和工作流类型之间拥有一个通用接口。
  • 信号和查询处理程序的动态注册。
  • 允许通过外部配置文件配置超时等功能的工作流和活动拦截器。
  • 改进了活动和工作流类型名称生成

PHP SDK Cadence 不支持 PHP。Temporal 最近发布了PHP SDK。

Typescript SDK Temporal 发布了Typescript SDK的 alpha 版本。

我们计划了许多其他语言的其他功能和客户端 SDK。您可以在Temporal Community Forum找到我们。

于 2020-04-17T22:00:49.590 回答
10

我来自 Uber 的 Cadence 团队，我想让你知道 Cadence 将继续由我们的团队积极开发。以下是我们最近与 Cadence 社区分享的更新的一部分：

我们想强调 Uber 的 Cadence 团队致力于 Cadence 项目的增长和开源开发。如今，Cadence 为 Uber 内部 100 多个不同的用例提供支持，而且这个数字还在迅速增长。总体而言，任何时候平均有 5000 万次以上的执行，我们的客户每月完成 3B+ 次执行。在 Uber 之外，我们还知道不同公司的许多工程团队已经将 Cadence 用于他们的关键业务工作流程。我们很高兴能够以向后兼容的方式继续将 Cadence 发展为一个开源项目，并在短期内更加关注可靠性、可扩展性和可维护性。

现在比较 Cadence 和 Temporal 可能还为时过早。尽管如此，关于我们如何系统地阐明 Cadence 的路线图，以确保所有必要的信息都在那里，以便进行此类比较，我有一些想法。当我们创建一个包含路线图信息的页面时，我将使用链接更新这篇文章。

同时，如果您需要有关 Cadence 的更多信息，请告诉我，这在这方面会有所帮助。

于 2020-04-14T00:39:41.033 回答
7

概述

事实上，两者都在积极开发中。如果查看他们的路线图，您会发现他们有一些不同的重点。这两个项目有着相同的愿景，让每个人都重新思考长期业务的编程模型。

Cadence 作为一个开源项目更加成熟。该开发涉及来自世界各地的许多贡献者。

跨域+集群的任务

如果您有多个 Cadence 集群，这允许跨不同集群和域启动 childWF。

支持 Thrift 和 gRPC

gRPC 支持完全在服务器端完成。内部流量全部使用 gRPC，我们正在努力让用户从 Thrift 迁移到 gRPC。

授权

权限基于域，但可以扩展。与 Temporal 不同，权限策略可以存储在 Cadence 域数据存储中，这样您就不必构建另一个服务/存储来管理它们。请注意，整个提案是由社区成员开发的。

工作流阴影器

Workflow Shadower构建在 Workflow Replayer 之上以解决此问题。阴影的基本思想是：根据您定义的过滤器扫描工作流，从 Cadence 服务器的扫描结果中获取每个工作流的历史记录并运行重放测试。它既可以作为测试运行以服务于本地开发目的，也可以作为工作流中的工作流来持续重播生产工作流。

优雅的域故障转移

这允许 XDC（多集群）模式减少在故障转移期间重新运行某些任务的痛苦。

NoSQL 插件模型

这允许以最小的方式实现不同的 NoSQL 持久性。在写这篇文章的时候，Temporal 还没有开始研究它。

MongoDB 支持

在 NoSQL 接口之上，MongoDB 支持是WIP。

使用多个 SQL 实例作为分片 SQL

这允许用户拥有一个规模更大的 Cadence 集群。（然后使用 XDC 添加更多数据库实例）

动态配置的配置存储

这使我们能够在不进行任何部署的情况下更改动态配置（例如速率限制）。只需一个 CLI 命令就可以控制系统的行为。

它处于实验阶段，仍处于WIP生产准备阶段。

工作流程通知

允许从 Cadence 获取通知的 WIP 生态系统项目。这就是 Cadence 使用 Kafka 传递可见性消息的好处。Temporal 不使用 Kafka，这将很难支持此功能。

Periodical Healthchecker( Canary ) and Benchmark tool and benchmark setup docs

更多文档

Temporal 缺少的其他小改进

于 2020-09-19T00:46:36.910 回答
2

Temporal.io 是一家分叉 cadence 项目的公司，现在正在其上构建——将其命名为 temporal。它是由 cadence 的作者创立的。

我建议使用 temporal.io，因为它正在积极开发中

于 2020-04-11T19:31:10.407 回答