本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

考虑使用无服务器 .NET

概述

无服务器计算已成为构建和部署应用程序的一种常用方式。这主要是因为无服务器方法在构建现代架构时所提供的可扩展性和敏捷性。但是，在某些情况下，考虑无服务器计算的成本影响也是很重要的。

Lambda 是一个无服务器计算平台，它能让开发者无需使用专用服务器即可运行代码。对于那些希望降低基础设施成本的 .NET 开发人员来说，Lambda 是一个极具吸引力的选择。借助 Lambda，.NET 开发人员能够开发并部署具有高度可扩展性且可能具有成本效益的应用程序。通过采用无服务器方法，开发人员不再需要为处理应用程序请求而预调配服务器。相反，开发人员可以创建那些按需执行的函数。这使得无服务器架构在可扩展性、可管理性以及潜在的成本效益方面都优于运行、管理和扩展虚拟机的方式。因此，您只需为应用程序所使用的资源付费，而无需担心资源未充分利用的情况或服务器维护费用。

开发人员可以使用现代的跨平台 .NET 版本来构建运行速度快、效率高且成本效益好的无服务器应用程序。.NET Core 及其更新版本是一个免费且开源的框架，相较于之前的 .NET Framework 版本，它更适合在无服务器平台上运行。这使得开发人员能够缩短开发时间并提高应用程序的性能。现代 .NET 还支持一系列编程语言，包括 C# 和 F#。因此，对于那些希望在云中构建现代化架构的开发者来说，这是一个颇具吸引力的选择。

本部分介绍如何通过将 Lambda 作为无服务器选项来实现成本节省。您可以通过微调 Lambda 函数的执行配置文件、调整您的 Lambda 函数的内存分配大小、使用原生 AOT 以及迁移到函数来进一步优化成本。 Graviton-based

成本影响

您可以降低多少成本取决于多个因素，包括您的无服务器函数将执行多少次以及分配的内存量和每个函数的持续时间。 AWS Lambda 提供免费套餐，包括每月 100 万个免费请求和每月 400,000 GB 秒的计算时间。您可以显著降低超出或接近这些免费套餐限制范围的工作负载所产生的每月费用。

使用以 Lambda 函数为目标的负载均衡器时，可能还会产生额外费用。这是根据负载均衡器针对 Lambda 目标处理的数据量计算得出的。

成本优化建议

调整您的 Lambda 函数的大小

正确调整大小是成本优化的基本做法。 NET-basedLambda 函数。这一过程包括确定既能保证性能又能兼顾成本效益的最优内存配置，且无需对代码进行任何更改。

通过为 Lambda 函数配置内存（范围从 128MB 到 10240MB 不等），您还可以调整调用时可用的 vCPU 数量。这使内存或 CPU-bound 应用程序能够在执行期间访问额外的资源，从而有可能缩短调用持续时间和总体成本。

但是，请确定最适合您的配置。 NET-based Lambda 函数可能是一个手动且耗时的过程，尤其是在频繁更改的情况下。AWS Lambda Power Tuning 工具能够通过将一组内存配置与示例有效载荷进行对比分析，帮助您确定合适的配置。

例如，增加 a 的内存。 NET-based Lambda 函数可以在不影响性能的情况下缩短总调用时间并降低成本。函数的最佳内存配置可能有所不同。 AWS Lambda Power Tuning 工具可以帮助确定每项功能的最具成本效益的配置。

在下面的示例图表中，对于此 Lambda 函数而言，总调用时间随着内存的增加而缩短。这可以降低总执行成本，同时又不影响该函数的原有性能。对于此函数，其最佳内存配置为 512MB，因为在此配置下，每次调用的资源利用率在总成本方面最为高效。这因函数而异，而通过在您的 Lambda 函数中使用该工具，可以确定这些函数受益于大小调整。

我们建议您定期完成此项操作，将其作为发布新更新时进行集成测试的一部分。如果更新频率较低，请定期进行此项练习，以确保函数得到优化和调整。确定了 Lambda 函数的合适内存设置之后，就可以对您的进程添加大小调整。 AWS Lambda Power Tuning 工具会生成编程输出，供您的 CI/CD工作流程在新代码发布期间使用。这使您能够自动进行内存配置。

您可以免费下载 AWS Lambda Power Tuning 工具。有关如何使用该工具的说明，请参阅中的如何执行状态机 GitHub。

Lambda 还支持原生 AOT，它支持对 .NET 应用程序进行预先编译。这可以通过缩短 .NET 函数的执行时间来降低成本。有关创建本机 AOT 函数的更多信息，请参阅 Lambda 文档中的使用本机 AOT 编译的 .NET 函数。

避免闲置等待时间

Lambda 函数持续时间是用于计算账单的一个维度。当函数代码发出阻止调用时，将根据它等待接收响应的时间向您计费。当 Lambda 函数链接在一起时，或者函数充当其他函数的编排工具时，此等待时间可能会增加。如果您有诸如批处理操作或订单交付系统之类的工作流，将会增加管理开销。此外，可能无法在 Lambda 的最大超时时间 15 分钟内完成所有工作流逻辑和错误处理。

与其在函数代码中处理此逻辑，我们建议您重新构建解决方案，以将 AWS Step Functions 用作工作流的编排工具。使用标准工作流时，将为工作流中的每个状态转换向您计费，而不是工作流的总持续时间。此外，您可以将对重试的支持、等待条件、错误工作流和回调移至状态条件中，以便您的 Lambda 函数专注于业务逻辑。有关更多信息，请参阅 AWS Compute 博客中的优化 AWS Lambda 成本 — 第 2 部分。

移至 Graviton-based 函数

由下一代 Graviton2 处理器提供支持的 Lambda 函数现已全面推出。Graviton2功能采用 ARM-based 处理器架构，旨在将各种无服务器工作负载的性能提高多达19％，成本降低20％。凭借更低的延迟和更出色的性能，由 Graviton2 处理器提供支持的函数非常适合为任务关键型无服务器应用程序提供支持。

对于希望优化 Graviton-based Lambda 成本的.NET 开发人员来说，迁移到 Lambda 函数可能是一个经济实惠的选择。 Graviton-based 函数使用 ARM-based 处理器而不是传统的 x86 处理器。这能够带来显著的成本节省，同时又不会影响性能。

虽然迁移到 Graviton-based 功能有很多好处，但我们建议您考虑一些挑战和注意事项。例如， Graviton-based 函数需要使用 Amazon Linux 2，它可能无法与所有.NET 应用程序兼容。此外，可能存在与第三方库的兼容性问题或与 ARM-based 处理器不兼容的依赖关系。

如果您正在运行 .NET Framework 应用程序，并希望利用 Lambda 实现无服务器，那么您可以考虑使用 Porting Assistant for .NET 将这些应用程序迁移到现代的 .NET 环境中。这将有助于您将遗留的 .NET 应用程序快速移植到现代的 .NET 环境中，从而使该应用程序能够在 Linux 上运行。

下图比较了计算素数的函数的 x86 和 ARM/Graviton2 架构结果。

该函数使用的是单线程。当内存配置为 1.8GB 时，两种架构的最短运行时间均被报告出来。除此之外，Lambda 函数可以使用超过 1 个 vCPU，但在这种情况下，该函数无法利用这些额外的计算能力。出于同样的原因，在内存最高达到 1.8GB 时，成本保持稳定。随着内存容量的增加，成本也会随之上升，因为此工作负载没有任何额外的性能益处。Graviton2 处理器显然在这一计算密集型函数方面提供了更高的性能和更低的成本。

要配置要使用 Graviton 的函数和 ARM-based 处理器，请执行以下操作：

其他资源