认识达内从这里开始

随着互联网的不断发展，程序员在服务器架构和软件开发领域可以使用的方法和技巧也是越来越多了。今天，我们就一起来了解一下，无服务器架构都有哪些开发技巧。

不让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。这个模式的关键之处在于将获取数据的关注点和输入数据的关注点分离开来。

作者：PaulJohnston

译者：无明

节选：infoq

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。