temporal.io与cadenceworkflow.io有何关系？如果要根据节奏工作流服务启动新项目，应该使用什么？
答案 0 :(得分：29)
免责声明：我是Cadence项目的原始联合创始人和技术负责人，目前是Temporal Technologies的联合创始人/首席执行官。
temporal.io是Cadence项目Maxim Fateev和Samar Abbas的原始创始人和技术负责人的Cadence项目的分支。我们成立了Temporal Technologies，并获得了风险投资，因为我们相信通过AWS Simple Workflow，Durable Task Framework和Cadence项目开创的编程模型具有超越单个公司的潜力。拥有一个商业实体来推动该项目向前发展对于该项目的寿命至关重要。
temporal.io分支具有Cadence的所有功能，因为它不断与它合并。它还实现了多个新功能。
这是自Temporal叉子首次发布时Cadence和Temporal之间的一些技术差异（预计在05/2020达到生产状态）
所有节俭结构均被原生泡沫替代
Cadence的所有公共API都依赖Thrift。节俭对象也以序列化形式存储在数据库中。
Temporal将所有这些结构转换为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的任何人来说都很重要。
有效负载元数据
Cadence将活动输入和输出以及其他有效负载存储为二进制blob，而没有任何关联的元数据。
Temporal允许将元数据与每个有效负载相关联。它启用了诸如动态可插拔序列化机制，无缝压缩和加密之类的功能。
故障传播
在Cadence中，活动和工作流失败被建模为单个二进制有效负载和一个字符串原因字段。仅Java客户端支持跨工作流和活动边界的链接异常。但是这种链接依赖于脆弱的GSON序列化，不适用于其他语言。
临时活动和工作流失败are modeled as protobufs，并且可以链接到不同SDK中实现的组件之间。例如，单个故障跟踪可能包含一条链，该链由异常所引起，该异常源自以Python编写的活动，并通过Go子工作流程传播到Java工作流程，再传播到客户端。
Go SDK
Temporal在Cadence Go客户端上实现了以下改进：
Java SDK
Temporal在Cadence Java客户端上实现了以下改进：
我们还有许多其他功能和计划用于其他语言的客户端SDK。您可以在Temporal Community Forum找到我们。
答案 1 :(得分：8)
我来自Uber的Cadence团队，我想告诉您，我们的团队将继续积极开发Cadence。以下是我们最近与Cadence社区共享的更新的一部分：
我们想加强Uber的Cadence团队致力于 Cadence项目的增长和开源开发。今天， Cadence在Uber内为100多种不同的用例提供支持 快速增长。总共有5000万个执行中的执行 平均而言，我们的客户每月完成3B +次执行。 在Uber之外，我们还知道许多不同的工程团队 公司已经将Cadence用于其关键业务 工作流程。我们很高兴能继续将Cadence发展为 向后兼容的开源项目，增加了 着眼于近期的可靠性，可扩展性和可维护性 学期。
现在比较Cadence和Temporal可能还为时过早。尽管如此，我对如何系统地了解Cadence的路线图以确保所有必要的信息可用以进行未来的比较有一些想法。当我们创建一个包含路线图信息的页面时，我将使用链接更新此帖子。
同时，如果您需要有关Cadence的更多信息，在这种情况下会有所帮助，请告诉我。
答案 2 :(得分：2)
Temporal.io是一家分叉节奏项目的公司，现在正在其基础上进行构建-将其命名为临时的。 它是由节奏的作者创立的。
我建议使用temporal.io，因为它正在积极开发中
答案 3 :(得分：2)
我的个人观点并非来自Uber，而是作为Cadence项目的外部贡献者。
很可惜，该项目分为两个部分，包括社区。时间是一个伟大的项目/团队/公司。我希望Temporal取得成功。
有时候，竞争对他们很有好处。事实都在积极发展中。如果查看他们的路线图，您会发现他们有不同的重点。这两个项目有着相同的愿景，使每个人都可以重新思考长期运行的业务的编程模型。
我了解到，目前很难说哪个更好，因为从Cadence那里得到时态。但是随着时间的推移，这些项目会有所分歧，最终答案将更加清晰，例如MySQL / MariaDB，Cassandra / Scylladb，甚至是MongoDB社区版本/商业版本。
由于Cadence团队的支持，我个人倾向于Cadence，并且大多数Cadence贡献者仍在这里，而且我始终相信Cadence团队成员的出色团队合作。而且显然是因为我在那儿花了更多时间。