导读

你是否想充分利用无服务器架构的全部威力来处理生产工作负载？你是否在思考事件如何帮助你的应用程序实现扩展？你是否一直在尝试调优应用程序以获得更高的性能和更低的成本？本次会话将提供架构最佳实践、优化方法和实用技巧，专家可以利用这些来构建安全、高度可扩展和高性能的无服务器应用程序。

演讲精华

以下是小编为您整理的本次演讲的精华。

应用程序开发的未来是一个无需人工干预即可无缝运行、轻松适应需求波动的世界。这就是无服务器计算的现实，这种范式彻底改变了软件构建和交付的方式。欢迎来到无服务器开发人员的最佳实践世界，这是一个创新与效率融合，创造真正非凡体验的领域。

无服务器计算的演进可以追溯到2006年S3和SQS等服务的推出，远远早于EC2等虚拟机租赁服务的出现。这些早期产品为按需付费模式奠定了基础，基础设施管理不再是一个问题。然而，直到2014年Lambda的推出，无服务器革命才真正点燃。有了Lambda，开发人员只需将代码上传到云端，亚马逊云科技就会安全地大规模运行它，确保高可用性和无缝执行。

与Lambda的兴起同步的是同年ECS和Fargate的推出，使开发人员能够轻松运行和管理无服务器容器。这标志着无服务器之旅的一个重要里程碑，因为开发人员现在可以利用容器的强大功能，而无需承担基础设施管理的开销。

从那时起，无服务器领域呈指数级增长，涵盖计算、存储、工作流、数据库、分析等各种服务。无服务器产品的激增还得益于众多合作伙伴的贡献，确保开发人员能够获得满足特定需求的最佳工具。

无服务器技术的客户采用范围广泛，跨越行业，包括初创公司、企业、政府等各个领域。无服务器的吸引力在于它能够促进快速迭代和将想法迅速交付给客户，从而改变软件开发和部署的方式。

云中无服务器计算的一个非凡之处在于，它能够持续改进而无需人工干预。例如，EventBridge服务经历了显著增强，将交付延迟降低了高达94%。这一看似微不足道的变化，开启了全新的可能性，实现了以前无法企及的事件驱动架构。

例如，考虑一个需要从云端后端及时获取更新的外卖移动应用程序。传统上，前端需要同步调用多个后端服务来检索订单信息，由于重复轮询，这个过程可能会阻塞和昂贵。然而，借助EventBridge降低的延迟，现在可以将后端服务的状态更新异步路由到前端，消除了拉取的需求，确保了无缝的用户体验。

这种新发现的能力是通过EventBridge、AppSync和WebSockets之间的最新集成实现的。一种方法是使用GraphQL将事件异步路由到AppSync，GraphQL是一种强大的工具，可以聚合数据并确保客户端只接收所需的信息。或者，开发人员可以利用新的AppSync Events API，它允许轻松将事件传递到一个简单的Web Socket发布/订阅主题，而无需了解GraphQL。

这种降低的延迟所带来的影响远远超出了移动应用程序。它开启了快速、异步、事件驱动架构的新领域，可以彻底改变应用程序的设计和开发方式。可能性真正是无穷无尽的。

随着无服务器领域的不断发展，一种新的范式出现了:“有服务器的无服务器”方法。这种方法主张将应用程序组件迁移到独立的托管服务中，利用它们的本地功能，并尽量减少所需的代码量。通过这种方式，开发人员可以将非差异化的繁重工作卸载给亚马逊云科技，让他们专注于交付价值，同时受益于这些托管服务提供的弹性、可扩展性和安全性。

“有服务器的无服务器”方法的一个关键优势是能够有效扩展应用程序。通过将单体代码库拆分为更小的面向服务的组件，开发人员可以利用每个服务的本地功能，例如API网关中的缓存、路由和授权。这种模块化方法不仅提高了可扩展性，而且还促进了针对每个特定任务使用最佳服务，确保了最佳性能和效率。

随着应用程序变得更加分布式，有效的通信模型变得至关重要。在这种情况下，编排和编排就成为了互补的方法。编排(如Step Functions)采用中央协调器来管理服务的交互和使用顺序。而编排(如EventBridge)则依赖于去中心化模型，事件在服务之间自由流动，触发反应而无需严格的中央控制。

许多应用程序都同时利用了编排和编排，根据具体用例量身定制方法。Step Functions在需要严格顺序和工作流管理的场景中表现出色，而EventBridge在需要事件自由流动而无需中央协调器约束的情况下更为出色。

“有服务器的无服务器”方法的一个关键好处是减少代码量的机会。在Lambda开发中，一种常见模式是捕获DynamoDB更改事件并在下游处理它们。然而，通过引入EventBridge Pipes，开发人员可以完全消除对Lambda函数的需求。通过配置一个管道从DynamoDB读取并指定API目标参数，EventBridge Pipes会自动处理事件传递、读取重试和身份验证，从而解放开发人员免于安全补丁和维护的负担。

同样，Step Functions也提供了通过直接SDK集成和使用JSON.nata来消除代码的机会。通过直接在Step Functions中实现业务逻辑，开发人员可以消除对Lambda函数的需求，降低成本和复杂性，同时保持所需的功能。

无服务器范式还应用于生成式人工智能(gen AI)领域。许多gen AI应用程序可以利用与其他领域类似的工作流和架构。其中一个例子是工具使用，也称为函数调用，其中一个现有工具被注册到gen AI代理。在这种情况下，gen AI模型解析一个自然语言提示，例如为某种汽车品牌和轮胎更换安排预约。然后，该模型确定哪个已注册的工具可以提供所需信息，生成适当的JSON负载，并查询相关的库存数据库。

Step Functions可以通过注册可用工具、将自然语言提示发送到语言模型以及根据模型响应调用适当的API来协调这一过程。结果可以存储起来，并发出事件以触发其他服务中的反应，通过工作流和事件的结合实现有效的微服务通信。

虽然“有服务器的无服务器”方法提供了诸多好处，但构建生产就绪的无服务器服务需要仔细考虑弹性、可观察性、安全性和治理。弹性是一个关键方面，因为正如Werner Vogels所说，“一切都会一直失败”。为了确保弹性，开发人员必须实现死信队列和具有指数退避的重试机制等机制。

在一个由SQS队列、轮询该队列的Lambda函数以及将项目插入S3存储桶的简单无服务器服务中，如果缺乏弹性措施，可能会导致数据丢失。如果Lambda函数遇到问题(如bug或S3暂时不可用)，整个批次项目都会失败，并且Lambda服务会重复重试该函数，直到保留期到期，从而导致数据丢失。

为了缓解这种风险，开发人员可以引入死信队列。在配置的失败次数后，项目会被移动到死信队列，防止进一步重试并保留数据。此模式的最佳实践包括使用10个项目的批量大小(最大批量大小以获得最佳吞吐量)、将可见性超时设置为至少函数超时的6倍以应对失败和限制、在移动到死信队列之前定义至少5次的最大接收计数，以及为死信队列设置更长的消息保留期。

一旦项目进入死信队列，就可以实施重新驱动机制来促进重新处理。这种机制通常涉及一个事件调度程序，它定期调用一个Lambda函数，该函数调用一个API将项目从死信队列移回原始SQS队列进行重新处理。这种方法的最佳实践包括确保只有可重试的失败(如节流或可修复的bug)才会被移动到死信队列、将死信队列保留期设置为比重新驱动cron作业频率长，以及考虑项目效力以确保任何副作用都是原子性的。

在 Lambda 函数本身中，开发人员可以利用 Power Tools for Amazon Lambda 库来实现批处理和处理部分失败。这个开源库提供了一系列生产就绪的实用程序，包括批处理、输入验证和错误处理。通过使用 Power Tools 批处理处理器，开发人员可以遍历一批项目，使用 Pydantic 模型执行输入验证，并为每个项目调用记录处理程序函数。如果在处理过程中发生异常，Power Tools 会自动将该项目标记为部分失败，并继续处理下一个项目，确保整个批次不会因单个失败而丢失。

可观察性是生产就绪的无服务器服务的另一个关键方面。它实现了整个组织的统一语言，允许团队跨多个服务调试客户请求。可观察性包括 CloudWatch Logs、CloudWatch 指标、X-Ray 跟踪、CloudWatch 仪表板和警报。

为了有效地记录日志，开发人员应该采用结构化的 JSON 日志记录，这允许在 CloudWatch 控制台中轻松过滤和查询。建议在所有日志中包含关联 ID 和客户 ID，而不仅仅是错误日志，以便跨多个服务端到端跟踪客户请求。为了管理与日志存储相关的成本，开发人员可以将默认日志级别设置为“info”，并将“debug”级别保留用于更详细的日志记录，仔细考虑哪些日志真正提供了有价值的信息。

CloudWatch 指标和警报可以洞察服务的性能，并在客户受到影响之前向开发人员发出潜在问题的警报。在 SQS-Lambda-S3 服务的上下文中，相关指标包括从 SQS 删除的消息数量(如果该值为零，则表示潜在失败)、死信队列中可见的大约消息数量(在短时间内大量消息可能表示失败)、Lambda 节流、未捕获的异常以及产品团队为监控服务关键绩效指标和功能采用而定义的自定义指标。

Amazon X-Ray 提供了一个强大的工具，用于了解服务内部的瓶颈和性能特征。通过分析 X-Ray 跟踪，开发人员可以识别总体函数时间、初始化时间以及单个 API 调用的性能，从而实现针对性的优化。

CloudWatch 仪表板将可观察性元素整合到一个视图中，使监控和故障排除变得更加容易。开发人员应该考虑创建两种类型的仪表板:一种是高级仪表板，供消防队或产品团队快速分类;另一种是低级仪表板，用于深入分析指标和日志。

Power Tools for Amazon Lambda 简化了将可观察性功能集成到 Lambda 函数的过程。开发人员可以初始化日志记录器、跟踪器和自定义 CloudWatch 指标处理程序，并为特定函数添加装饰器以跟踪其执行时间并发出自定义指标，例如成功写入 S3 存储桶的项目数量。

安全性是 亚马逊云科技 及其客户之间的共同责任，亚马逊云科技 负责云的安全性，而客户则负责云内的安全性，包括他们的业务域逻辑代码和基础设施配置。确保无服务器服务安全的最佳实践包括对静态数据和传输中的数据进行加密、阻止公共访问私有资源以及审计对客户数据的访问。

在 SQS-Lambda-S3 服务中使用的 S3 存储桶的上下文中，开发人员可以通过阻止公共访问、附加访问日志存储桶、启用加密(使用 S3 托管密钥或客户托管密钥)以及强制执行 SSL 通信来增强安全性。这些配置可以使用基础设施即代码工具(如 亚马逊云科技 Cloud Development Kit (CDK))来实现，确保跨部署时安全措施的一致性和可重复性。

Governance 是生产就绪的无服务器服务的另一个关键方面，通常由 IT 和 DevOps 团队通过诸如 Amazon Config、Amazon Control Tower、亚马逊云科技 Organizations Service Control Policies (SCPs) 和最近推出的 Resource Access Manager (RAM) 等工具进行管理。开发人员应该了解治理实践，例如使用堆栈标签来标识服务、宏服务和团队，这可以帮助跨多个团队和账户进行成本归属和资源管理。

在部署之前进行自动化安全扫描也是推荐的做法，利用开源工具如 CDK Nag 或 CFN Lint 来识别和防止错误配置和安全问题。

虽然弹性、可观察性、安全性和治理的原则对于构建生产就绪的无服务器服务至关重要，但是在整个组织中扩展这些最佳实践可能是一项艰巨的任务，尤其是在处理数百个服务时。为了解决这一挑战，Ran Eisenberg 引入了服务蓝图和架构模式的概念。

服务蓝图是 GitHub 存储库，其中包含最小的无服务器服务实现，可作为开发人员的起点。这些蓝图封装了弹性、安全性、可观察性和治理的最佳实践，减轻了认知负担，让开发人员可以专注于编写业务域逻辑。例如，在 Cybric，开发了一个 CRUD API 蓝图，包括 API Gateway、Lambda 和 DynamoDB，内置了 CI/CD 管道、基础设施即代码以及部署和监控功能。

为了促进服务蓝图的共享和发现，Ran 创建了开源的“Awesome 亚马逊云科技 Serverless Blueprints”存储库，这是一个社区贡献的无服务器服务蓝图集合，涵盖了各种后端服务、CI/CD 管道、基础设施即代码语言和编程语言。我们鼓励开发人员探索这个存储库，找到合适的蓝图，并贡献自己的变体，以促进协作和知识共享。

另一方面，架构模式是可重用的模块，封装了无服务器架构中特定功能或组件的最佳实践。这些模式不包含业务域逻辑，可以轻松集成到多个服务中，促进整个组织的一致性和最佳实践的遵循。

在 SQS-Lambda-S3 服务的上下文中，可以识别出两种架构模式:死信队列和重驱动机制，以及 Lambda 函数内的批处理和部分失败处理。这些模式可以被提取并打包为可重用的 CDK 构造或 Terraform 模板，允许开发人员在不必从头实现底层逻辑的情况下将它们集成到自己的服务中。

Ran 提供了几个发现和利用架构模式的资源，包括 亚马逊云科技 Solutions Constructs 库，它提供了一系列可重用的常见用例模式。

除了服务蓝图和架构模式之外，Ran 还分享了构建生产就绪 Lambda 函数的一些技巧。他建议采用一种文件夹结构，将服务代码、测试和基础设施即代码组件分开，实现明确的关注点分离，并促进开发人员和 DevOps 团队之间的协作。

采用六边形架构，将处理程序、业务逻辑和数据访问层分开，可以进一步促进代码组织和可维护性。处理程序层负责输入验证和全局初始化，逻辑层封装业务域逻辑，数据访问层提供了对具体数据库实现的抽象。

Power Tools for Amazon Lambda 为各种语言(包括 Python、Java、Node.js 和 .NET)提供了一套全面的实用程序，简化了数据提取、流式处理、缓存和功能标记等任务。Ran 演示了如何利用 Power Tools 在 Lambda 函数中实现输入验证、批处理和可观察性功能。

性能调优是构建高效 Lambda 函数的另一个关键方面。通过增加配置的内存分配，开发人员可以获得相应的 CPU 和网络吞吐量的增加。但是，重要的是要确保代码是多线程的，以充分利用超过单核性能阈值(约 1.8 GB 内存)的额外 CPU 资源。

Ran 还介绍了 Lambda Power Tuning，这是一个开源工具，可以跨多个配置调用 Lambda 函数并生成性能成本图，使开发人员能够确定执行时间和成本之间的最佳平衡。

保持运行时的最新状态是提高性能和安全性的一个简单而有效的做法。正如 Julian Wood 所指出的，亚马逊云科技 不断更新托管运行时的底层操作系统和库，升级函数运行时通常可以带来显著的性能提升，同时确保应用了最新的安全补丁。

为了促进运行时升级，可以利用 Amazon CodeGuru 的代码转换功能。CodeGuru 已成功在几天内将数千个 Java 8 应用程序转换为 Java 17，自动化了依赖管理、框架更新和安全最佳实践实现等任务。

尽管无服务器(serverless)领域已经经历了重大演进，但前景依然光明。亚马逊云科技不断努力改善开发人员体验、治理控制和扩展集成能力。最近推出的新 Lambda 控制台具有类似 Visual Studio Code 的功能，Amazon Toolkit for Visual Studio Code 的应用程序构建器，以及 Step Functions 和 EventBridge 的私有 API 集成，都证明了亚马逊云科技致力于简化开发人员体验。

此外，亚马逊云科技正在积极增强治理能力，推出了诸如最近引入的Kafka预配置模式，该模式抽象了网络复杂性，并实现了高效处理流数据。随着无服务器生态系统不断成熟，开发人员可以期待更加无缝和更广泛的集成，从而能够构建真正创新和可扩展的应用程序。

总之，无服务器计算带来了应用程序开发范式的转变，使开发人员能够专注于交付价值，同时将无差异的繁重工作卸载到托管服务。通过采用弹性、可观察性、安全性和治理的最佳实践，并利用服务蓝图、架构模式和 Power Tools for Amazon Lambda 等工具和框架，组织可以跨数百种服务扩展其无服务器最佳实践，促进一致性、效率和创新。无服务器计算的未来前景光明，亚马逊云科技将继续为开发人员提供构建真正非凡应用程序所需的工具和能力。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。