无服务器最佳实践

该Serverless无服务器最佳实践认为：无服务器是继承事件驱动EDA和异步编程范式，其实是一系列FaaS函数服务和队列的序列。对于一个后端是无服务器的应用，最好的架构是参考CQRS。

这些无服务器的最佳实践主要针对大规模和突发性工作负载而不是相对较低的水平，因此很多这些最佳实践来自规模角度，例如零售中的Nordstrom和物联网中的iRobot。如果你的目标不是那么远，那么你可能无需遵循这些最佳实践。

每个函数应该只做一件事

这是关于功能错误和规模缩放的隔离。

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

许多教程和框架推荐在基于单个代理路由情况下，编制一整块大的函数并使用switch语句。我不喜欢这种模式。它不能很好地扩展，并且往往会产生大而复杂的功能。

如果你的Web应用程序中有一部分接受一百万次调用，有一部分可以接受1千次调用，则必须两者分离，否则的话你无法轻易地优化千次调用的代码，将它们分开。这里有很多价值。

函数不会调用其他函数

调用其他函数的函数是反模式。函数应该将数据推送到数据存储或队列，如果需要更多工作，则应该触发另一个函数。

在函数中使用尽可能少的库（最好为零）

函数具有冷启动（当第一次启动函数时）和热启动（它已经启动，并且准备好从温池执行）。冷启动受到许多因素的影响，但是zip文件的大小（或者代码被上传）是其中的一部分。此外，需要实例化的库的数量。

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

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

例如，Java在一些平台上的热情开始是一种出色的高性能语言。但是如果你使用大量的库，你会发现它需要很多秒才能冷启动。你几乎肯定不需要它们，冷启动性能不仅会阻碍启动，也会阻碍扩展。

作为另一点，我非常相信开发人员只在必要时使用库，这意味着从无，从无结束，除非我无法构建没有需要的东西。

像express这样的东西是为服务器构建的，无服务器应用程序不需要这个东西的所有元素。那么为什么要介绍所有的代码和依赖？为什么要带来多余的代码？它不仅仅是永远无法运行的东西，但它可能带来安全风险。

这是最佳实践的原因有很多。当然，如果有一个你已经测试，知道和信任的库，那么绝对要把它带进来，但关键元素是测试，了解和信任代码。遵循教程，是不一样的。

避免使用基于连接的服务，例如RDBMS​​​​​​​

只是不要，除非你必须。

这个会让我陷入最大的麻烦。很多网络应用程序的人都会跳上“但RDBMS是我们大家都掌握的知识”这趟潮流列车。

我谈的不是关于RDBMS，而是关于连接。

无服务器最适合服务而不是连接。

服务旨在快速返回对请求的响应，并处理服务背后的数据层的复杂性。这在无服务器空间中具有巨大价值，并且为什么像DynamoDB这样的东西在无服务器范例中非常适合。

说实话，无服务器的人不反对RDBMS，他们反对连接。连接需要时间，如果您想象一个功能扩展，每个功能环境都需要一个连接，并且您在功能的冷启动中引入了瓶颈和I / O等待。这是不必要的。

因此，如果您必须使用RDBMS，但是放置一个处理中间连接池的服务，可能只是处理一些描述的自动缩放容器会很好。

这里要做的最重要的一点是，无服务器架构可能需要您重新考虑数据层。这不是无服务器的错。如果您尝试重用当前的数据层思维并且它不起作用，则可能缺乏对无服务器架构的理解。

每个路由一个功能（如果使用HTTP）

尽可能避免使用单一功能代理。它不能很好地扩展，也无助于隔离问题。在某些情况下，您可以避免这种情况，例如，一系列路由的功能严格地绑定到单个表，并且它与应用程序的其余部分非常分离，但这是我工作的大多数应用程序中的边缘情况在。

这增加了管理方面的复杂性，但在应用程序扩展时，它确实有助于隔离错误和问题。从你的意思开始吧。

但是，你使用某种配置管理 工具 来运行一切都不是你吗？你已经使用了某种CI和CD工具吗？你仍然需要无服务器的DevOps。

学习使用消息和队列（异步FTW）​​​​​​​

当应用程序异步时，无服务器应用程序往往效果最佳。对于那些倾向于进行请求 - 响应和大量查询的Web应用程序来说，这种方式并不是直截了当的。

回到”不调用其他函数的函数“这个主题，重要的是要指出这是将函数链接在一起的方式。队列在链接方案中充当断路器，因此，如果功能失败，您可以轻松地排空由于故障而备份的队列，或者将失败的消息推送到死信队列。

了解分布式系统的工作原理。

对于一个后端是无服务器的应用程序，最好的架构是参考CQRS 。从输入数据的角度分离检索数据的点是这种模式的关键。

数据流，而不是数据湖​​​​​​​

在无服务器系统中，您的数据流经您的系统。它可能最终存在于数据湖中，但可能的是，虽然它位于无服务器系统中，但却处于某种流动状态。因此，请将所有数据视为动态，而不是在任何时候休息。

并非总是可行，但尽量避免在无服务器环境中查询数据湖。

无服务器要求您显着重新考虑数据层。这是最新的问题，新人们无法服务于无服务器，他们倾向于达到RDBMS而且不会因为缩放问题而将其淘汰，但他们的数据结构变得过于僵化。

您将发现您的流程将随着您的应用程序更改而更改，并且比例将更改所有内容。如果你所要做的就是重定向一个流程，这很容易。湖泊更加困难。

只是为了缩放编码是一个错误，你必须考虑它如何扩展

创建第一个无服务器应用程序非常容易，并且可以扩展它。如果您不了解自己已完成的工作，那么您可以轻松陷入其他所有自动扩展解决方案的陷阱。

如果您不考虑您的应用程序以及它将如何扩展，那么您可以自行解决问题。如果你使用缓慢的冷启动（例如许多库并使用RDBMS）然后获得高峰使用率，你最终可能会显着增加函数的并发性，然后最大化你的连接，并减慢你的应用程序下。

所以，不要只是将一个应用程序放入无服务器，然后想象它将在各种负载下工作运行是相同的。了解不同负载下的应用程序表现仍然是你的工作的一部分。