时间工作流与 Cadence 工作流
Temporal workflow vs Cadence workflow
temporal.io 与 cadenceworkflow.io 有什么关系？如果依赖cadence工作流服务启动一个新项目应该使用什么？
Temporal.io 是一家分叉了 Cadence 项目的公司，现在正在其之上构建 - 将其命名为时间。
由cadence的作者创立。
我建议使用 temporal.io，因为它正在积极开发中
我来自 Uber 的 Cadence 团队，我想让你知道我们的团队继续积极开发 Cadence。以下是我们最近与 Cadence 社区分享的更新的一部分：
We want to reinforce that Uber's Cadence team is committed to the
growth and open source development of the Cadence project. Today,
Cadence powers 100+ different use cases within Uber and that number
grows quickly. Collectively, there are 50M+ ongoing executions at any
moment on average and our customers finish 3B+ executions per month.
Outside of Uber, we also know that many engineering teams at various
companies have already adopted Cadence for their business-critical
workflows. We are excited to continue evolving Cadence as an
open-source project in a backward-compatible way with an increased
focus on reliability, scalability, and maintainability in the near
term.
现在比较 Cadence 和 Temporal 可能还为时过早。尽管如此，关于我们如何系统地阐明 Cadence 的路线图以确保提供所有必要的信息以实现此类比较，我仍然有一些想法。当我们创建包含有关路线图信息的页面时，我将使用链接更新此 post。
与此同时，如果您需要有关 Cadence 的更多信息以帮助解决此问题，请告诉我。
免责声明：我是 Cadence 项目的最初联合创始人和技术负责人，目前 co-founder/CEO 是 Temporal Technologies。
temporal.io is the fork of the Cadence project by the original founders and tech leads of the Cadence project Maxim Fateev and Samar Abbas. The fork is fully open source under the same MIT (with some SDKs under Apache 2.0) license as Cadence. We started Temporal Technologies and received VC funding as we believe that the programming model that we pioneered through AWS Simple Workflow, Durable Task Framework 并且 Cadence 项目的潜力远远超过一家公司。拥有一个商业实体来推动项目向前发展对于项目的长寿至关重要。
temporal.io 分支具有 Cadence 的所有功能，因为它不断地从中合并。它还实现了多项新功能。
以下是 Cadence 和 Temporal 在 Temporal 分支最初发布时的一些技术差异。
所有 thrift 结构都被 protobuf 结构替换
Cadence的所有public API都依赖于Thrift。 Thrift 对象也以序列化形式存储在数据库中。
Temporal 将所有这些结构转换为 Protocol Buffers。这包括存储在数据库中的对象。
通信协议从TChannel切换到gRPC
Cadence 依赖于 TChannel，它是 Uber 开发的基于 TCP 的多路复用协议。 TChannel 有很多限制，例如不支持任何安全性以及语言绑定的数量非常有限。即使在优步，它基本上也已被弃用。
Temporal 使用 gRPC 进行所有进程间通信。
TLS 支持
Cadence 不支持任何通信安全，因为它是 TChannel 的限制。
Temporal 支持双向 TLS，未来将支持更高级的身份验证和授权功能。
简化配置
Temporal 重新设计了服务配置。其中一些最令人困惑的部分已被删除。例如，无需配置成员资格种子。每个主机在启动时都会暂时向数据库注册，并使用数据库中的列表作为种子列表。
发布管道
Cadence 不测试任何 public 刚刚发布的工件，包括 docker 图像，因为其内部发布管道仅确保内部构建工件的质量。它也不会对 Uber 中未使用的依赖项执行任何发布测试。例如，MySQL 集成没有经过相当不完整的单元测试之外的测试。这同样适用于 CLI 和其他组件。
Temporal 正在对发布过程进行大量投资。所有工件，包括完整支持的依赖矩阵，都将通过完整的发布管道进行处理，该管道将包括多天的压力运行。
发布过程的另一个重要部分是能够为生产问题生成补丁。确保此类补丁的质量并及时生成所有必要工件的能力对任何人都很重要 运行 生产中的时间。
负载元数据
Cadence 将 activity 输入和输出以及其他有效载荷存储为没有任何关联元数据的二进制 blob。
Temporal 允许将元数据与每个负载相关联。它支持动态可插入序列化机制、无缝压缩和加密等功能。
故障传播
在 Cadence activity 中，工作流故障被建模为单个二进制有效负载和一个字符串原因字段。只有 Java 客户端支持跨工作流和 activity 边界链接异常。但是这种链接依赖于脆弱的 GSON 序列化并且不适用于其他语言。
临时 activity 和工作流失败 are modeled as protobufs 并且可以链接到不同 SDK 中实现的组件。例如，单个故障跟踪可以包含由 activity 中编写的 Python 中的异常引起的链，通过 Go 子工作流传播到 Java 工作流，然后传播到客户。
Go SDK
Temporal 对 Cadence Go 客户端进行了以下改进：
- Protobuf 和 gRPC
- activity 和工作流类型
没有全局注册
- 能够向 worker 注册 activity 结构实例。它大大简化了将外部依赖项传递给活动的过程。
- 工作流和 activity 拦截器，允许通过外部配置文件实现配置超时等功能。
- Activity 和工作流类型名称不包括包名称。这使得在不破坏更改的情况下进行代码重构变得更加简单。
- Cadence 要求的大部分超时现在都是可选的。
- workflow.Await方法
Java SDK
Temporal 对 Cadence Java 客户端进行了以下改进：
- 工作流和activity注释允许activity和工作流实现对象实现非工作流和activity接口。这对于像 Spring.
这样的 AOP 框架很好地发挥作用很重要
- 多态工作流和 activity 界面。这允许在多个 activity 和工作流类型之间有一个通用接口。
- 信号和查询处理程序的动态注册。
- 工作流和 activity 拦截器，允许通过外部配置文件实现配置超时等功能。
- Activity 和工作流类型名称生成得到改进
Cadence 不支持的 SDK
SDK 正在积极开发中
我们为其他语言计划了很多其他功能和客户端 SDK。您可以在 Temporal Community Forum.
找到我们
概览
事实是两者都在积极开发中。如果查看他们的路线图，您会发现他们有一些不同的重点。两个项目有着相同的愿景，让大家重新思考long-running业务的编程模型。
Cadence 作为一个 open-source 项目更加成熟。开发涉及来自世界各地的许多贡献者。
跨域+集群任务
如果您有多个 Cadence 集群，
这允许跨不同集群和域启动 childWF。
支持Thrift&gRPC
gRPC support is completely done on the server side. Internal traffic is all using gRPC 我们正在努力让用户从 Thrift 迁移到 gRPC。
授权
权限基于域，但可以扩展。与 Temporal 不同的是，权限策略可以存储在 Cadence 域数据存储中，因此您无需构建另一个 service/storage 来管理它们。
请注意，the whole proposal 是由社区成员开发的。
工作流影子
Workflow Shadower 构建在 Workflow Replayer 之上以解决此问题。阴影的基本思想是：根据您定义的过滤器扫描工作流，从 Cadence 服务器的扫描结果中获取每个工作流的历史记录和 运行 回放测试。它可以 运行 既可以作为服务于本地开发目的的测试，也可以作为您工作人员中的工作流来不断重放生产工作流。
Graceful domain failover
这允许 XDC（多集群）模式减少故障转移期间重新运行 一些任务的痛苦。
NoSQL plugin model
这允许以最少的方式实现不同的 NoSQL 持久性。在撰写本文时 post，Temporal 尚未开始处理它。
MongoDB支持
在 NoSQL 接口之上，MongoDB 支持 WIP。
Using multiple SQL instances as sharded SQL
这允许用户拥有一个规模更大的Cadence集群。 （然后使用 XDC 添加更多数据库实例）
动态配置的配置存储
这使我们能够在不进行任何部署的情况下更改动态配置（如速率限制）。只需一个 CLI 命令就可以控制系统的行为。
它处于试验阶段，仍 WIP 可用于生产。
Workflow notification
允许从 Cadence 获取通知的 WIP 生态系统项目。这就是 Cadence 使用 Kafka 传递可见性消息的好处。 Temporal 不使用 Kafka，这将很难支持此功能。
定期健康检查器(Canary) and Benchmark tool and benchmark setup docs
更多文档
Temporal 缺少的其他小改进
- TerminateIfRunning IDReusePolicy
- 所有域API转发策略
- Better & cleaner XDC configuration
- Tooling to deserialize database blob data
...
...
temporal.io 与 cadenceworkflow.io 有什么关系？如果依赖cadence工作流服务启动一个新项目应该使用什么？
Temporal.io 是一家分叉了 Cadence 项目的公司，现在正在其之上构建 - 将其命名为时间。 由cadence的作者创立。
我建议使用 temporal.io，因为它正在积极开发中
我来自 Uber 的 Cadence 团队，我想让你知道我们的团队继续积极开发 Cadence。以下是我们最近与 Cadence 社区分享的更新的一部分：
We want to reinforce that Uber's Cadence team is committed to the growth and open source development of the Cadence project. Today, Cadence powers 100+ different use cases within Uber and that number grows quickly. Collectively, there are 50M+ ongoing executions at any moment on average and our customers finish 3B+ executions per month. Outside of Uber, we also know that many engineering teams at various companies have already adopted Cadence for their business-critical workflows. We are excited to continue evolving Cadence as an open-source project in a backward-compatible way with an increased focus on reliability, scalability, and maintainability in the near term.
现在比较 Cadence 和 Temporal 可能还为时过早。尽管如此，关于我们如何系统地阐明 Cadence 的路线图以确保提供所有必要的信息以实现此类比较，我仍然有一些想法。当我们创建包含有关路线图信息的页面时，我将使用链接更新此 post。
与此同时，如果您需要有关 Cadence 的更多信息以帮助解决此问题，请告诉我。
免责声明：我是 Cadence 项目的最初联合创始人和技术负责人，目前 co-founder/CEO 是 Temporal Technologies。
temporal.io is the fork of the Cadence project by the original founders and tech leads of the Cadence project Maxim Fateev and Samar Abbas. The fork is fully open source under the same MIT (with some SDKs under Apache 2.0) license as Cadence. We started Temporal Technologies and received VC funding as we believe that the programming model that we pioneered through AWS Simple Workflow, Durable Task Framework 并且 Cadence 项目的潜力远远超过一家公司。拥有一个商业实体来推动项目向前发展对于项目的长寿至关重要。
temporal.io 分支具有 Cadence 的所有功能，因为它不断地从中合并。它还实现了多项新功能。
以下是 Cadence 和 Temporal 在 Temporal 分支最初发布时的一些技术差异。
所有 thrift 结构都被 protobuf 结构替换
Cadence的所有public API都依赖于Thrift。 Thrift 对象也以序列化形式存储在数据库中。
Temporal 将所有这些结构转换为 Protocol Buffers。这包括存储在数据库中的对象。
通信协议从TChannel切换到gRPC
Cadence 依赖于 TChannel，它是 Uber 开发的基于 TCP 的多路复用协议。 TChannel 有很多限制，例如不支持任何安全性以及语言绑定的数量非常有限。即使在优步，它基本上也已被弃用。
Temporal 使用 gRPC 进行所有进程间通信。
TLS 支持
Cadence 不支持任何通信安全，因为它是 TChannel 的限制。
Temporal 支持双向 TLS，未来将支持更高级的身份验证和授权功能。
简化配置
Temporal 重新设计了服务配置。其中一些最令人困惑的部分已被删除。例如，无需配置成员资格种子。每个主机在启动时都会暂时向数据库注册，并使用数据库中的列表作为种子列表。
发布管道
Cadence 不测试任何 public 刚刚发布的工件，包括 docker 图像，因为其内部发布管道仅确保内部构建工件的质量。它也不会对 Uber 中未使用的依赖项执行任何发布测试。例如，MySQL 集成没有经过相当不完整的单元测试之外的测试。这同样适用于 CLI 和其他组件。
Temporal 正在对发布过程进行大量投资。所有工件，包括完整支持的依赖矩阵，都将通过完整的发布管道进行处理，该管道将包括多天的压力运行。
发布过程的另一个重要部分是能够为生产问题生成补丁。确保此类补丁的质量并及时生成所有必要工件的能力对任何人都很重要 运行 生产中的时间。
负载元数据
Cadence 将 activity 输入和输出以及其他有效载荷存储为没有任何关联元数据的二进制 blob。
Temporal 允许将元数据与每个负载相关联。它支持动态可插入序列化机制、无缝压缩和加密等功能。
故障传播
在 Cadence activity 中，工作流故障被建模为单个二进制有效负载和一个字符串原因字段。只有 Java 客户端支持跨工作流和 activity 边界链接异常。但是这种链接依赖于脆弱的 GSON 序列化并且不适用于其他语言。
临时 activity 和工作流失败 are modeled as protobufs 并且可以链接到不同 SDK 中实现的组件。例如，单个故障跟踪可以包含由 activity 中编写的 Python 中的异常引起的链，通过 Go 子工作流传播到 Java 工作流，然后传播到客户。
Go SDK
Temporal 对 Cadence Go 客户端进行了以下改进：
- Protobuf 和 gRPC
- activity 和工作流类型 没有全局注册
- 能够向 worker 注册 activity 结构实例。它大大简化了将外部依赖项传递给活动的过程。
- 工作流和 activity 拦截器，允许通过外部配置文件实现配置超时等功能。
- Activity 和工作流类型名称不包括包名称。这使得在不破坏更改的情况下进行代码重构变得更加简单。
- Cadence 要求的大部分超时现在都是可选的。
- workflow.Await方法
Java SDK
Temporal 对 Cadence Java 客户端进行了以下改进：
- 工作流和activity注释允许activity和工作流实现对象实现非工作流和activity接口。这对于像 Spring. 这样的 AOP 框架很好地发挥作用很重要
- 多态工作流和 activity 界面。这允许在多个 activity 和工作流类型之间有一个通用接口。
- 信号和查询处理程序的动态注册。
- 工作流和 activity 拦截器，允许通过外部配置文件实现配置超时等功能。
- Activity 和工作流类型名称生成得到改进
Cadence 不支持的 SDK
SDK 正在积极开发中
我们为其他语言计划了很多其他功能和客户端 SDK。您可以在 Temporal Community Forum.
找到我们概览
事实是两者都在积极开发中。如果查看他们的路线图，您会发现他们有一些不同的重点。两个项目有着相同的愿景，让大家重新思考long-running业务的编程模型。
Cadence 作为一个 open-source 项目更加成熟。开发涉及来自世界各地的许多贡献者。
跨域+集群任务
如果您有多个 Cadence 集群， 这允许跨不同集群和域启动 childWF。
支持Thrift&gRPC
gRPC support is completely done on the server side. Internal traffic is all using gRPC 我们正在努力让用户从 Thrift 迁移到 gRPC。
授权
权限基于域，但可以扩展。与 Temporal 不同的是，权限策略可以存储在 Cadence 域数据存储中，因此您无需构建另一个 service/storage 来管理它们。 请注意，the whole proposal 是由社区成员开发的。
工作流影子
Workflow Shadower 构建在 Workflow Replayer 之上以解决此问题。阴影的基本思想是：根据您定义的过滤器扫描工作流，从 Cadence 服务器的扫描结果中获取每个工作流的历史记录和 运行 回放测试。它可以 运行 既可以作为服务于本地开发目的的测试，也可以作为您工作人员中的工作流来不断重放生产工作流。
Graceful domain failover
这允许 XDC（多集群）模式减少故障转移期间重新运行 一些任务的痛苦。
NoSQL plugin model
这允许以最少的方式实现不同的 NoSQL 持久性。在撰写本文时 post，Temporal 尚未开始处理它。
MongoDB支持
在 NoSQL 接口之上，MongoDB 支持 WIP。
Using multiple SQL instances as sharded SQL
这允许用户拥有一个规模更大的Cadence集群。 （然后使用 XDC 添加更多数据库实例）
动态配置的配置存储
这使我们能够在不进行任何部署的情况下更改动态配置（如速率限制）。只需一个 CLI 命令就可以控制系统的行为。
它处于试验阶段，仍 WIP 可用于生产。
Workflow notification
允许从 Cadence 获取通知的 WIP 生态系统项目。这就是 Cadence 使用 Kafka 传递可见性消息的好处。 Temporal 不使用 Kafka，这将很难支持此功能。
定期健康检查器(Canary) and Benchmark tool and benchmark setup docs
更多文档
Temporal 缺少的其他小改进
- TerminateIfRunning IDReusePolicy
- 所有域API转发策略
- Better & cleaner XDC configuration
- Tooling to deserialize database blob data ... ...