应用程序的无服务器：具有真实示例的架构

无服务器很容易抽象地解释，但在实践中很难可视化。大多数介绍都会谈论函数、事件和自动可伸缩性，这些都是正确的概念，但它们并不能帮助那些需要决定这是否适合手头问题的人。

理解[无服务器0的最好方法是看看它真正的亮点在哪里。它比其他方案更好地解决了哪些具体问题？在有效的架构中重复了哪些模式。

本文以理论换实例。让我们看看真实的架构，即每天出现在数字产品中的那种架构，并了解为什么[无服务器1] 在每种架构中都有意义。不是为了出售技术，而是为了让您认识到什么时候它是正确的选择。

几乎所有无服务器良好使用背后的模式

在示例之前，值得注意一件事。最好的[无服务器2]应用程序有一个共同的特征：它们是响应事件而发生的任务，不需要一直运行。

发生了一些事情，文件到达，用户单击，时间到达，收到消息，函数被唤醒，完成其工作，然后再次休眠。您只需为执行的那一刻付费。没有机器在等待。

当您内化这种模式时，您就会开始看到[无服务器3] 机会无处不在。他也开始认识到自己不适合的地方。

想象一个用户发送图像、文档、个人资料照片、收据的产品。每次上传都需要进行处理：调整大小、验证，或许还需要分析。

在传统架构中，您将保持服务器为该处理做好准备，大部分时间处于闲置状态，并在高峰期间过载。在[无服务器4中，流程是不同的。文件到达存储器，该事件触发一个函数，该函数处理图像并终止。

如果有一千个同时上传到达，平台会并行运行一千个执行。如果没有人到达，您无需支付任何费用。这种契合是完美的，因为工作是基于事件的、间歇性的，这正是 [无服务器 5] 获胜的领域。

考虑一个具有明确定义的高峰时间的应用程序的后端 API。一款早晚使用的交通应用程序。月初突发的预约安排系统。

维护高峰时的服务器规模意味着要为低谷时的闲置容量付费。针对山谷调整规模意味着不应对高峰。这是一个经典的困境。

[无服务器6API 优雅地解决了这个问题。每个请求都会触发执行，平台会根据流量进行扩展。巅峰时，规模化；在山谷里，收集。您可以跟踪实际使用曲线，而不是为最坏的情况进行配置。对于不规则流量，这是最具成本效益的用例之一。

许多组织都依赖小型自动化。每天早上生成一份报告。在特定时间发送提醒。定期在系统之间同步数据。清除旧记录。

传统上，这些任务需要服务器一直运行，每天只运行几分钟。浪费。在[serverless7]中，您可以定义触发器（例如时间），并且该函数仅在该时刻执行。

对于市政府来说，这可能意味着每天晚上整合服务数据或触发应税通知，而无需维护专用基础设施。单独运行的管理任务仅花费它们所占用的秒数。

最复杂的例子也是最有力的。现代应用程序通常由需要相互反应的多个部分组成。

已下订单。这需要更新库存，通知客户，记录交易，也许触发物流。这些反应中的每一个都可以是一个独立的函数，由“下订单”事件触发，而不是一个以耦合方式执行所有操作的整体系统。

这种事件驱动的架构自然是[无服务器8]。每个部分都很小、独立并且可以自行扩展。如果一个组件出现故障，其他组件将继续运行。灵活性是巨大的，尽管我们将看到，它带来了自身的复杂性。

这些例子揭示了我的中心立场。无服务器并不比传统架构好，也不比传统架构差。它是不同的，它的价值完全取决于它与问题的契合度。

当工作是基于事件的、间歇性的和可变的时，[无服务器9]通常是一个很好的选择。在工作持续、可预测且对延迟敏感的情况下，其他方法可能效果更好。

技术成熟度并不在于采用[无服务器10时尚，而是在于认识到问题的形式并选择合适的工具。上面的示例共享一个共同的签名，您必须学会识别这个签名。

第一个错误是在不适合的地方强制使用[无服务器11]。具有长时间连续处理或依赖于持续低延迟的应用程序会受到该方法的限制。强行安装会产生挫败感和成本。

二是低估了分布式复杂性。具有数十种功能的事件驱动架构可能会变得混乱，难以理解和调试。更大的灵活性意味着更多的部件相互通信，这需要设计纪律。

第三是极度忽视成本。对于非常高且恒定的数量，按执行付费模型最终可能比专用机器更昂贵。值得进行数学计算，而不是假设节省。

在这些例子之后，实践课程就很简单了。学习识别[无服务器12]能够很好解决的问题格式：事件、间歇性、可变性、部件之间的独立性。

当你看到这种模式时，你的决定就变得很自然。当您看不到它时，您就可以避免采用与您需要做的事情不匹配的架构的麻烦。

好的架构并不是选择最新的技术。它正在选择适合问题的一个，就像一直缺失的一块一样。

如果您正在设计一个架构并想要讨论 [无服务器13] 真正适合您的案例，那么它就值得讨论。我在博客上还有其他关于实践和日常生活中无服务器的文章，重点是执行和操作，适合那些已经决定走这条路的人。