高性能无服务器工程的6个最佳实践

18-11-20 banq
              

当你写下你的前几个lambdas时,性能是你最不想要的,你最关心的是权限,安全性,身份和访问管理(IAM)角色和触发器,这些都是为了进行“hello world”试用之后,让您的第一个无服务器能够部署正常运行。但是,一旦您的用户开始依赖您的lambdas提供的服务,就应该专注于高性能无服务器。

当您尝试生产高性能无服务器应用程序时,需要记住以下一些关键事项。

1.可观察性

无服务器处理扩展非常好。但随着规模与复杂性的相互作用,减速和错误是不可避免的。

可观察性不仅仅是日志记录或指标 - 这两者都是无服务器的。您可以深入了解云监视,以便在每次调用lambda时获取日志记录信息,并且AWS控制台提供了充分的方法来查看执行时间,内存使用和其他关键指标的平均值。

但是可观察性是我们如何从外部分析系统而不破解其内部结构。日志记录和指标都不能真正做到这一点,因为日志记录提供的信息太精细,无法告诉您如何处理请求,而度量标准只能指出问题的症状而不是其原因。该解决方案是真实的仪器,可以对跟踪信息进行采样,并为您提供一般和异常数据。

2.想想函数的请求路径

一旦触发一个函数lambda,就寻找各种信息,发出各种Web请求,检查配置文件,获取各种上下文,不要在一个函数中做太多事,注销这个被调用的lambda,寻找可实现你目标的函数。

3.不要重写您的代码

以下列出了常见的谎言:

  • “在迭代之前一定要制作一个数组的副本,改变副本会更有效”
  • “不要连接字符串,即使它只是两个字符串仍然加入一个数组,这将节省内存”
  • “全局变量的性能比良好的变量要糟糕得多”

所有这些都是由善意的人提供的,他们希望帮助人们编写更具性能的JavaScripts。所有这些都忽略了一个基本事实:  JavaScript是一种更高阶的语言。

可以通过减少必须执行的操作来改进程序:

  • 将多个请求组合到其他服务;
  • 当你有足够的匹配时就立即停止循环;
  • 返回有用的错误信息;
  • 失败优雅。

但除了这些最基本的最佳实践之外,重写代码并不是解决性能问题的方法

4.从本地开始

我认识的每个人在无服务器开发的早期都有类似的经历:当你的lambda开始做一些有点复杂的事情时,你会发现自己对你的配置和功能代码做了几十个小的调整。每次更改时,您都必须等待代码部署,然后堆栈的其余部分才能生效。而不是“保存,构建,刷新”,您的开发周期看起来更像是“保存,打开控制台,部署,等待,刷新,等待,刷新,等待,等待,刷新”

可以复制lambdas和API端点以及许多其他资源到本地docker容器中。

5.本地永远不会复制你的整个堆栈

要真正模拟无服务器流,您需要有一个堆栈来部署代码。

具体情况可能因团队规模而异,但基本上您需要某种阶段或测试版本的堆栈,您可以在其中测试我们的代码。

6.管理代码,而不是配置

创建YAML,管理你的堆栈。