初探 Lambda Powertools TypeScript
声明：
本文转自 DEV Community 网站，文章翻译由开发者社区提供；
点击下方链接，查看英文原文：
2022 年 1 月 5 日，AWS 高级解决方案架构师 Sara Gerion 宣布，Lambda Powertools TypeScript 已经进入公开测试阶段。Lambda Powertools 是一个由 AWS 赞助的开源项目，旨在使用 AWS Lambda 时优化开发人员的体验并采用最佳实践。Lambda Powertools TypeScript 加入了 Java 和 Python Lambda Powertools 库。
目录
Node.js Tooling for Lambda
我是 TypeScript 的忠实粉丝，实际上我还与他人合著了一本关于 TypeScript 的书。我不常用 Java 或 Python，所以，虽然我对 Lambda Powertools 很感兴趣，但直到现在我才开始尝试使用。Lambda Powertools TypeScript、middy 和 DAZN Lambda Powertools 都是运行 Node.js 的 Lambda 工具。
Lambda Powertools TypeScript 与同类库的两点区别在于，前者是由 AWS 赞助的，并且支持 decorator。
Lambda Powertools TypeScript 同时支持 JavaScript AWS SDK v2 和 v3 版本，两个版本的例子都会给出。
Decorators
大家对 decorator 的看法不一，但我认为它们是有用的抽象，并且在面向对象的 TypeScript 中大量使用。然而，在 TypeScript 中有一个相当大的制约因素，那就是 decorator 可以放在类方法上，但不能放在函数上。这意味着，像这样的代码目前还无法实现。
这一点很遗憾，因为它能提供很好的开发者体验。为了将 doSomethingGreat decorator 添加到我们的处理程序上，我们需要写一些像下面的代码。
这是额外的五行代码，或许不是什么大问题。不管怎样，Powertools 团队能做的不多，因为在函数支持 decorator 之前可能还要等上几年。请记住，如果我们选择在 Lambda 中使用 decorator 和类，我们需要谨慎参考这个文件。
（如果不使用 deno）Lambda 中不支持 decorator 和 TypeScript，所以如果要运行 decorator 和 TypeScript，我们还需要一个转译步骤。幸运的是，对于 AWS CDK、AWS SAM 和无服务器框架的用户来说，这个问题已经基本解决。如果你打算或需要推出自己的 decorator 和 TypeScript，esbuild 是一个很好的开始，似乎是首选的 bundler。
不使用 Decorators
我们不妨选择不使用类或转码器。Lambda Powertools TypeScript 可以不使用 decorator，事实上也不需要 TypeScript。我们可以通过 vanilla Node.js 使用该库。
Lambda Powertools TypeScript 文档非常好，里面提供了几个例子，GitHub 上还有更多例子。
功能
三个版本的 Lambda Powertools 都将 Metrics、Logger 和 Tracer 作为核心工具。Lambda Powertools Python 包含一个 Event Handler 和其他一些有用的工具，支持批量处理、无效性、验证等。
Lambda Powertools 的每个版本都是独立开发的，其功能是根据不同运行时间的不同需求而定制的。区别在于，AWS CDK 使用 jsii 向多个运行时间发布相同的结构。虽然等待某些功能可能会令人沮丧，但这就是正确的做法，因为如果将通用代码编译成可以装饰多个运行时间的自定义代码，只会增加复杂性。
为了进行测试，我在一个样本项目中实施了 Lambda Powertools TypeScript 的所有三个实用程序。我选择了 CDK Async Testing 项目，因为它包含若干个 Lambda 函数，以及通过 EventBridge 和 Step Functions 的异步工作流。
可以点击此处查看我的 instrument 代码。
Tracer
为了通过 Tracer 来 instrument 我的函数，我需要将它们重写为类。我选择了使用 decorator，因为我还没有决定是否要全部使用类，所以我需要摸索一下。我从 collect.ts 开始，以下是该函数初始的 11 行代码。
下是为了包括 Tracer 而进行的重构。
该函数现在有 25 行代码，这并不可怕。加入 Metrics 和 Logger 工具后，最终变为 33 行。当然，我的函数会更大，因为它拥有更多的功能。我们应该把这种增加看作是加法，而不是乘法。我的 11 行代码函数变成了 25 行。如果它最初有 111 行，它就会增加到 125 行，而不是翻倍。
那么，结果如何呢？Tracer 模块封装了 AWS X-Ray SDK（作为横向的依赖关系）。它并没有增加任何新的功能，而是使 SDK 更易使用。根据我的经验，这个 SDK 的使用有些麻烦，所以这么做是非常值得的。我们可以装饰类方法，在一行代码中引入新的跟踪段。我们还可以使用命令的形式在我们认为合适的地方添加新的跟踪。我们可以捕获 AWS 客户端，但这会暴露 X-Ray SDK。
还有一点没有解决，那就是使用 X-Ray SDK 和 DynamoDB DocumentClient 时比较怪异。在使用 DocumentClient 和 X-Ray 时，我们需要稍作变通，因为 SDK 需要访问 DocumentClient 服务属性，但这并没有在类型上反映出来。以下是我解决这个问题的方法。
更新! 这个问题在 0.5.0 版本中已经解决了! 上面的代码现在可以这样写：
非常感谢这个迅速的改进! 现在我的 DX 变得更好了，以下是我的应用。
原始文本
我不仅获得了非常棒的服务图，还有详细的跟踪。
Tracer 模块正在添加这些截图上的 ##index.handler 部分。我想增加更多的跟踪来更好地利用这个工具。总的来说，通过所有功能和服务获得应用程序的这些详细的跟踪是相当令人印象深刻的，也是非常有用的。大部分工作由 X-Ray 完成，但更好的开发者体验意味着我们要 instrument 更多的应用程序，这当然是一件好事。
在这里我想说的是，跟踪也包括日志，instrument 程序段的日志位于 CloudWatch 中的跟踪。
这一点也很棒。我能够以分布式的方式、使用单一用途的函数编写应用程序代码，但能够在执行程序时掌控全局。
只要我们在高吞吐量的应用上设置一个取样率，X-Ray 服务的价格就会很低。定价似乎是基于跟踪，所以在跟踪中增加额外的代码段并不会增加成本。
Logger
Logger 工具可以直接替代任何记录器，包括控制台。Logger 的附加价值在于能够将 Lambda 上下文注入到所以日志信息中。当我们用 @logger.injectLambdaContext() 给 handler method 加注释，然后使用 logger.info，我们会看到如下的日志消息：
如果我们计划将日志提取至搜索索引，或者如果只是想使用 CloudWatch Logs Insights，这真的很方便，因为该结构有助于我们搜索和过滤日志信息。另一方面，如果我们只是查阅少量日志信息，则可能会有点繁杂。我们应该记住，任何日志服务（包括 CloudWatch）都要按量计费，极其冗长的日志成本会很高昂。
考虑到这一点，Logger 工具有很多不错的功能，我们可以随心所欲地构建日志。此外，Logger 还包括一个取样率功能，用于降低费用。
默认情况下，记录器方法需要一个或多个参数。第一个参数是一个字符串或带有消息键的对象。我发现，如果我将一个字符串作为后续参数，那么这个字符串就会被转换成一个字符数组并被打印出来，所以这一点需要注意。
Metrics
Metrics 工具的用途是发布自定义 CloudWatch 指标。尽管 Lambda 会自动发布一些有用的指标，比如延迟、并发执行、节流等，但自定义指标可以在指标中添加相关的业务事件，实现可观察性。
追踪可靠性非常重要，但它并不代表全部！自定义指标应该是最重要的指标。这周有多少客户进行注册？其中有多少人能够完成有价值的工作流？这些问题的答案就在代码中，如果我们发出自定义指标，它们也会出现在我们的仪表盘中。
自定义指标的定价结构可能非常昂贵。嵌入式指标格式有助于管理成本，并且是由 Lambda Powertools TypeScript 支持。此文档也很明确，不需要我过多阐述。让我们来看看实际体验。我给 collectionSuccess 函数添加了一个 "collectionSuccess "的自定义指标。在我假设的应用程序中，会催收部分付款，在这里我标记出催收能否实现支付。
添加 @metrics.logMetrics 会使我们发出的任何指标都被记录到 CloudWatch。（考虑到成本）我们可能希望，也可能不希望这样。要添加一个自定义指标，我们只需使用 metrics.addMetric。
我对我的应用进行了 instrument，以发射冷启动指标，以及其他描述应用中重要事件的自定义指标，例如成功/失败的支付/催收。由于我的应用的重点是展示集成测试，所以我还设置了自定义指标，以显示测试的运行时间。
这些指标可以在 CloudWatch Metrics 中找到，位于仪表盘或通过 API 导出到第三方工具。
Package Size
在项目中添加的所有工具增加的容量，未压缩是 600kb，压缩后是 200kb。考虑到其价值以及将部分依赖性链接到 AWS SDK 或 X-Ray SDK 中的需要，这似乎很合理，而且该团队在贯彻其精益宗旨方面做得很好。
总结
Lambda Powertools 将重点放在了开发者真正需要的工具方面，能够优化应用并遵循最佳实践。其中的核心模块都专注于可观察性，这一点是必须的，也是值得赞赏的。该团队开发出的 API，无论是对于使用 decorator 的开发者，还是不使用 decorator 的开发者都具有吸引力。
我希望这个库能够尽快普及，我会关注路线图，跟进后续进展，并参与进来。
文章作者：Matt Morgan
Matt Morgan for AWS Community Builders
还未添加个人签名 2019.09.17 加入
还未添加个人简介
评论