想象一下这种情况：您的组织构建了一个电子商务平台，开发人员可以在其中专注于库存管理，有竞争力的价格，交付管理和客户体验。而不是编写大量的技术上的基础结构代码来管理季节性，区域性和情景性的使用高峰。
听起来不可思议，对吧？使之成为可能的是一个无状态无服务器模型，该模型可扩展应用程序层并保留云本机应用程序的状态。分配状态的一种明智方法是复制和保留数据（即状态和行为的共置）。不仅是当前状态，还包括导致当前状态的所有状态和事件的完整历史记录。
因此，在发生故障的情况下，服务可以通过重播事件以从任何先前状态到达当前状态来进行自我修复。特别是，有状态无服务器模型的Cloudstate版本（它是有状态无服务器，事件源和Akka的组合）不仅在任何给定时刻都是有状态的，而且它是自我修复的，并且可以从任何灾难中恢复到当前状态。无需任何外部模拟即可快速完成。
扩展数据库或复制缓存系统可以相当快地处理大量数据。通过事件溯源，函数可以在启动时加速（或赶上）到当前状态。这意味着在每次事件处理时都不需要往返于外部持久数据存储，因为它可以自给自足。这些分布式函数成为具有ZeroOps的应用程序的真正扩展。根据需求，应用程序现在可以真正具有弹性，并且可以在云中无限扩展。
管理状态：云中企业的银弹
无状态无服务器方法允许企业构建复杂的工作流，而无需往返数据库。如果在无服务器设计中使用一系列拼凑的函数链，具有触发其他函数的函数，工作流中有很多队列或频繁的数据库连接，那么您需要使用有状态无服务器来重新考虑您的设计。在撰写本文时，需要考虑一些流行的框架，包括Cloudstate，Azure耐用功能（基于Dapr）和RIFF。
即使这些功能旨在保持更长的生命周期（几天甚至几个月），您也只会在执行该功能函数时付费，而不是在等待某件事发生时付费。这些函数还可以快速执行，因为没有按需供应开销。它们将在“睡眠模式”下运行，在业务流程功能调用它时醒来，在工作流周期中执行其工作，保留状态，然后过渡回睡眠状态。计费基于执行时间和所使用的内存，而不是处于睡眠模式时，而是基于消耗的真正定价模型。