内存与成本之间的平衡
在Lambda里，内存和CPU息息相关，也就是说，如果您增加了内存，那么CPU分配也应该有所增加。因此，如果需要减少Lambda的执行时间，那么我们就应当增加内存和CPU。但是，如果您进行过详细的实验就会发现：在一定的限制情况下，单凭增加内存只会增加购置成本，而并不会大幅减少执行的时间。
目前市面上很少有开源的工具，能够帮助我们找到最佳的资源配置。我个人倾向使用CloudWatch的各种日志，来监控内存的使用情况和执行时间，进而调整相应的配置。对内存进行参数微调，便可对AWS的整体成本产生较大的影响，我籍此来找到最佳平衡点。
性能 - 冷启动与热启动
当我们第一次调用Lambda时，它会从S3那里下载代码和所有依赖项，以创建容器，并在执行代码之前先启动对应的应用程序。整个过程的耗时（代码的执行除外）被称为冷启动时间。而一旦容器被启动并运行起来后，Lambda就已经为后续的调用完成了初始化，它只需要执行应用程序的逻辑便可。因此，这段时长就被称为热启动时间。
那么问题来了，我们应该缩短冷启动时间、还是热启动时间呢？原则上说，作为完整执行时长的一部分，冷启动占据了大部分时间，因此需要想办法予以减少。但是，在实践中，我们却可以通过优质的代码，来减少热启动的时间。
下面，让我们讨论如何才能提高Lambda的整体性能：
l 选择诸如Nodejs和Python之类的解释性语言，而不是Java或C ++，来减少冷启动时间。
l 如果出于某种原因不得不选用Java的话，请使用Spring Cloud Functions，而不是Spring Boot Web框架。
l 由于我们设置ENI的耗时较长、并且会增加冷启动时间，因此除非您需要带有专有IP地址的VPC资源，否则请使用默认的网络环境。我个人判读：随着新版AWS Lambda的即将发布，此方面应该有所改进。
l 删除所有与运行该函数无关的依赖项。仅保留那些必需的。
l 使用各种全局/静态变量、以及Singleton对象，这些变量能够在容器发生故障之前，一直保持活动状态。因此，任何后续调用都不必再重新初始化这些变量与对象了。
l 请使用全局定义的数据库连接，以便它们能够被重用到后续的调用中。
l 如果您选用的是Java，那么请使用诸如Dagger和Guice之类的简单IoC依赖注入，而不是Spring框架。
l 同样，如果您选用了Java，那么请将依赖项.jar文件与函数的代码相分离，以便对解包程序加速。
l 如果您选用的是Nodejs，请控制Function js文件的体积小于600字符，并使用V8的运行环境（runtime）。V8优化器能够内联主体小于600字符（包括各种注释）的函数。
l 同样，如果您选用了Nodejs，则可以使用代码的minification和/或uglification，来减小包的大小，进而大幅减少下载包的耗时。在某些情况下，我曾经看到有将包的体积从10MB减少到1MB的案例。
n Minification – 会删除掉所有的空格、换行符、以及注释。
n Uglification – 会对所有变量进行混淆和简化。
示例，原代码：
var organizationname = “xyz”
var bigArray = [1,2,3,4,5,6]
//write some code
for(var index = 0; index < 6; index++){
console.log(bigArray[index]);
}
Minification之后：
var organizationname = “xyz”, bigArray = [1,2,3,4,5,6] for(var index = 0; index < 6; index++) console.log(bigArray[index]);
Uglification之后：
for(var o=”myname”,a=[1,2,3,4,5,6],e=0;e<6;e++)console.log(a)
网上有不少的文章都提到：Lambda的执行环境已经具有了适用于Nodejs和Python的AWS SDK。因此，我们不必在依赖项中添加它们。此特性虽然有利于提高性能，但是潜藏着一个问题：该SDK库将定期使用最新的修补程序来进行升级，为了不影响Lambda的各种行为，您最好采用自己的依赖项管理方式。
安全性
l 为每个函数分配一个IAM角色。即使有多个函数需要相同的IAM策略，单个IAM角色也应该只映射一个函数。当特定的函数安全策略需要加固时，这将有助于保持最小权限的策略。
l 由于Lambda会在共享的VPC上运行，因此将AWS的凭据保留在代码中并不可取。
n 在大多数情况下，IAM的执行角色已足以通过使用AWS SDK，去连接到AWS的各种服务。
n 如果函数需要调用跨帐户的服务，则可能会使用到不同的凭据。因此我们需要在AWS的Security Token Service（请参见https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html）中使用Assume Role API，并检索各种临时凭据。
n 如果函数需要存储长期凭据（如DB凭据、访问密钥），请使用带有加密助手或AWS System Manager的环境变量。
可测性
由于AWS Lambda让用户的代码运行在云端，那么我们该如何在本地进行测试呢？
虽然Lambda并不提供任何直接测试的URL，但是我们可以根据要启动的事件源系统来开展测试。
l 我们可以使用AWS SAM（请参见https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html）进行Lambda函数的本地测试。它为CLI提供了类似本地Lambda的执行环境。我们可以获得API Gateway的localhost URL，它会在本地调用Lambda函数。
l 我们可以使用localstack（请参见https://github.com/localstack/localstack）开源项目，来创建具有大量AWS资源/服务的本地环境。它可以与其他AWS服务一起运行Lambda。而且由于它能够以API的形式提供所有的服务，并能够在后端作为Docker容器运行，因此您也可以将AWS SAM与localstack相集成。
l 将业务逻辑放到Lambda Handler之外。Handler函数应当仅用于检索各项输入，然后将它们传递给其他函数/方法。这些函数/方法会将它们解析成为与我们的应用程序相关的变量，然后进一步使用。该过程不但实现了将业务逻辑与处理程序相分离，而且可以在我们创建的对象和函数的上下文中进行测试。
蓝/绿部署
通过Lambda附带的Versioning和Alias功能，我们可以发布一个函数的多个版本。同时，我们可以在单独的容器中并行地调用每个版本。默认情况下，版本特征是由$LATEST来表示的。在开发的过程中，我们可以使用这些版本，来创建诸如dev/UAT等多个环境。但是，由于我们在每一次上传新的代码时，版本都会递增，而客户则会被指向最新的版本。因此，我们最好不要直接将Versioning用于生产环境，而可以用到Alias。
Alias可以指向函数的某个特定版本。因此，如果您的代码发生了更改，并且发布了更新的版本时，事件源仍将指向原来相同的Alias。我们只需管理好Alias何时需要被指向新的版本便可。这便实现了蓝/绿部署。我们可以使用一些样本事件来测试新的版本，确认其工作正常之后，再通过修改Alias的指向，来切换访问的流量。与此同时，如果发现出现任何问题，我们还可以迅速回滚到原始的版本上。
监控
个人以为：CloudWatch能够很好地与Lambda配合使用，并为用户提供Lambda执行的各种详细信息。Lambda能够自动跟踪请求数、每个请求的执行时间、导致错误的请求数、以及发布相关的CloudWatch指标。同时，您也可以利用这些指标，来自定义各种CloudWatch的警报功能。
另外，我们还可以使用X-Ray来识别Lambda执行中的各种潜在瓶颈。它对于我们试图可视化那些耗费在函数执行上的时间，是非常实用的。而且，X-Ray还有助于跟踪那些与整个流程相连接的所有下游系统。
其他建议
l 请勿使用AWS Lambda Console开发那些直接被用在生产环境中的代码。
n 由于代码版本控制并非自动生效的，因此如果您误点了Save按钮，那么生产环境中的工作代码就会被永久覆盖掉。
n 它并没有与GitHub、或其他代码存储库相集成。
n 它无法被导入AWS SDK之外的模块中。因此，如果您需要某种特定的库，则必须从一开始就在本地开发自己的函数、创建.zip文件、然后将其上传到AWS Lambda中。
l 请使用AWS SAM或无服务器框架来进行开发。
l 就Lambda部署的CI/CD计划而言，它其实与其他可交付式的计划并无不同。
l 可使用各种环境变量（Environment Variables）和参数存储（Parameter Store），来将代码与配置相分离。
总结
在本文中，我们讨论了在设计和部署Lambda时，各种值得参考和使用的最佳实践。我们可以根据实际应用的编码语言和用例，来不断改进业务系统的性能。当然，我们也可以在其他的云平台，以及Kubernetes的无服务器平台中借鉴这些最佳实践。希望您能够将这些实践总结运用到自己成熟的生产环境与应用之中。
【原标题】AWS Lambda Best Practices (作者：Rajesh Bhojwani )
原文链接：https://dzone.com/articles/aws-Lambda-best-practices
