根据TemporalTechnologies的微服务状态

对于最终用户来说，云原生服务应该可以简化生活并提供更多的敏捷性。尽管如此，对于开发人员来说，由于它们的分布式特性，它们可以使生活变得更加复杂。挑战之一是管理状态，这是数据库从业者的第二天性，但不一定是应用程序开发人员。这就是TemporalTechnologies所面临的挑战，它提供微服务编排背后的状态管理，接替Istio等服务网格的不足。

可以理解的是，您之前可能从未听说过这家成立两年的公司，因为其稀疏的网站使公司看起来几乎仍处于隐身状态。目前尚不清楚Temporal是否拥有大量付费客户群;它列出了许多徽标，如Datadog、Netflix、Instacart、Qualtrics、Box等，但它们是开源技术的用户，而不是付费客户。如果你深入挖掘，你实际上可以找到一些真实的文档。但以防万一我们忘记提及它，Temporal刚刚获得了1.03亿美元的B轮融资。

具体来说，Temporal确定了一项狭窄的任务：管理微服务的状态。鉴于微服务通常在高度分布式的云环境中启动，管理状态类似于在无主数据库或多主数据库中编排事务。这是一个挑战，例如，Cassandra开发人员非常了解这一点。在数据库中，一切都是关于平衡事务一致性和写入可用性。在应用程序或微服务层，它是关于可用性的，其中链(在这种情况下，托管特定微服务的计算节点)将仅与其最薄弱的链接一样强大。

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

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

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

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

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

Temporal用微服务解决的问题是nothingnw。如上所述，在AppDev世界中，状态引擎必须编写为外部代码或捆绑为某些框架的一部分。这正是Internet应用程序也必须解决的问题，因为Web是无状态的，这就是导致专用中间件或应用程序服务器处理Web应用程序过程的原因，其中像Java这样的流行语言具有自己的状态管理机制.

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

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