cadence-workflow - 时间工作流程与Cadence工作流程

Question

Temporal.io与cadenceworkflow.io有何关系？如果根据节奏工作流服务启动新项目，应该使用什么？

Answer 1

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

temporal.io是Cadence项目Maxim Fateev和Samar Abbas的原始创始人和技术负责人的Cadence项目的分支。我们成立了Temporal Technologies，并获得了风险投资，因为我们相信通过AWS Simple Workflow，Durable Task Framework和Cadence项目开创的编程模型具有超越单一公司的潜力。拥有一个商业实体来推动该项目向前发展对于该项目的寿命至关重要。

时分叉具有Cadence的所有功能，因为它不断与它融合。它还实现了多个新功能。

这是自Temporal音叉最初发布以来Cadence和Temporal之间的一些技术差异（预计在05/2020达到生产状态）

所有节俭结构都被原生动物结构所取代

Cadence的所有公共API均依赖Thrift。节俭对象也以序列化形式存储在数据库中。

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

通信协议从TChannel切换到gRPC

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

Temporal将gRPC用于所有进程间通信。

TLS支持

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

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

简化配置

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

发布管道

Cadence不会测试任何公开发布的工件，包括docker映像，因为它的内部发布管道仅确保内部构建的工件的质量。它还不会对未在Uber中使用的依赖项执行任何发布测试。例如，除了进行不完全的单元测试外，还没有对MySQL集成进行过测试。 CLI和其他组件也是如此。

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

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

转到SDK

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


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


Java SDK

Temporal在Cadence Java客户端上实现了以下改进：


工作流和活动注释，以允许活动和工作流实施对象实施非工作流和活动接口。对于像Spring这样的AOP框架来说，这很重要。
多态工作流和活动接口。这允许在多个活动和工作流类型之间具有公共接口。
动态注册信号和查询处理程序。
工作流和活动拦截器允许实现一些功能，例如通过外部配置文件配置超时。
活动和工作流程类型名称生成得到改进


我们还有许多其他功能和计划用于其他语言的客户端SDK。您可以在Temporal Slack Workspace找到我们。