对无服务器架构的误解：你以为 AWS Lambda 能做到的 5 件事……但它其实做不到。

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

啊，Serverless……它现在是软件工程界的宠儿，互联网上到处都是Serverless和AWS Lambda的成功案例。但实际上，这个软件工程界的宠儿还隐藏着一些秘密……

没错，Serverless 并没有宣传页面吹嘘的那么好。这并不是说 Serverless 本身不好——我个人非常喜欢 Serverless。但有几次使用过程中，我感觉自己被骗了。

读完本文，您将了解 AWS Lambda 的一些局限性，以及 DDOS 和内存泄漏等一些功能的真正工作原理。

在深入探讨之前，我想先说明一下，本文主要基于 AWS Lambda，这些误解也主要针对 AWS。虽然其他云服务提供商的相关主题可能类似，但今天我们将重点关注 Lambda。

1. 函数独立缩放

理念：采用无服务器架构，每个服务都可以独立扩展，一个功能的负载增加不会影响其他功能。

认为各个功能是真正独立的，这似乎合乎逻辑。毕竟，这正是微服务架构的优势之一，对吧？将应用程序拆分，各个独立部分就可以独立扩展。

但是，由于 AWS 的限制，函数无法真正独立地扩展。为什么呢？因为 AWS 账户默认限制 Lambda 函数的并发执行次数为 1000 次。这看起来似乎很合理，但让我们想想这个限制会以我们意想不到的方式影响我们……

想象一下，你公司内部有一个用于记录元数据的公开 API，它与生产函数位于同一区域和 AWS 账户中……这很正常。然后，这个 API 开始承受巨大的负载。当达到并发限制时，将不再创建新的函数。这实际上会导致该区域内所有函数的性能问题。

您可以申请提高某个区域的限额，或者为特定的 Lambda 函数预留并发量……但始终存在一个您有可能达到的限额。唯一真正的解决方案是使用AWS Organizations将每个服务拆分到各自的 AWS 账户中，这样每个服务都有自己的限额，但这样拆分服务会带来额外的运维开销。

2. 功能可逐步提升以满足任何负载需求

信念：无服务器架构可以快速扩展，满足任何工作负载的需求（无需任何花哨的调整）。

你可能认为，既然使用了无服务器架构，就无需进行容量规划，任何规模的工作负载都能得到快速有效的响应。但实际上，在某些情况下并非如此。

Lambda每分钟只能创建 500 个新实例。这意味着在突发流量情况下，响应时间可能会受到影响。不仅存在实例创建数量限制，而且每个新请求都会访问一个冷启动的容器，从而导致 Lambda 函数的“冷启动”（即容器初始启动所需的时间）。

和以前一样，有一些方法可以绕过扩展限制，例如使用预置并发。但Serverless的卖点不就是让我们不必再考虑这些问题吗？哦，当然，预置并发会增加成本。

3. 函数无法被拒绝服务攻击

信念：运行无服务器架构意味着 DOS（拒绝服务）攻击并不真正令人担忧，即使发起攻击，函数也能无限扩展，从而保护我们。

正如我们在第一部分和第二部分讨论的那样，Lambda 函数并非完全免疫于拒绝服务 (DoS) 攻击。事实上，如果攻击者知道您正在使用 AWS Lambda，他们就可以利用这些扩展限制来攻击您，从而确保攻击迅速而猛烈，而非持续不断。

除了故障转移到不同的区域或 AWS 账户并启用你能找到的最好的DOS 防护之外，没有其他真正的 DOS 问题解决方案。

4. Lambda 函数不存在内存泄漏

信念：由于 Serverless 运行在临时函数上，这意味着您不必担心内存泄漏。

因为你运行的是临时函数，你可能会认为函数不会出现长时间运行的问题，比如内存泄漏，或者一个函数的状态影响另一个函数，但事实并非如此……

无服务器架构可能会出现内存泄漏，并且如果一个函数中全局存储的状态不小心可能会泄漏到下一次调用中，从而导致问题。

Serverless 架构存在内存泄漏的问题，乍一看可能令人困惑，但当你真正理解 Serverless 架构的工作原理后，一切就都说得通了。让我来解释一下……

Serverless 的工作原理是通过创建容器。在特定负载条件下，系统会启动一个新容器，并使其保持运行状态直至达到使用期限。当负载下降时，容器会被关闭。

在这些容器的整个生命周期内，无服务器函数都会维护其状态。任何全局存储的值或泄漏的内存都会传递给下一个函数。

内存泄漏没有真正的缓解措施——你只需要注意它们，以防函数性能开始下降。你可能还需要监控底层容器的运行时间，以帮助你进行调试。

5. Lambda 函数利用单线程处理

观点： Serverless 可以利用异步处理，例如 JavaScript 中的单线程异步。

如果您使用过类似 Node.js 的框架，您可能熟悉任务可以并发处理，同时等待其他异步任务完成的概念。然而，AWS Lambda 的工作方式是每次只处理一个请求。这意味着您的 Lambda 函数在处理请求时可能会处于“空闲”状态。

但凡事都有好的一面……由于 Lambda 每个函数只处理一个请求，您可以做一些有趣的事情。例如，您可以将请求信息存储在 Lambda 的全局上下文中。将请求信息存储在全局上下文中非常有用，例如，您可以将请求上下文添加到日志或事件中。

揭秘：关于无服务器架构的 5 个误区

今天的内容就到这里！我们已经破除了关于无服务器架构和AWS Lambda函数的五个常见误解。

我并不反对无服务器架构，恰恰相反。事实上，AWS 对这些问题都有详细的文档说明，只是我很少看到有人提及或讨论这些方面。但我认为社区应该了解全貌，而不仅仅是那些对无服务器架构有多么好的过度吹捧。

无论如何——我希望您能从这篇文章中了解到一些关于无服务器架构和 AWS Lambda 的新知识。现在，您能带着更充分的了解开启您的无服务器架构之旅。

云原生领域的朋友们，下次再聊！

您对 Serverless 有哪些误解，后来证明是错误的？

这篇文章《对无服务器架构的误解：你以为 AWS Lambda 能做到但实际上做不到的 5 件事》最初发表于The Dev Coach网站。

Lou 是《云原生软件工程通讯》的编辑，这份通讯致力于让云软件工程更易于理解和掌握。每两周，您都会在邮箱中收到一份精选的云原生软件工程内容摘要。