41、AWS 云架构优化与 Serverless 实践指南

最新推荐文章于 2025-12-05 03:37:20 发布

dapp9builder

最新推荐文章于 2025-12-05 03:37:20 发布

阅读量45

点赞数

CC 4.0 BY-SA版权

分类专栏：解码无服务器架构真谛文章标签： AWS Connect Customer Profiles Salesforce

本文链接：https://blog.youkuaiyun.com/dapp9builder/article/details/152721661

解码无服务器架构真谛专栏收录该内容

45 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

AWS 云架构优化与 Serverless 实践指南

1. AWS Connect 与客户信息整合

AWS Connect Customer Profiles 能够整合来自不同来源的客户信息，其中包括 Salesforce 或 Zendesk 等第三方应用程序。整合后的信息会显示在统一的仪表板中，让我们可以查看与来电者的所有过往交互。当发起呼叫时，Customer Profiles 会扫描电话号码或客户 ID，并自动为座席检索客户资料。

此外，Connect 还提供可视化仪表板和分析功能，以支持管理人员分析平均排队放弃时间和平均通话时长等趋势。管理人员可以利用这些信息，做出基于数据的决策，从而提高座席的工作效率和客户体验。

2. AWS 良好架构框架概述

AWS 良好架构框架是 AWS 开发的一套重要指南，旨在帮助云架构师构建高度安全、有弹性且高效的解决方案。该框架为架构师和客户提供了一种一致的方法，用于根据经过验证的解决方案和 AWS 架构师进行的深入研究，评估他们现有的架构。

这个框架始于 2012 年亚马逊发布的一份白皮书，随着时间的推移，它获得了广泛的欢迎，亚马逊也不断对其进行扩展和改进。如今，它包括特定领域的版本、实践实验室以及 AWS 良好架构工具，以指导用户完成评估过程。

2017 年，AWS 通过引入“透镜”（Lenses）的概念扩展了该框架，以提供更具针对性的工作负载建议。透镜将 AWS 架构指导扩展到更多特定行业领域，如无服务器计算、高性能计算、物联网（IoT）和金融服务等。需要注意的是，透镜并非独立存在，它们应与良好架构框架一起使用。

架构师和组织可以将该框架及其工具应用于自己的解决方案，顾问也可以将其应用于客户的解决方案。

2.1 良好架构框架的五大支柱

支柱	描述	关键领域
卓越运营	专注于系统监控，以增加业务价值并持续改进流程	变更自动化、事件响应、日常运营标准定义
安全	充当信息和系统的守门人	数据完整性和隐私、权限管理识别、系统保护、安全事件检测流程建立
可靠性	确保工作负载正确、高效地运行	分布式系统设计、恢复计划、变更处理
性能效率	强调明智地使用 IT 和计算资源	选择合适的资源类型和大小、性能监控、根据业务需求做出明智决策
成本优化	专注于消除不必要的成本	了解和控制资金支出、选择合适数量和类型的资源、在不过度支出的情况下扩展资源

2.2 设计原则

基于五大支柱，良好架构框架确定了一组六项通用设计原则，有助于确保在云中采用良好的设计实践：
1. 停止猜测容量需求 ：云计算中的容量规划挑战较小，我们可以自动进行资源的扩展或缩减，避免为闲置资源付费或因容量有限而导致性能下降。
2. 对生产规模的系统进行测试 ：可以在云中创建生产规模的临时测试环境，测试完成后删除资源以避免持续收费。运行临时测试环境的成本仅为在本地进行实时测试成本的一小部分。
3. 自动化以简化架构实验 ：自动化有助于以较低成本复制工作负载，并减少手动操作。在云计算和无服务器解决方案中，跟踪自动化变更、审核影响以及在需要时恢复到先前设置都非常简单。
4. 支持架构的演进 ：传统物理基础设施由于成本和时间限制，架构决策难以快速演进。但在基于云的无服务器解决方案中，自动化、按需测试以及蓝绿部署和金丝雀部署等策略成为了变革性因素。它们允许系统快速演进，而不会影响底层资源，同时企业能够从创新中受益。
5. 基于数据驱动架构 ：在云中很容易收集有关架构选择如何影响工作负载的数据，这意味着我们可以做出基于事实的选择，而不是基于假设的选择。由于云基础设施本质上就是代码，我们可以跟踪架构选择并随时间进行改进。
6. 通过游戏日进行改进 ：安排游戏日是模拟实时事件以测试架构和流程有效性的好方法。这有助于识别基础设施中的薄弱环节，并提高组织在处理突发事件时的应对能力。

2.3 使用 AWS 良好架构框架的原因

快速构建和部署 ：该框架有助于构建强大可靠的基础设施，使团队能够更快地创建和部署应用程序。
降低风险 ：按照良好架构框架的指南定期对整个云账户进行评估，有机会评估并主动修复任何错误、安全漏洞或潜在威胁。
做出明智决策 ：由于框架提供了合理且经过时间考验的建议，我们可以做出明智的基础设施决策，而不是凭猜测行事。
学习和实施 AWS 最佳实践 ：框架为云架构师提供了最佳实践，正确遵循这些实践可以确保基础设施和系统的稳定与安全。

2.4 AWS 良好架构工具

AWS 良好架构工具是 AWS 提供的一项免费服务，可以从 AWS 管理控制台访问。它是一种定期评估工作负载、识别高风险问题并记录改进措施的好方法。客户填写一份表格后，亚马逊会根据良好架构框架的五大核心支柱，为他们的基础设施提供建议和潜在风险评估。

该工具的使用步骤如下：
1. 从控制台启动 AWS 良好架构工具网页，导航到“定义工作负载”，填写工作负载的基本信息，包括行业类型、区域和环境，然后再次点击“定义工作负载”。
2. 工具将对当前基础设施进行系统的工作负载审查。根据我们的需求，我们可以选择配置支柱优先级，使建议与对我们最重要的支柱保持一致。
3. 完成审查后，将根据预先定义的工作负载选择和支柱优先级生成一份 PDF 报告。
4. 分析报告后，我们可以返回工作负载选项卡，点击改进计划以获取针对我们工作负载的建议。

2.5 无服务器透镜及其层

无服务器应用透镜是对良好架构框架的一种扩展，使其更适用于无服务器应用程序。与支柱类似，透镜包含相关属性的层次结构。以下是无服务器透镜各层的概述：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(无服务器透镜):::process --> B(计算层):::process
    A --> C(数据层):::process
    A --> D(流和消息层):::process
    A --> E(用户身份和管理层):::process
    A --> F(边缘层):::process
    A --> G(监控和部署层):::process

计算层 ：负责管理来自外部系统的工作负载请求，并控制请求的访问和正确授权。该层包括 Lambda、API Gateway 和 Step Functions 等应用程序。
数据层 ：负责管理持久存储，并提供一种安全的机制来存储业务逻辑所需的状态。它还能根据数据变化触发事件。这里包含 DynamoDB、DynamoDB Streams 和 DynamoDB Accelerator 等数据库应用程序，以及 S3、Elasticsearch Service 和 AppSync 等基于存储和分析的应用程序。
流和消息层 ：消息层促进工作负载不同组件之间的通信，流层提供对流式数据的实时分析和处理。SQS、SNS、Kinesis 和 Kinesis Data Firehose 等应用程序在这些层中运行。
用户身份和管理层 ：专注于工作负载用户的身份识别、认证和授权。Cognito 和 Federated Identities 等应用程序属于该层。
边缘层 ：连接外部客户，能够将数据高效地交付到不同地理位置的客户手中。Snowball Edge、CloudFront 和 Greengrass 等应用程序位于该层。
监控和部署层 ：监控层通过指标持续检查系统并观察其随时间的行为，部署层通过发布过程管理变更。CloudWatch 和 X-Ray 等工具属于该层。

任何关心构建可靠、安全、可扩展且有弹性的 AWS 云基础设施的组织，都应努力遵循良好架构框架。通过实施该框架中的最佳实践和指南，我们可以确保应用程序的持续改进，并提供高质量的解决方案。

3. Serverless 实践技巧

3.1 文件上传

将文件上传到由 Lambda 支持的 REST API 的一种方法是将文件编码为 Base64，并像传递其他参数一样将其放在 POST 或 PUT 请求体中。不过，API Gateway 和 Lambda 限制请求大小为 6 MB，考虑到 Base64 编码需要 1.5 MB，实际留给文件数据的空间略超过 4.5 MB。这对于大多数标准单图像上传可能足够，但对于高分辨率图像、多图像、视频、可视化 PDF 文件等需求则不够。此前提到的解决方案是使用 S3 预签名 URL。

3.2 缓存层的应用

Lambda 常见的用例之一是自动生成缩略图，在许多 Serverless 教程中，通常有以下两种实现方式：
1. S3 触发 Lambda ：S3 为每个新上传的文件触发一个 Lambda，输出变体通常无限期存储在 S3 上。如果各种尺寸是预定义的，并且必须应用于每个新图像，这种方法效果很好。但这可能导致不必要的处理和存储可能永远不会使用的图像变体。
2. 按需动态生成 ：通过 API Gateway 将用户请求路由到 Lambda 按需动态生成图像。这种方法可以支持自定义尺寸，并确保只生成请求的尺寸。问题是结果会通过 API Gateway 立即返回，不会存储任何内容。频繁请求的图像会为每个请求再次生成，这会增加请求的显著延迟，使解决方案感觉缓慢。

更好的方法是结合上述两种方法，并使用 CloudFront CDN 添加缓存层。CloudFront 配置为从 S3 拉取请求的内容呈现给用户，然后在 AWS 网络上靠近该用户的地理位置存储或缓存一段时间，以便后续请求可以更快地得到响应。当文件一段时间未被请求时，它将自动从缓存中删除。下次请求过期文件时，它将再次从 S3 源检索。

CloudFront 有一个名为源故障转移的功能，本质上是一个备用源，如果在主源上找不到文件，CloudFront 将从该备用源请求文件。我们可以将故障转移源配置为我们的 API 端点和 Lambda 微服务，该微服务将生成缩略图。Lambda 微服务将输出存储在 S3 上，并在单个请求中返回给 CloudFront。因为我们有重新生成图像变体的选项，所以我们可以在 S3 源上设置生命周期策略，自动删除超过一定年龄或在给定时间段内未被请求的变体。

这样，我们可以最大限度地减少不必要的数据存储，仍然可以为可能已过期的变体提供服务请求，可以通过 CloudFront 快速为常用变体提供服务请求，并在需要时支持生成自定义变体。

3.3 多语言支持

在全球化的世界中，并非每个人都是英语母语者，因此为微服务和 UI 添加 i18n 支持是很重要的。有一些库可以相对容易地实现这一点，一旦养成习惯，其实并不会增加太多工作。这不仅使将来支持多种语言变得更容易，还使编辑和改进解决方案的书面内容变得更加容易。

3.4 使用 TypeScript

如果你是 JavaScript 开发者，建议切换到 TypeScript。它会让你的生活更轻松，代码更优秀，解决方案更具可扩展性、可读性和可移植性。Python 也很棒，特别是在与其他语言的互操作性和数据科学活动方面。但在许多 Web 应用程序和 API 使用案例中，编译为 JavaScript 的编写良好的 TypeScript 通常比 Python 运行得更快。

3.5 选择合适的工具

3.6 使用 Cognito 作为用户数据库

Cognito 是一个安全的服务，用于存储用户登录信息。如果我们将所有个人身份信息保存在 Cognito 用户池中，并使用 ID（在 Cognito 中称为“sub”）从其他数据库和服务中引用它，它可以帮助满足 GDPR 和其他隐私合规要求。使用 Cognito，我们只需为给定月份的活跃用户付费，因此停止使用的测试账户不会产生费用。

以下是有效使用 Cognito 的一些提示：
1. 按 sub 检索用户 ：使用 listUsers 函数和 Filter 参数，通过用户的 sub 而不是用户名从 Cognito 检索用户：

cognito.listUsers({
    UserPoolId: process.env.userpool,
    Filter: 'sub="'+user_id+'"'
}).promise()
.then(users => {})
.catch(error => {});

使用标准配置文件参数 ：访问和使用标准配置文件参数时，不要将它们设置为必需项。将标准参数设置为必需项可能会导致社交媒体集成等方面出现问题，因此最好避免在 Cognito 中进行此配置，而是在应用程序中处理参数验证。我们可以为 Cognito 配置文件添加最多 50 个自定义属性，每个属性值最多可包含 2048 字节的数据。
管理用户访问 ：一种管理用户访问的方法是在 Cognito 中包含一个 JSON 策略文档作为自定义参数。该策略包含在 Cognito 令牌中，因此如果我们通过 API Gateway 请求在事件中传递它（使用集成映射），则可以在 Web 应用程序前端和 Lambda 微服务中访问它。在前端，该策略可用于确定向用户显示哪些菜单和页面；在后端，它可用于确定用户是否应访问特定的微服务和操作。
首次登录查询 Lambda ：自 2022 年 6 月起，Cognito 可以在用户首次登录时查询 Lambda，并将权限和其他用户信息添加到 Cognito 会话中。这避免了单个 Lambda 函数查询数据库以检索用户信息和权限的需要，大大减少了请求和延迟。
处理密码导出问题 ：Cognito 不允许导出密码，这在进行一些配置更改需要重新创建 Cognito 用户池时会带来问题，使迁移现有用户变得有点困难。一种方法是先使用所需的设置创建新的 Cognito 用户池，然后在一段时间内，当用户登录现有用户池时收集他们的密码。收集到每个密码后，在新的 Cognito 用户池中创建完整的用户账户，包括密码。收集期结束后，导入剩余没有密码的用户，并将应用程序切换到新的用户池。这些剩余用户需要重置密码，但我们至少可以避免让更活跃的用户这样做。
多组织用户管理 ：如果应用程序使用多个组织，每个组织都有自己的用户，我们可以为每个组织创建一个 Cognito 用户池，但这可能会变得相当复杂。相反，我们可以使用一个不需要的标准属性，如“family_name”来存储组织 ID。使用 listUsers 中的 Filter 选项，我们可以检索属于该组织的所有用户：

cognito.listUsers({
    UserPoolId: process.env.userpool,
    Filter: 'family_name="'+organisation_id+'"'
}).promise()
.then(users => {})
.catch(error => {});