无服务器场景(serverless)的容错怎么做？我们的设计

无服务器架构和FaaS（Function-as-a-service 函数即服务）近年来越来越受欢迎，这要归功于易用性、自动伸缩和按需付费的特性。然而，FaaS 基础设施中缺少应用程序的容错能力。

把坑留给码农？

默认情况下，AWS Lambda 或 Google Cloud Functions 等 FaaS 系统需要开发者自己考虑执行失败的情况。云服务的策略是：无论是应用程序自身错误还是基础设施故障，一旦函数执行失败就执行重试。这意味着函数可能会运行多次。

并且更可怕还有，你的业务代码也可能会运行 0.5 次，或者 3.2 次……这是怎么回事？

这个糟糕问题的原因是，大多数 FaaS 系统提供的能力不能保证资源层（如数据库或文件等）在执行失败后被清理。

在失败和重试的过程中，修改共享状态的应用程序会在不知不觉修改部分结果。如果一个请求将更新两个键 k 和 l，但函数在两次更新之间崩溃，那么现在客户端将看到较新版本的 k 和较旧版本的 l。

这就是云平台 FaaS 的现状。

FaaS 的无痛容错:原子性

为了避免这种类型的异常，开发人员需要一个简单的保证，那就是原子性：要么一个请求的所有操作全部成功，要么全部失败。传统做法中，原子性是由强一致性（事务式）存储引擎来保证的，但这些系统有众所周知的扩展和性能问题。如何才能让 FaaS 执行保证原子性？

为此，我们构建了一个名为 AFT（Atomicity for Fault Tolerance）