构建云原生应用程序时可以忽略弹性吗？

Temporal 的 Samar Abbas 认为开发人员甚至不必考虑丢失状态。只有这些永不失败的持久执行。

如果您长期使用文字处理工具，您会记得按下“保存”键盘快捷键时的本能反应——害怕丢失您的工作，大声咒骂并哀叹您刚刚丢失的出色工作。

使用现代工具（想想 Google Docs），这种担心甚至不会出现。说到一半就没电了？没问题。一切都保存在你离开它的状态，你可以继续前进。

工作流编排引擎 Temporal 的 Samar Abbas 和他的团队希望将这一概念引入您的企业工作流。您提供业务逻辑，他们处理所有需要专业知识的部分，例如持久性和弹性。

Temporal于 2019 年由 Abbas 和他的同事 Maxim Fateev 在 Uber 创立。他们为名为“Cadence”的叫车应用公司创建了一个开发平台。这是AWS Simple Workflow Service 平台的演变，二人在 2000 年代中期还是 Amazon 的同事时帮助开发了该平台。数十种 Uber 服务和应用程序采用了Cadence 。

Abbas 和 Fateev 离开后共同创立了 Temporal，并为 Cadence 构建了容错工作流引擎的后续项目。从那以后的三年里，该公司取得了稳固的成功，Netflix、Instacart 等公司都在使用 Temporal 的开源软件代码。今年早些时候，该公司获得了 1.03 亿美元的 B 轮融资，估值达到 15 亿美元。

我最近与阿巴斯进行了一次谈话（你可以观看整个过程）关于他和 Fateev 如何建立他们非常成功的企业。 （为了清晰和篇幅，他在下面的话进行了编辑）。

从 Uber 到 Temporal

2015 年，优步在西雅图开设了办事处，我加入了他们的工程团队。我和 Max [Temporal 联合创始人 Maxim Fateev] 在彼此不到一个月的时间内就加入了 Uber。我们一起工作的关键项目是 Cadence。

在优步，工程师们花了很多时间将低级队列、数据库和持久计时器拼接在一起，以在他们的应用程序中构建弹性。

这就是我们试图用像 Cadence 这样的系统来解决的问题，我们在 Cadence 中提供了仍然基于代码的高级抽象，但我们从工程师的盘子中取出了某些类别的故障，并在平台下解决了它们，让工程师专注于应用程序的业务逻辑，而不是构建弹性。

这在 Uber 内部取得了成功，并且由于它是开源的，我们开始看到该技术在外部得到广泛采用。所以在 2019 年，我和 Max 都决定迈出这一步，开始了 Temporal，因为我们真的想专注于该技术的外部采用。

暂时的开发者体验

人们有时将 Temporal 描述为工作流引擎，或描述其功能，但对我们而言，关键价值主张是开发人员的生产力：开发人员能够以多快的速度构建应用程序并使其在生产环境中运行，而无需花费数周或数月的时间来测试各种可能导致故障的故障情况发生在云原生环境中。

因此，我们考虑开发人员体验的方式不仅仅是技术必须提供的核心方面；我们从一开始就涵盖了整个软件开发生命周期，包括开发人员如何构建他们的应用程序。例如，许多工作流引擎通常采用领域特定语言 (DSL) 路线。我们都是基于代码的。我们知道开发人员喜欢编写代码，我们希望他们编写代码，但只是消除了某一类问题，例如在某些底层基础设施出现故障时如何使代码具有弹性，或者在网络故障发生时如何使代码具有弹性.

Temporal 何时以及如何产生影响？

汇款是 Temporal 被频繁使用的关键用例之一。如果您要将资金从一个账户转移到另一个账户，通常从用户的角度来看，是的，我从账户 A 借记，然后贷记到账户 B。但是大部分软件开发时间都花在了这两个调用之间的系统故障上。这基本上是工程师花费各种时间的地方。

这是一个例子，说明像 Temporal 这样的系统可以帮助很多人——它甚至感觉很神奇。我们经常听到这样的问题：如果此时我的申请失败了怎么办？

我们对这个问题的回答是：工作流永远不会失败（在 Temporal，我们称我们正在构建的原语为“工作流”。）然后就是电灯开关亮起的那些时刻之一。我们开始将此称为“持久执行”，在高层次上我们提供的是：您的执行是完全持久的。他们从不失败。

“无故障”状态工作流的业务影响

回到 90 年代，当我还在上学时，我们曾经在 Microsoft Word 中输入所有作业。您养成了每次编辑几次后都保存文档的习惯。然而，还是会出现某种类型的故障，比如硬盘坏了，你会丢失所有的工作。

现在，有了 Google Docs，孩子们甚至无法理解这一点。甚至没有“保存”按钮了。我们认为，有一类有状态应用程序仍处于 1990 年代，其中超过 80% 的代码是关于处理基础设施故障以建立有状态应用程序的弹性。每次事件发生时，您都会加载该状态，应用该事件，执行一系列操作，然后将该状态存储回去。这是大多数工程的方向：如何使其可靠、快速和高性能，并保护它免受各种故障和损坏。

开发人员甚至不必认为他们会失去状态。只有这些永不失败的持久执行。我认为这将彻底改变工程师对云原生系统的看法。

为什么要托管 Apache Cassandra？

我和我的联合创始人 Max 具有构建消息系统和中间件的背景。运行存储系统不是我们的强项。因此，当我们只有两个人创办公司时，我们的一个主要目标是利用我们的优势为 Temporal 用户提供最佳的开发人员体验。 Temporal 有一个服务器组件和客户端 SDK，大多数开发人员都使用它们来构建应用程序。但是人们如何才能以最小的运营开销来运行这些服务器呢？这是运行 Temporal 的大部分开销所在。

我们有一个可插入的持久化模型；我们支持Apache Cassandra 、MySQL 和 Postgres 作为可插拔适配器。 Cassandra 是具有非常好的可扩展性特征的适配器之一。对于我们的用户来说，一个关键的价值主张是他们正在运行关键任务应用程序，而可靠性是他们正在寻找的关键。因此，当我们将新的依赖项引入 Temporal fold 时，我们不会掉以轻心。我们对各种持久性选项进行了一个多月的评估。毫无疑问，这是DataStax Astra DB 。

一些数据库在某些功能上取胜，另一些数据库在其他功能上取胜。但在这种情况下甚至与技术无关；这是关于人民的。我们相信错误和失败是生活的一部分。这完全取决于您在发生中断时如何响应。这就是我们认为 Astra DB 获胜的地方。 DataStax 对待客户的方式以及他们在操作数据库时建立的各种关系有很多相似之处。这让我们相信这是我们想要为系统核心部分投资的依赖项。

如果没有像 Astra 这样的技术供我们利用和构建，我认为我们不会处于今天的位置。诸如仅操作 Cassandra 和单独“完成”事情之类的事情至少需要一年的时间，而这甚至不是我们核心力量的一部分。对于像我们这样的公司来说，关键价值主张是可靠性，如果我们不能找到一种方法以可靠的方式运行和操作您的存储，我们就没有业务。

立即注册Cassandra Forward，这是一个免费的两小时虚拟活动，将于 3 月 14 日举行，深入探讨 Apache Cassandra 的方方面面。

作者：Patrick McFadin，DataStax

Patrick McFadin 是 O'Reilly 图书“在 Kubernetes 上管理云原生数据”的合著者。他目前在 DataStax 从事开发人员关系工作，并且是 Apache Cassandra 项目的贡献者。 Patrick 曾担任 Apache Cassandra 的首席布道师（他也是新成立的 Cassandra 提交者！），并担任 DataStax 的顾问，在那里他在生产中构建了一些最大的部署。