对于最终用户来说，云原生服务应该简化生活并提供更多的灵活性。然而，对于开发人员来说，由于它们的分布式特性，它们可以使生活变得更加复杂。其中一个挑战是管理状态，这是数据库从业者的第二天性，但不一定是应用程序开发人员。这就是Temporal Technologies所面临的挑战，它提供微服务编排背后的状态管理，填补Istio等服务网格遗漏的地方。

可以理解的是，你可能从来没有听说过这家成立两年的公司，因为它的网站很少，让公司看起来仍然很隐秘。目前尚不清楚Temporal是否拥有大量付费用户;它列出了Datadog、Netflix、Instacart、Qualtrics、Box等公司的商标，但它们是开源技术的用户，而不是付费客户。如果你深入挖掘，你可以找到一些真实的文档。但如果我们忘了提一下，Temporal刚刚获得了1.03亿美元的B轮融资。

具体来说，Temporal定位了一个狭窄的任务:管理微服务的状态。考虑到微服务通常在高度分布式的云环境中启动，管理状态类似于在无主或多主数据库中编排事务。这是一个挑战，例如，Cassandra开发人员非常了解。在数据库中，这都是关于平衡事务一致性和写可用性。在应用程序或微服务层，它与可用性有关，其中链(在本例中，托管特定微服务的计算节点)的强度取决于其最薄弱的环节。

管理提交事务的状态是确保结果有效和最新的关键，也是防止系统(无论是数据库还是应用程序)崩溃的关键。例如，当您从银行ATM机提取现金时，状态管理对于确保仅在帐户被借记时交易才完成至关重要。

在分布式环境中管理状态的需求是非常关键的，因为有多个活动部件，其中一个很可能会失败。因此，在互联网或云上运行的任何东西都需要针对故障进行工程设计，包括故障转移和变通，因此单个节点的中断不会使整个应用程序或服务崩溃。

在数据库世界中，状态引擎通常是内置的;如果启动数据库，则不必编写自己的状态引擎。在AppDev领域，情况并非如此;开发人员通常不得不自己编写。

对于微服务，除了应用程序代码外，组织通常还必须编写自己的状态机。对于提供在线员工背景调查的临时用户检查，典型的工作流程通常涉及一系列50 - 60个自动和手动步骤(每个步骤都是微服务)，从各种外部来源检索数据。有很多Kafka队列需要处理，将数据写入多个目标数据库，然后编写逻辑来合并结果。有了临时服务器，他们可以专注于应用程序，而不是状态引擎。

Temporal将其解决方案描述为“用于大规模编排高度可靠的关键任务应用程序的开源平台”。对于微服务，乍一看，这听起来很像服务网格所做的。但是，服务网格在基础设施级别运行，在节点停止运行时建立连接并确保故障转移。相比之下，Temporal侧重于应用程序级别，更具体地说，检查微服务中的代码或逻辑是否被执行，如果没有，则管理处理级联依赖关系的解决方案。

Temporal用微服务解决的问题并不是什么新鲜事。如上所述，在AppDev世界中，状态引擎必须作为外部代码编写，或者作为某个框架的一部分捆绑在一起。这正是互联网应用程序必须解决的问题，因为web是无状态的，这导致了专用的中间件或应用程序服务器来处理web应用程序的过程，其中像Java这样的流行语言带有自己的管理状态的机制。

随着时间的推移，历史在微服务层中不断重演。它的状态管理服务器技术来自一个有五年历史的开源项目，该项目是优步开发工作的产物。它是围绕时态服务器构建的，这是一个位于计算服务器和可执行源代码之间的微服务编排平台。

这引出了一个明显的问题:如果微服务本质上是分布式的，在分布式计算环境中执行，那么中央编排服务器不会因为引入单点故障而破坏目的吗?答案是一个新的“实验性”多集群异步复制特性，它应该提供必要的故障转移功能。当谈到微服务的事务性保证时，未来的工作仍在进行中。