线性资本成功募集5亿美元，王淮写下深情信
06-17
编者按：作者总结了他这五年来管理AWS无服务器应用的见解和经验。
其中大部分原理也适用于在“智智云”无服务器平台上操作小程序。
从 开始我就成为了 AWS 客户，在早期，我和 AWS 上的几乎所有其他人都花了很多时间来管理基础设施。
修补 AMI、配置负载均衡器、更新自动扩展配置等。
这是一项吃力不讨好的工作，直到出现问题之前，没有人关心！沃纳·沃格尔（Werner·沃格尔）经常将其定义为“无差别的苦差事”。
很长一段时间以来，我都希望有更好的方法。
当 AWS 在 re:Invent 上推出 Lambda 服务并随后与 .自 . 以来，我几乎一直致力于无服务器技术。
如今，我发现自己比以往任何时候都更有效率，而且我构建的系统也更加可靠、可扩展和安全。
然而，这不是免费的午餐，我必须犯很多错误，并在此过程中吸取很多教训。
毕竟，通过无服务器，您正在构建充分利用云的云原生应用程序。
为此，我们需要有效地使用 AWS 并开发有助于我们充分利用 AWS 所提供功能的工作方式。
在这篇文章中，让我与您分享我在过去五年中在生产中运行无服务器工作负载时学到的五个最重要的经验教训。
从第一天开始构建系统监控如果无法有效调试，就无法构建可靠的应用程序。
就是这么简单。
什么是系统监控（可观察性）？建筑系统监控（或“可观测性”）在过去几年中已成为一个流行词，对我来说，它是衡量系统内部状态从外部输出推断出来的程度的指标。
您知道，您能够如何及时了解云托管应用程序的最新动态吗？无服务器应用程序中的可观察性取决于您从中收集的外部输出的数量和质量：指标、日志、分布式跟踪等。
它决定了您分析和理解这些数据以识别行为模式、异常值和解决实时问题的程度。
日志记录被高估了不，日志记录和指标还不够。
事实上，我得出的结论是日志记录被高估了。
它们有其用途，但并不是解决问题的最有效方法。
特别是当您面临快速识别和解决问题的时间压力时，就像大多数生产中断的情况一样。
在最好的情况下，搜索堆积如山的日志消息就像大海捞针一样。
您必须应对一长串的挑战和决??策点：如何确保每个人都编写结构化日志？如何确保每个人都一致地记录数据，例如： 字段命名 要捕获哪些数据 - Lambda 调用有效负载、IO 调用的请求和响应正文、IO 调用的持续时间、异常消息和堆栈跟踪等。
我如何捕获和转发相关ID以便您可以轻松找到相关日志消息？例如，用户事务涉及通过事件链接在一起的多个 Lambda 函数。
使用什么日志聚合平台？如何从 CloudWatch 转发日志？如何在生产中对调试日志进行采样以控制 CloudWatch 成本？ AWS 客户在 CloudWatch 上的花费比 Lambda 上的花费多 10 倍是很常见的。
构建一个既经济高效又能有效帮助开发人员了解其应用程序发生的情况的日志记录解决方案需要花费大量的工作。
通常需要专门的“平台”团队来构建和拥有这些定制解决方案。
这些内部解决方案往往会带来与其解决的问题一样多的问题，并在组织协同中产生摩擦。
因为开发这些解决方案的人通常不需要每天使用它们，也不会经历修复系统故障的痛苦。
我自己也经历过，而且这种情况已经发生过很多次了...我的系统监控策略 今天，我使用以下组合： Lumigo 进行大部分调试和警报。
小但高价值的结构化日志可以覆盖 Lumigo 无法覆盖的盲点。
AWS 服务的 CloudWatch 指标和警报，例如 API Gateway 集成延迟或 DynamoDB 用户错误。
如果您想知道应该为无服务器应用程序设置哪些警报，请查看此博客文章。
该策略很容易设置并且非常有效。
这就是为什么。
Lumigo 具有内置警报，并与 Slack 或 PagerDuty 等工具集成。
结合我已有的 CloudWatch 警报，如果出现任何问题，我都会收到警报。
在微观层面上，如果我需要调查某个问题，很可能该问题已在 Lumigo 的问题页面中捕获。
所有最近的问题均按功能和错误类型进行组织。
Lumigo 开箱即用，可以捕获我推断应用程序内部状态所需的大部分信息：Lambda 调用事件。
Lambda 调用中存在的环境变量。
每个出站调用请求（例如，到另一个 AWS 服务）以及请求和响应消息正文的延迟。
失败调用的错误消息和堆栈跟踪。
这些使我能够深入了解应用程序内部发生的情况，因此我不需要自己记录太多内容。
因此，我倾向于编写日志的唯一时间是覆盖我在 Lumigo 中看不到的内容 - 当我的代码执行复杂的数据转换或业务逻辑时。
幸运的是，即使用户事务涉及多个 Lambda 函数，Lumigo 也会将我的日志与其他所有内容并排显示。
将所有这些信息集中在一处并且易于访问，可以更轻松地解决复杂的无服务器应用程序中的问题。
最好的部分是设置 Lumigo 只需几分钟，特别是如果您使用无服务器框架和无服务器 lumigo 插件。
无需手动配置，您即可获得大量开箱即用的功能。
在我这几年学到和采用的所有东西中，这个系统监控策略给了我在系统操作上最大的支持，帮助我成为一个更好的开发人员。
使用多个 AWS 账户 我可以教给您的第二个最重要的教训是：使用多个 AWS 账户。
理想情况下，每个环境的每个团队至少应使用一个帐户。
缓解 AWS 限制 AWS 服务有许多限制，有些是可调整的（也称为“软限制”），有些则不可调整（“硬限制”）。
但即使是软限制通常也有上限，例如一个区域中可以拥有的 IAM 角色数量。
某些限制会限制您帐户中可以拥有的资源数量。
例如，DynamoDB 表或 S3 存储桶的数量。
其他限制要求您的应用程序在某个区域可以处理的请求量。
例如，API Gateway 的默认限制是每个区域 10 个请求/秒，而 Lambda 的默认限制是每个区域并发执行数。
这些请求量限制可能会对应用程序的可扩展性产生很大影响，并且它们在不同区域之间可能存在很大差异。
因此，您需要了解您所在地区的局限性，并将其纳入您的建筑设计中。
如果您知道您的生产工作负载需要一定级别的访问请求，您应该主动要求 AWS 增加您的账户限制。
为不同的团队和环境拥有多个 AWS 账户将大大降低遇到这些限制的风险。
针对安全漏洞分区拥有多个帐户还可以充当防火墙，有助于在安全事件发生时安全地隔离它们。
例如，如果攻击者能够访问您的开发帐户之一，那么至少他们将无法访问您生产中的用户数据。
将团队和工作负载彼此隔离 每个团队每个环境都有一个帐户，使您可以将每个团队和环境与其他团队和环境隔离。
因此，您不会出现一个团队的服务使用过多吞吐量并导致其他团队的服务出现问题的情况。
如果一个团队拥有多个服务，您可能还希望将业务更关键或高吞吐量的服务隔离到他们自己的帐户中。
使用 org-formation 管理多个 AWS 计费账户 您可以使用 AWS Organizations 和 AWS Control Tower 来帮助您管理最终使用的所有 AWS 账户。
但是在Control Tower中，我发现控制台中有太多需要点击的东西。
虽然它具有帐户配置功能，可让您使用 CloudFormation 模板创建登录区域，但它也感觉有限。
无法在不同帐户中创建资源并在同一模板中引用它们。
毕竟，CloudFormation 是帐户级服务。
这就是为什么我更喜欢使用组织结构。
一种开源工具，可让您使用基础设施即代码来配置和管理整个 AWS 组织及其登录区域。
它使我能够在几个小时内自行设置复杂的 AWS 环境，而使用自定义脚本则需要团队花费几周的时间才能完成。
如果您对组织形成的工作原理感兴趣，请观看我们与它的创建者 Olaf Conijn 一起举办的网络研讨会。
在运行时安全地加载密钥当谈到无服务器应用程序的安全性时，有两个非常重要的主题需要讨论。
第一个是如何在运行时安全地存储和加载密钥。
此时，大多数 AWS 用户知道他们可以将其密钥放置在 SSM Parameter Store 或 Secrets Manager 中，并使用 AWS KMS 对其进行静态加密。
如果您想知道这两种服务有何不同，我还会在此 YouTube 视频中对它们进行比较。
许多人错误的地方在于如何保持这些密钥在运行时可用以供 Lambda 函数调用。
例如，如果您在无服务器框架中使用 ${ssm:…} 语法从 SSM Parameter Store 或 Secrets Manager 引用加密密钥，并将其分配给 Lambda 函数的环境变量。
在这种情况下，密钥将在部署期间解密，解密后的值将作为环境变量分配给 Lambda 函数。
这使您的代码可以在运行时轻松访问密钥。
但这也使得攻击者在发现漏洞时可以轻松访问系统，因为环境变量对他们来说是唾手可得的成果。
从历史上看，许多人将敏感数据放置在环境变量中，包括数据库连接字符串和 API 密钥。
这不仅限于无服务器，甚至不限于在云中运行的应用程序。
这个问题在软件工程的所有领域都普遍存在，许多攻击者瞄准并窃取环境变量中的信息。
我的经验法则是：永远不要将纯文本形式的密钥放入环境变量中。
相反，您应该从 SSM Parameter Store 或 Secrets Manager 获取密钥，并在冷启动期间在运行时对其进行解密。
为了避免在每次调用时重复调用这些服务，您还应该缓存解密的值（但不要缓存到环境变量中！）。
您还应该经常使缓存失效，以便您可以轮换密钥而无需重新部署函数。
对于 Node.js 功能，您可以使用 middy 中间件引擎通过内置 ssm 和 Secrets-manager 中间件来实现此目的。
而且只需要几行代码！ module.exports.handler = middy(async (event, context) = {… // 在上下文对象中使用秘密进行操作}).use(ssm({setToContext: true, // 将解密后的参数保存在“context”中objectcacheExpiry: 0, // 1 分钟后过期fetchData: {accessToken: /dev/service_name/access_token }})) 遵循“最小权限”原则 另一个重要的安全考虑因素是：您应该遵循最小权限原则并为您的 Lambda 提供函数提供最低限度的必要权限。
例如，如果您的函数需要将数据保存到 DynamoDB 表，只需授予其执行此操作的权限即可。
这可以说是减少安全隐患事件的爆炸半径所需要做的最重要的事情。
零信任网络 传统的网络安全方法侧重于网络周边的强化。
它监视进出网络的流量并阻止恶意行为者进入我们的网络。
但在网络内部，我们有一个完全可信的环境，任何节点都可以访问所有其他节点。
这里的风险是，一个受感染的节点会让攻击者访问我们的整个系统。
这使得我们的安全就像网络中最不安全的组件一样脆弱。
通过零信任网络，我们摆脱了旧观念，即网络上的每个人本质上都是值得信赖的，并且应该有权访问我们的所有数据。
相反，每个系统的每个请求都必须经过身份验证和授权。
这意味着，即使在我们的 AWS 环境中使用内部 API 来执行其他服务，我们仍然需要对这些请求进行身份验证。
幸运的是，我们可以通过 API Gateway 和 AWS_IAM 授权轻松做到这一点。
这可以保护内部 API 并确保调用者拥有访问它们所需的 IAM 权限。
您仍应使用 VPC（在有意义的情况下）并应用传统网络安全实践作为附加安全层。
但它们不应该是您抵御恶意流量的唯一防御措施。
优化冷启动 当谈到 Lambda 函数的性能时，首先想到的是冷启动。
好消息是，通过预配置并发，有一个本机解决方案可以在大多数情况下缓解冷启动。
我在这篇博文中广泛介绍了预置并发的用例，这是一个让我非常兴奋的功能，并且仍然很高兴能将其作为一个选项。
坏消息是，这不是免费的午餐，并且有其自身的缺点：在低流量场景中，使用预配置并发将显着增加您的 Lambda 成本，因为您要为正常运行时间和调用付费。
从可用区域并发度中减去预配置并发度（正如我们上面提到的，该并发度从大多数区域开始）。
这需要仔细的并发管理，以确保您有足够的并发性供其他功能根据需要进行扩展。
内置并发不适用于 $LATEST 别名，因此您可能必须使用自定义别名。
由于这些原因，预置并发最好被视为特定问题的解决方案，而不是默认情况下应使用的解决方案。
在我看来，您应该首先尝试优化 Lambda 函数的冷启动性能，使其处于可接受的参数范围内。
仅当这被证明不可行时，您才应考虑将预配置并发作为解决方案。
在这篇博文中，我探讨了三种提高 Lambda 性能的方法，包括一些有关如何改进 Lambda 冷启动的技巧： 删除不必要的依赖项。
较小的部署对象会导致更快的冷启动时间。
如果许多功能（在同一项目中）需要不同的依赖项，请考虑将它们分开打包，以便每个功能都有更小的部署对象。
对于 Node.js 函数，使用像 webpack 这样的捆绑器可以减少模块初始化时间（因为当您需要模块时它会删除许多系统 IO 调用）。
将您的依赖项放置在 Lambda 层中。
但这是为了优化部署，不要使用 Lambda 层作为包管理器（这就是原因）。
这些技巧并非我原创，您之前可能已经听过其中的许多观点。
它们可能很无聊，但很有效。
如果完成所有这些还不够，请考虑使用预配置并发！以下是我从在生产中运行无服务器中学到的五个最重要的经验教训： 从一开始就考虑系统监控（可观察性）。
使用多个 AWS 账户。
不要将纯文本形式的密钥放入环境变量中。
遵循“最小特权”原则。
监控和优化 Lambda 冷启动性能。
其中许多经验教训适用于在 AWS 中运行的任何应用程序，而不仅仅是无服务器应用程序。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-18
06-21
06-17
06-17
06-17
06-21
06-18
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态