AWS Lambda Durable Functions：首次印象
Source: Dev.to
无服务器架构是一个持续增长的话题，尤其是当我们谈论 Amazon Web Services 时。近年来，该平台推出了一系列旨在实现可扩展性、弹性和降低运维复杂性的创新，使团队能够越来越专注于业务逻辑。
长期以来，无服务器模型的主要限制之一与函数的最大执行时间有关。对于 AWS Lambda，这一限制始终是 15 分钟，这自然限制了可以直接通过函数解决的问题类型。
在最近几个月，AWS 开始更成熟地探索一个在其他平台上已经熟知的概念：持久编排。在本文中，我使用术语 Durable Functions 来指代一种架构模式（而非特定服务），它允许在 Lambda 上构建长期工作流，能够延伸至数天、数月甚至一年，而无需任何函数保持持续运行。
可持久编排解决的问题
在传统工作流中，执行是连续进行的，并且直接受限于函数的生命周期。这对短任务来说运行良好，但在需要更多控制和更长处理时间的场景下会成为障碍，例如：
- 长时间运行的数据管道；
- 涉及多个外部集成的流程；
- 依赖人工交互的过程；
- 与人工智能和机器学习相关的工作负载。
为满足此类需求，Durable Functions 模式引入了 基于事件的编排执行 和 持久化状态 概念。实际上，这意味着一个过程可以前进、暂停、等待外部事件，然后在以后继续执行，并始终保留其上下文。
重要提示： Lambda 函数 不会在整个期间持续运行。可持久的是 工作流，而不是连续的执行。
如何在实践中实现持久化编排
该模式的运行基于无服务器生态系统的几个核心支柱：
- 短小且幂等的执行；
- 将状态持久化在函数之外；
- 通过事件进行通信。
流程的每一步都由事件触发，执行结束后函数会持久化后续流程所需的状态。编排的唯一标识符确保在收到新事件时，流程能够准确地从正确的位置继续执行。
这些事件可以由以下来源发出：
- 应用程序本身；
- 其他服务；
- 或者甚至是外部用户，例如在手动审批场景中。
这种方法能够构建极其灵活的工作流，同时不违背无服务器模型的前提。
Durable Functions 与 Step Functions
自然会将其与 AWS Step Functions 进行比较。虽然两者都解决编排问题，但主要区别在于 通过代码的控制层级：
Durable Functions
- 完全在代码中定义的工作流；
- 更高的灵活性和动态性；
- 与应用程序一起进行工作流的版本管理；
- 适用于复杂且高度自定义的逻辑。
Step Functions
- 基于状态的声明式工作流；
- 出色的可视化和可观测性；
- 较低的运维复杂度；
- 是可预测且明确的工作流的理想选择。
Durable Functions 并不取代 Step Functions；它们解决的是一套不同的问题，其中对工作流在代码中进行细粒度控制是必要的。
基于事件的架构
基于事件的执行是从事 serverless 工作的人已经非常熟悉的概念。在持久化编排中，它变得更加核心。
像 Amazon EventBridge 这样的服务可以完全解耦工作流的各个步骤，而 Amazon DynamoDB 等数据库则可用于持久化执行的状态和元数据。
该模型保证：
- 高弹性；
- 发生故障时自动恢复；
- 几乎无限的可扩展性。
生态系统的演进与未来展望
随着 Lambda 支持的运行时不断演进（截至目前，Durable Functions 仅支持 Python 和 Node.js 语言），以及 boto3 库的持续进步，代码层面的更高级编排模式自然会在 AWS 生态系统中占据越来越多的空间。
随着无服务器应用的成熟，对更长、更可控且更具弹性的工作流的需求也在增长——正是在这种情境下，Durable Functions 的概念得以契合。
结论
Durable Functions 代表了 AWS 无服务器架构演进中的一个重要步骤。它们并不是已经成熟的解决方案的替代品，而是针对需要更高控制、灵活性和更长执行时间的场景的强大替代方案。
了解何时应用此模式（以及何时选择更简单的解决方案）对于充分利用无服务器生态系统至关重要。