Fel*_*nov 18 cadence-workflow temporal-workflow
temporal.io 与 cadenceworkflow.io 有什么关系？如果根据节奏工作流服务启动一个新项目应该使用什么？
Max*_*eev 50
免责声明：我是 Cadence 项目的最初联合创始人和技术负责人，目前是 Temporal Technologies 的联合创始人/首席执行官。
temporal.io是 Cadence 项目Maxim Fateev和Samar Abbas的原始创始人和技术负责人的 Cadence 项目的分支。在与 Cadence 相同的 MIT（在 Apache 2.0 下有一些 SDK）许可下，该 fork 是完全开源的。我们启动了 Temporal Technologies 并获得了 VC 资金，因为我们相信我们通过AWS Simple Workflow、Durable Task Framework和 Cadence 项目开创的编程模型具有远远超出单个公司的潜力。拥有一个商业实体来推动项目向前发展对于项目的长期性至关重要。
temporal.io fork 具有 Cadence 的所有功能，因为它不断从中融合。它还实现了多项新功能。
以下是 Temporal fork 初始发布时 Cadence 和 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，没有任何关联的元数据。
Temporal 允许将元数据与每个有效负载相关联。它支持动态可插入序列化机制、无缝压缩和加密等功能。
故障传播
在 Cadence 中，活动和工作流故障被建模为单个二进制负载和字符串原因字段。只有 Java 客户端支持跨工作流和活动边界链接异常。但是这种链接依赖于脆弱的 GSON 序列化，并且不适用于其他语言。
临时活动和工作流故障被建模为 protobuf，并且可以跨不同 SDK 中实现的组件链接。例如，单个故障跟踪可以包含由异常引起的链，该异常源自用 Python 编写的活动，通过 Go 子工作流传播到 Java 工作流，然后传播到客户端。
去SDK
Temporal 对 Cadence Go 客户端进行了以下改进：
开发工具包
Temporal 对 Cadence Java 客户端进行了以下改进：
PHP SDK Cadence 不支持 PHP。Temporal 最近发布了PHP SDK。
NodeJS SDK Temporal 发布了NodeJS SDK的 alpha 版本。
我们计划为其他语言提供许多其他功能和客户端 SDK。您可以在Temporal Community Forum找到我们。
Lon*_*eng 12
使用iWF可以让您轻松在 Cadence 和 Temporal 之间切换。此外，iWF 将在两者之上提供一个很好的抽象，让您的生活变得更加美好。
事实上，Cadence 和 Temporal 都在积极开发中。如果查看他们的路线图，你会发现他们有一些不同的重点。这两个项目有着相同的愿景，让大家重新思考长期运行业务的编程模型。
如果您有多个 Cadence 集群，这允许跨不同集群和域启动 childWF。
gRPC 支持完全在服务器端完成。内部流量全部使用 gRPC，我们正在努力让用户从 Thrift 迁移到 gRPC。
该权限基于域，但可以扩展。与 Temporal 不同的是，权限策略可以存储在 Cadence 域数据存储中，这样您就不必构建另一个服务/存储来管理它们。请注意，整个提案是由社区成员制定的。
Workflow Shadower构建在 Workflow Replayer 之上来解决此问题。影子的基本思想是：根据您定义的过滤器扫描工作流程，从 Cadence 服务器获取扫描结果中每个工作流程的历史记录并运行重播测试。它可以作为测试运行以服务于本地开发目的，也可以作为工作人员中的工作流程来连续重放生产工作流程。
这允许 XDC（多集群）模式减少故障转移期间重新运行某些任务的痛苦。
这允许以最小的方式实现不同的 NoSQL 持久性。在写这篇文章时，Temporal 还没有开始研究它。
在 NoSQL 接口之上，MongoDB 支持尚未完成。
这允许用户拥有规模更大的Cadence集群。（然后使用 XDC 添加更多数据库实例）
这使我们能够在不进行任何部署的情况下更改动态配置（例如速率限制）。只需一个 CLI 命令就可以控制系统的行为。
它正处于实验阶段，仍处于生产准备阶段。
一个 WIP 生态系统项目，允许从 Cadence 获取通知。这就是 Cadence 使用 Kafka 传递可见性消息的好处。Temporal 不使用 Kafka，支持此功能非常困难。
我来自 Uber 的 Cadence 团队，我想让您知道 Cadence 继续由我们的团队积极开发。以下是我们最近与 Cadence 社区分享的更新的一部分：
我们想强调的是，Uber 的 Cadence 团队致力于 Cadence 项目的增长和开源开发。如今，Cadence 支持 Uber 内 100 多个不同的用例，而且这个数字还在快速增长。总的来说，平均任何时刻都有 5000 万次以上的持续执行，我们的客户每月完成 3B+ 次执行。在 Uber 之外，我们还知道，不同公司的许多工程团队已经将 Cadence 用于其关键业务工作流。我们很高兴能够继续以向后兼容的方式将 Cadence 发展为一个开源项目，并在短期内更加关注可靠性、可扩展性和可维护性。
现在比较 Cadence 和 Temporal 可能还为时过早。尽管如此，我对如何系统地阐明 Cadence 的路线图有一些想法，以确保所有必要的信息都在那里，以便进行此类比较。当我们创建一个包含路线图信息的页面时，我会用链接更新这篇文章。
同时，如果您需要有关 Cadence 的更多信息，这将在此上下文中有所帮助，请告诉我。
| 归档时间： |
|
| 查看次数： |
10724 次 |
| 最近记录： |