什么是AWS Lambda？
AWS Lambda是一种无服务器计算的服务，也被称为功能即服务（FaaS）。它使用户能够按需运行功能，并通过云服务事件或API手动调用这些功能。通过Lambda，用户可以按需访问基础设施，不需要配置资源或维护硬件。此外，Lambda向用户收取所使用的计算能力，不需要承担额外的责任。
Lambda的常见用例包括。
- 实时数据处理
- 提取、转换、加载（ETL）过程
- 应用程序、网站和物联网（IoT）后端
AWS Lambda是如何工作的？
在Lambda中，你可以用你选择的语言创建函数。该服务原生支持最常见的语言，并为整合任何非原生语言、框架或库提供Runtime API。一旦你的函数准备好了，它就会与配置和资源需求信息一起被打包。然后，这个包会根据需要被触发。
当Lambda函数被调用时，每个函数都在一个单独的容器中运行，该容器在由AWS维护的多租户机器集群上运行。这使你可以同时运行一个函数的多个实例。它也使你能够同时运行几个不同的功能。
当使用Lambda功能时，你不需要负责任何基础设施的维护或管理。你可以控制你的个人功能和触发器，以及分配的计算能力、带宽和I/O。
AWS Lambda的挑战和解决方案
Lambda可以为你的无服务器需求提供一个很好的解决方案，但该服务并非没有挑战。以下是你可能面临的一些最常见的挑战和一些可以应用的解决方案。
提高冷启动性能
当需要为一个功能的运行创建一个新的容器实例时，就会造成冷启动。当函数执行之间有很长的权重期时就会发生这种情况，导致容器被杀死。对AWS来说，为每一个可能的功能维护活跃的容器实例是不符合资源效率的，所以只有那些活跃的功能才是活的。
提高Lambda的冷启动性能是你可以在第三方工具的帮助下，对你的做法做一些修改。例如，用更快的加载语言编写函数，以减少启动时间。然而，你最好的选择是尝试减少冷启动的频率。
减少频率的一个方法是为你的函数安排Ping事件。这可以确保一个函数在达到空闲限制（大约30分钟）之前被重新激活。然而，在这样做时，要注意不要太频繁地ping你的函数。这样做可能会延迟函数的执行时间，从而抵消了通过保持函数活力而获得的性能。
监控和记录
像所有的服务和实现一样，你需要能够监控你的Lambda函数，以确保你得到你需要的性能。如果没有监控，就很难或不可能确定函数是否按照你的要求被触发。要确定你的资源需求是否被正确定义也是一个挑战。然而，对于Lambda，你不能像使用实例那样依赖持久性日志或监控代理。
相反，你需要依靠发送到AWS CloudWatch的指标和日志。这项服务收集性能和运行时数据，你可以直接访问或用第三方解决方案摄取。你还可以使用X-Ray服务进行应用追踪。结合起来，这些服务应该可以帮助你识别大多数问题。
调试
如果你的功能没有按照预期运行，调试并不总是直接的。例如，如果你需要按时间顺序查看多个执行的日志，那么查看来自CloudWatch的日志就很有挑战性。此外，无服务器架构和服务的分布式性质可能会使你难以确定问题的源头。
解决这些问题的方法之一是确保在上传到Lambda之前正确调试你的函数。这有助于确保不是函数本身出了问题。它还可以帮助你缩小任何相关服务的问题。
你可以用你的默认工具进行这种调试，或者你可以使用AWS无服务器应用模型（SAM）CLI中的调试模式。你也可以在本地运行SAM，或者通过工具包与你的集成开发环境（IDE）集成。工具包可用于JetBrains、PyCharm、IntelliJ和Visual Studio Code IDEs。
避免超时
Lambda超时值决定了一个函数在被服务终止之前可以运行多长时间。这些值可以防止函数因逻辑错误或响应问题而导致运行时间超过预期或无限期。Lambda函数可以运行的最长时间是5分钟。任何超过这个时间的都违背了FaaS的目的和成本节约。
除了与函数大小或复杂性有关的问题外，在Lambda函数中还可能遇到其他几种超时问题。这些包括。
- 亚马逊API网关相关的超时-有一个29秒的集成超时限制。这个限制适用于所有集成，包括Lambda、HTTP、AWS服务和代理。如果你经常看到API相关的超时，你应该检查下游的瓶颈问题。
- 与内存有关的低超时--当你创建函数时，你指定资源要求。如果你定义的要求对于你的实际需求来说太低，你的函数可能会超时。你可以通过检查日志中的
MemorySetInMB和MemoryUsedInMB值来检查低内存是否是你超时的原因。如果这些值经常接近或使用值较高，考虑增加你在函数中定义的内存要求。 - 虚拟私有云（VPC）相关的超时--应避免运行连接到VPC中外部服务的Lambda函数。这是因为请求不能通过互联网路由，导致没有响应。虽然有解决的办法，但这需要高级的网络技能，而且往往不值得花额外的精力去设置连接。
总结
作为一种无服务器服务，Lambda确实不需要在配置和硬件上花费时间和资源。然而，它仍然需要工作来排除性能问题。也许最著名的问题是Lambda的冷启动性能，这可能很难优化和排除故障，但通过ping功能和与第三方的整合，有可能取得良好的效果。
你还应该注意避免超时，这可能是由于函数大小限制、API错误配置、低内存和VPC造成的。如果你设置了一个有效的监控和记录周期，你可以跟踪函数的性能问题并及时应用修复。但是，由于Lambda的调试可能很复杂，你最好的行动方案也许是预防。因此，请确保你的初始配置是坚实的，并监测具体问题。对常见的问题进行监控可以为你节省大量的时间来调查问题的来源。
The post4 Tips for Solambda Performance Issuesappeared first onDevOps Conference.
