应用程序的无服务器：实践中的架构

理解[无服务器0是一回事。很好地实施它是另一回事。许多接受这一概念的人一路走来发现，承诺的轻松却伴随着无人提及的艰难决定。

幻灯片的[无服务器1] 与生产代码的无服务器之间的距离是团队受到伤害的地方。并不是因为技术不好，而是因为它需要一种思维方式，而很少有人在陷入困境之前就已经发展起来。

本文适合那些决定使用 [无服务器2] 进行构建并希望正确实施的人。让我们谈谈真正的设计决策、实现中出现的陷阱，以及将可靠的架构与难以维护的混乱功能区分开来的规则。

一开始的欺骗性轻松

无服务器有一个诱人的开始。几分钟后，您上传第一个函数，它就会做出响应，似乎一切都会那么简单。这就是陷阱所在。

问题不在于编写函数。它正在编写五十个函数，这些函数相互通信、共享逻辑、依赖于数据，并且需要在六个月后被团队理解。复杂性并不会随着[无服务器3]而消失。它改变了位置，离开了基础设施，转向了建筑。

那些没有意识到这一点的人构建了所谓的“分布式单体”：分布式系统的所有缺点，没有任何深思熟虑的设计的优点。这是世界上最糟糕的情况，而且比你想象的更常见。

这是我的中心立场。无服务器并不放弃架构，它需要更多架构。

当您管理服务器时，部分规则是由基础设施强加的。你被迫思考这些片段是如何组织的。无服务器消除了这种强加并返回完全的自由。没有纪律的自由就会变得混乱。

因此，良好地实施[无服务器4是一种有意识的设计练习。您需要有目的地决定如何划分职责、职能如何沟通、状态位于何处以及如何使这一切保持易于理解。那些将无服务器视为“快速无服务器代码”的人以创纪录的速度收获了技术债务。

第一个困难的决定是尺寸。函数太小会增加通信的复杂性。太大的功能会失去模块化和独立可扩展性的好处。

一个好的经验法则是围绕明确的业务职责而不是琐碎的操作来组织角色。每个功能必须做一些有凝聚力且易于理解的事情。抵制将一切碎片化为微观碎片的诱惑，“极其细粒度”的诱惑通常会导致难以控制。

[无服务器 5 函数本质上是无状态的。他们出生、执行、死亡。这意味着所有状态都需要存在于它们之外，在数据库、缓存、存储中。

这是最大的思维转变之一。您无法在运行之间保留任何内容。所有的坚持都是明确的、外在的。良好的设计，为每种类型的数据选择正确的存储，是将可靠的应用程序与充满不可预测行为的应用程序区分开来的关键。

在真正的无服务器架构中，功能需要交互。它们如何通过事件和队列进行同步、等待响应或异步通信的决定决定了系统的整体稳健性。

通过事件进行的异步通信往往会带来更大的弹性：如果某个部分发生故障，消息就会等待。但它增加了跟踪的复杂性。同步通信更容易理解，但它会产生耦合并传播故障。这种选择不是次要的技术性选择，而是结构性的。

想象一下使用[无服务器7]构建交付应用程序的后端。订单流程涉及几个步骤：验证、收费、通知餐厅、跟踪配送。

幼稚的实现会产生一个巨大的函数，试图同步协调一切。结果：缓慢、脆弱且无法调试。如果通知失败，则整个请求将挂起。

自觉执行，责任分离。函数接收并验证请求并记录它。这会发出一个独立触发计费、通知和跟踪的事件。每个部分都会发生故障并自行恢复。订单状态存在于数据库中，每个人都可以访问。

两者之间的区别不是技术。这是在编写第一行之前进行的设计。

第一个陷阱是调试。当系统中出现涉及数十个功能和事件的问题时，查找原因非常困难。如果从一开始就没有适当的跟踪，你就会陷入盲目。投资[可观察性8]不是可选的，而是生存的条件。

二是配置爆炸。每个函数都有其权限、变量和触发器。在规模上，手动管理会成为错误的来源。将基础设施视为代码、版本化和自动化，不再是一种改进，而是成为一种必然。

第三是孤立的幻觉。功能看似独立，但共享库、队列和提供者限制。表现不佳的功能可能会影响其他功能。思考这些看不见的依赖关系是工作的一部分。

我在实践中发现，[无服务器9] 并没有消除艰苦的工作，而是取代了它。你不再关心机器，而是开始关心设计、沟通和状态。对于那些遵守纪律的人来说，其结果是强大的：灵活、可扩展且具有成本效益的系统。

对于那些将其视为捷径的人来说，结果是一场无人理解、无人愿意维持的纠结。技术是一样的。改变的是那些运用它的人的严谨性。

无服务器并不容易。这是不同的。差异是通过设计而不是仓促赢得的。

如果您正在实施[无服务器10]架构并希望避免经典陷阱，那么值得改变您的想法。我在博客上还有其他关于无服务器概念、用例和日常操作的文章，这些文章补充了这一实施愿景。