资深 CTO 带来的 8 条 Serverless 最佳实践

多年来，社区一直在讨论最佳实践，但只有一小部分能够为人们所接受。

大多数遵循这些实践的无服务器从业者面对的是大规模的工作场景。无服务器架构承诺在大规模和突发性工作负载上发挥作用，所以大部分最佳实践更关注规模化问题，例如零售行业的 Nordstrom 公司和物联网领域的 iRobot。如果你的目标还达不到那样的规模，可能就无需遵循这些最佳实践。

请记住，最佳实践并非“唯一的实践”。最佳实践是以一系列基本假设为前提，如果你的场景不存在这些假设，那么这些最佳实践可能就不合适你。

我的主要假设是所有人构建的应用程序都能够大规模运行（即使它们可能永远不会）。

以下是我认为的最佳实践。

一个 function 应该只做一件事

这个最佳实践与 function 的错误和伸缩隔离有关。

换句话说，如果在 function 中使用 switch 语句，那么你可能是做错了。

很多教程和框架都是基于 function 大单体，然后在单体前面加上单个代理路由，并使用 switch 语句。我不喜欢这种模式，因为它的伸缩性不好，并且往往会产生大而复杂的 function。

这样做的问题在于，当你想要进行扩展时，需要扩展整个应用程序，而不是某些特定的元素。

假设 Web 应用程序的一部分需要处理 100 万的流量，而另一部分只需要处理 1 千的流量，而当你需要对前者进行优化时，也不得不捎带上后者。这是一种浪费，而且你无法轻易做到对后者的优化。所以，建议将它们分开。

不让 function 调用其他 function

调用其他 function 的 function 是一种反模式。

这种模式在很少情况下是有效的，但从根本上说，还是不要这样做。这样会成倍增加你的成本，让调试变得更复杂，而且抵消了隔离 function 所带来的价值。

function 应该将数据推送到数据存储或队列中，然后通过触发另一个 function 来完成其他的工作。

尽可能少在 function 中使用额外的库

这点对于我来说是显而易见的。

function 有冷启动（function 第一次启动）和暖启动（function 已经启动，并准备好被执行）两个阶段。冷启动受到很多因素的影响，比如 zip 文件的大小（或者被上传的代码）和需要实例化的库的数量。

代码越多，冷启动的速度就越慢。

需要实例化的库越多，冷启动的速度也就越慢。

例如，Java 在某些平台上算是一门实现暖启动的高性能语言。但如果你使用太多的库，你会发现它需要很多秒才能完成冷启动。有些库不是必需的，况且冷启动性能不仅会影响启动，还会影响伸缩。

我坚信开发人员应该只在必要的情况下才使用额外的库。

像 express 这样的东西是为服务器而生的，无服务器应用程序不需要用到它的所有元素。既然这样，为什么还要引入它的所有代码和依赖项呢？为什么要引入多余的代码？多余的代码不仅不会被运行，还会带来安全风险。

当然，如果一个库已经经过你的测试，而且你了解和信任它，那么就可以引入它。

避免使用基于连接的服务

除非真的有必要，否则不要使用基于连接的服务。

这个会让我陷入大麻烦。很多 Web 应用程序开发者都会陷入“我们只知道 RDBMS”的陷阱。

但重点不在于 RDBMS，而在于连接。

无服务器最适合与服务一起协作，而不是连接。

服务旨在快速对请求做出响应，并处理数据层的复杂性。这在无服务器领域具有巨大价值，也解释了为什么像 DynamoDB 这样的数据库非常适用于无服务器架构。

说实话，无服务器从业者并不反对 RDBMS，他们反对的是连接。连接需要时间，而且你试想一下，当一个 function 扩展到多个，每个 function 环境都需要一个连接，这样就给 function 冷启动引入了瓶颈和 I/O 等待，但其实这些是没有必要的。

如果你一定要使用 RDBMS，可以在中间放置一个连接池服务，如果是某种可以自动伸缩的容器，那就更好了。

关键是，你可能需要重新思考数据层，这不是无服务器的错。如果你尝试重用当前的数据层，但不奏效，那可能是因为你对无服务器架构缺乏理解。

一个路由对应一个 function

尽可能避免使用单一的 function 代理。它无法进行伸缩，也无助于隔离问题。在某些情况下，你可以使用单一的代理，例如：一系列路由功能被绑定到一个表上，并且它与应用程序的其余部分相对独立。但在我工作过的大多数应用程序中，这种情况只是个例。

虽然避免使用单一代理会增加管理方面的复杂性，但在扩展应用程序时，它确实有助于隔离错误。

话说回来，你会使用某种配置管理工具来运行这些东西，不是吗？你已经在使用某种 CI 和 CD 工具，对吗？所以，无服务器仍然需要 DevOps。

学习使用消息和队列

如果应用程序是异步的，无服务器往往会带来最佳的效果。对于那些倾向于进行请求响应和大量查询的 Web 应用程序来说，这可能不是很明显。

之前说过，最好不要让 function 直接调用其他的 function，所以如何将 function 链接在一起是一个很重要的问题。可以将队列作为断路器，如果一个 function 失效，只需要清空因为故障而堆积起来的队列，或者将失败的消息推送到死信队列（DLQ）。

基本上就是要了解分布式系统的工作原理。

对于带有无服务器后端的客户端应用程序，最好的方法是使用 CQRS。这个模式的关键之处在于将获取数据的关注点和输入数据的关注点分离开来。

数据流，而不是数据湖

在无服务器系统中，数据将流经你的系统。它们最终可能会形成数据湖，但更可能的情况是，它们会处于某种流动的状态。因此，任何时候都要将数据视为动态的，而不是静止的。

虽然这样做并非总是可行的，但一定要尽量避免在无服务器环境中查询数据湖。

无服务器要求你重新思考数据层。对于刚进入无服务器领域的新手来说，他们总是倾向于以 RDBMS 的方式考虑问题，他们极有可能会碰壁，不仅是因为伸缩问题，也因为他们的数据结构变得过于僵化。

你会发现数据流会随着应用程序的变化而发生变化，而伸缩将会改变所有的一切。如果你所要做的只是重定向一个数据流，那很容易，但要为数据库筑坝可是要难得多。

了解应用程序是如何伸缩的

创建第一个无服务器应用程序很容易，然后你看着它扩展。如果你不了解自己所做的一切，那么就很容易陷入与其他自动扩展方案相同的陷阱当中。

如果你不了解应用程序是如何伸缩的，有可能会让自己陷入麻烦之中。如果你使用缓慢的冷启动（依赖了很多库并使用了 RDBMS），然后碰上突发的高峰流量，就会急剧增加 function 的并发量，让连接数爆棚，从而拖慢了应用程序。

所以，不要认为应用程序一定会在相同的负载下运行。了解应用程序处于不同负载之下的行为仍然是工作内容的一部分。

结论

我可以在这里说更多的东西，不过以上这些是我在与其他人交谈时最想告诉他们的。我没有提到过如何规划应用程序，或者如何考虑应用程序的成本，因为它们超出了本文的讨论范围。我敢肯定，很多人会说我对 RDBMS 的看法是不对的。与容器一样，我并不讨厌 RDBMS，我只是喜欢在工作中使用对的工具。所以，先了解你的工具！

英文原文： https://medium.com/@PaulDJohnston/serverless-best-practices-b3c97d551535

感谢张婵对本文的审校。