38、AWS 架构技术全解析：从 Step Functions 到容器应用

最新推荐文章于 2025-10-20 14:23:57 发布

dapp9builder

最新推荐文章于 2025-10-20 14:23:57 发布

阅读量44

点赞数

CC 4.0 BY-SA版权

分类专栏：解码无服务器架构真谛文章标签： AWS Step Functions 事件驱动架构

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

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

45 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

AWS 架构技术全解析：从 Step Functions 到容器应用

1. Step Functions 概述

Step Functions 支持自动重试、消息数据转换、延迟与等待、死信队列和通知等功能。此外，它还具备手动请求步骤以获取批准，以及并行运行进程、等待响应并将其合并为单个响应对象的能力。它能与 200 多个 AWS 服务集成，通信通常是双向的。不过，其配置和管理较为复杂，尽管比单独使用 SQS 和 SNS 配置要容易一些。

1.1 运行模式

Step Functions 有标准和快速两种运行模式，具体对比如下：
| 运行模式 | 处理保证 | 工作流持续时间 | 执行速率 | 调试方式 |
| ---- | ---- | ---- | ---- | ---- |
| 标准模式 | 精确一次处理 | 适用于长时间运行的工作流，最长可达一年，状态可持久化，可下载 90 天执行历史 | 每秒约 800 次执行（作业） | 提供调试工具 |
| 快速模式 | 至少一次处理，可能重复处理任务 | 适用于短时间运行的工作流，最长 5 分钟 | 每秒约 6000 次执行，用于高吞吐量处理 | 通过 CloudWatch 日志调试 |

1.2 Workflow Studio

Workflow Studio 提供拖放式构建块，用于设计、原型制作和试验工作流。它可以验证设计和服务 API 请求参数，但不验证目标组件的存在或有效响应。该工具能导出完成的工作流设计所需的 Step Functions 配置，可将其复制到 CloudFormation 模板中，便于按照 DevOps 最佳实践进行云服务的配置。

1.3 工作流设计流程

graph LR
    A[使用 Workflow Studio 设计工作流] --> B[验证设计和参数]
    B --> C[导出 Step Functions 配置]
    C --> D[复制到 CloudFormation 模板]
    D --> E[完成云服务配置]

2. 事件驱动架构

事件驱动架构是一种设计无服务器微服务的不同方式，更符合业务视角而非技术视角。微服务代表业务流程中的步骤，而非技术特性，这使得微服务架构更易于理解，并能更好地将用户故事或业务需求映射到技术需求。

2.1 服务编排与服务编排对比

服务编排 ：有一个控制器负责协调工作流组件之间的所有指令和数据移动。服务依赖控制器的指令，相互紧密耦合，存在单点故障风险，一个服务失败可能导致整个工作流停止。
服务编排 ：服务主动监听环境变化并做出响应，无需等待控制器指令。这种方式促进了快速敏捷的软件开发，减少了服务之间的耦合，提高了可扩展性和可靠性。

2.2 服务编排架构组成

服务编排架构由事件生产者、事件路由器和事件消费者组成：
- 事件生产者 ：负责初始触发或请求，如用户上传文件到 S3 桶或微服务完成任务的信号。
- 事件路由器 ：负责将生产者生成的事件路由到消费者，还可进行事件转换操作。
- 事件消费者 ：接收路由器广播的消息，根据需要响应并处理事件。

2.3 事件驱动架构优势与挑战

优势	挑战
可扩展性：通过解耦，易于添加新服务	引入更多服务，增加系统复杂性和请求执行延迟
成本节省：无需轮询和控制器，减少空闲时间费用	额外服务可能增加总成本
可靠性：服务故障时工作流仍可继续

2.4 事件驱动架构示例

2.4.1 视频处理工作流

graph LR
    A[用户上传视频到 S3 桶] --> B[S3 发布视频上传事件到 SNS]
    B --> C[转码视频微服务]
    B --> D[创建字幕微服务]
    D --> E[字幕上传到 S3 桶]
    E --> F[SNS 发布新事件]
    F --> G[提取关键词微服务]

用户上传新视频文件到 S3 视频桶，S3 发布视频上传事件到 SNS。转码视频微服务创建不同格式视频，创建字幕微服务生成字幕。字幕上传到 S3 桶后，触发提取关键词微服务进行索引。

2.4.2 食品订购服务架构

客户提交订单，生成订单创建事件，由 EventBridge 路由到创建订单、通知供应商和分配骑手微服务。供应商准备好订单、骑手取货时，分别生成相应事件，由 EventBridge 路由到相关微服务。这种架构与服务编排不同，EventBridge 仅负责转发事件，服务失败时工作流仍可继续。

3. 异步设计模式与并行处理

3.1 异步设计模式

通常，API 服务采用同步设计，接收请求、处理并在同一连接中返回结果。而异步设计接收请求后，可选择进行验证，通知客户端请求已成功接收，然后结束连接。后端处理请求并在需要时通过新连接返回响应。异步设计适用于用户不期望立即得到结果的工作流，如生成发票 PDF 后通过电子邮件发送给用户。

3.2 并行处理

异步请求可在后台独立运行，适合并行处理。将请求拆分为多个小请求并同时执行，完成后合并结果。例如，从多个源检索数据或为一批图像生成缩略图时，可并行执行各个任务。

3.3 异步和并行处理示例

以视频处理为例，生成缩略图、转码视频和转录音频可并行进行，而生成字幕需在转录音频完成后进行。通过并行处理，工作流总运行时间从 8 分钟减少到 4 分钟。

3.4 异步设计的挑战

处理时间增加 ：如果无法进行并行处理，异步设计可能增加处理时间。
并行处理管理 ：并行处理可能出现错误，需要考虑错误处理和重试机制，合并结果也较为复杂。

3.5 异步 Step Functions 与 WebSocket 响应

API Gateway WebSockets 建立客户端与后端的双向连接，后端可主动向客户端推送消息。视频处理完成后，发布视频微服务可构建包含必要信息的完成消息，通过 WebSocket 发送给客户端。如果连接中断，可通过 SNS 或 SES 发送通知。

4. 容器技术

4.1 容器概述

容器化的概念起源于裸金属时代，但早期实现困难。第一个商业容器是 Solaris 10 UNIX 操作系统的 Zones 功能。容器与虚拟机类似，提供隔离、安全的独立执行空间，但容器启动速度更快，可在秒级甚至毫秒级内启动。2013 年 Docker 的出现改变了容器化难以实现的观念，它能轻松打包应用及其依赖项，使其在不同机器上以相同方式运行。

4.2 容器即服务（CaaS）

随着容器技术的发展，云提供商开发了容器即服务（CaaS）来托管和管理容器。Google 的相关服务发展为开源项目 Kubernetes，AWS 提供了 Elastic Container Service (ECS) 和 Elastic Kubernetes Service (EKS) 等 CaaS 服务。

4.3 Lambda 与容器对比

Lambda 本质上是一个容器平台，函数代码打包为容器在 Lambda 服务中按需启动，其容器管理平台 Firecracker 是开源的。与其他容器服务相比，Lambda 管理更严格，功能受限，对于运行时间超过 15 分钟的工作负载，容器可能是更好的选择。

4.4 无服务器容器

在 2017 年底之前，AWS 上的容器不被视为无服务器，因为 ECS 和 EKS 服务需要管理底层 EC2 实例，并按小时计费。2017 年 AWS 推出 Fargate，可完全管理底层集群和实例，用户只需在需要时运行容器，并按容器可用时间付费。Fargate 适用于按需任务，如视频转换、机器学习模型和某些数据聚合任务。

4.5 无服务器容器使用流程

graph LR
    A[确定任务需求] --> B{是否适合 Lambda}
    B -- 否 --> C[考虑使用 Fargate 容器]
    C --> D[根据需求启动和终止容器]
    D --> E[完成任务并计费]
    B -- 是 --> F[使用 Lambda 处理任务]

通过上述对 Step Functions、事件驱动架构、异步设计模式、并行处理和容器技术的介绍，我们可以看到 AWS 提供了丰富的工具和服务，帮助开发者构建高效、可扩展和可靠的云应用。在实际应用中，需要根据具体需求选择合适的技术和架构，以实现最佳的性能和成本效益。

5. 综合应用案例分析

5.1 电商平台订单处理系统

在电商平台中，订单处理涉及多个环节，如订单创建、库存检查、支付处理、发货通知等。我们可以结合前面介绍的技术构建一个高效的订单处理系统。

5.1.1 系统架构设计

graph LR
    A[用户下单] --> B[EventBridge 接收订单创建事件]
    B --> C[库存检查微服务]
    B --> D[支付处理微服务]
    C --> E{库存是否充足}
    E -- 是 --> F[更新库存]
    E -- 否 --> G[通知用户缺货]
    D --> H{支付是否成功}
    H -- 是 --> I[生成发货单]
    H -- 否 --> J[通知用户支付失败]
    F --> I
    I --> K[发货通知微服务]
    K --> L[用户接收发货通知]

5.1.2 技术选型与实现

事件驱动架构 ：使用 EventBridge 作为事件路由器，将订单创建事件路由到库存检查和支付处理微服务。
异步设计模式 ：支付处理和库存检查可以采用异步设计，用户下单后立即收到订单确认，后台进行处理。
Step Functions ：可以使用 Step Functions 来协调整个订单处理流程，确保每个步骤按顺序执行，并处理异常情况。
容器技术 ：对于库存检查、支付处理等微服务，可以使用 Docker 容器进行打包，并使用 AWS 的 ECS 或 EKS 进行管理。

5.2 大数据处理平台

大数据处理平台通常需要处理大量的数据，包括数据采集、清洗、分析和存储等环节。我们可以利用并行处理和异步设计模式来提高处理效率。

5.2.1 系统架构设计

graph LR
    A[数据采集] --> B[数据清洗微服务 1]
    A --> C[数据清洗微服务 2]
    A --> D[数据清洗微服务 3]
    B --> E[数据合并]
    C --> E
    D --> E
    E --> F[数据分析微服务]
    F --> G[数据存储微服务]

5.2.2 技术选型与实现

并行处理 ：数据清洗环节可以将数据拆分为多个部分，并行地由多个数据清洗微服务进行处理，最后合并结果。
异步设计模式 ：数据采集和数据清洗可以采用异步设计，采集到数据后立即发送给清洗微服务，不等待处理结果。
容器技术 ：数据清洗、分析和存储微服务可以使用 Docker 容器进行打包，并使用 AWS 的 Fargate 进行无服务器部署。

6. 技术选择与决策因素

6.1 业务需求

处理时间要求 ：如果业务要求快速响应，如实时交易系统，可能需要选择同步设计模式；如果对处理时间不敏感，如批量数据处理，可以采用异步设计模式。
业务流程复杂度 ：对于简单的业务流程，可以使用服务编排；对于复杂的业务流程，服务编排可能导致系统耦合度高，建议采用服务编排。

6.2 成本考虑

技术	成本特点
Lambda	按执行时间计费，适合短时间运行的任务
Fargate	按容器可用时间计费，适合按需任务
ECS/EKS	需要管理底层 EC2 实例，按小时计费，适合大规模容器集群

6.3 可扩展性要求

事件驱动架构 ：通过解耦服务，易于添加新的微服务，提高系统的可扩展性。
并行处理 ：可以将任务拆分为多个小任务并行执行，提高系统的处理能力。

6.4 可靠性要求

异步设计模式 ：可以避免一个服务的故障影响整个系统的运行，提高系统的可靠性。
Step Functions ：提供精确一次处理保证，确保工作流的准确性和可靠性。

7. 总结与展望

7.1 总结

本文介绍了 AWS 中的多种技术，包括 Step Functions、事件驱动架构、异步设计模式、并行处理和容器技术。这些技术各有特点，可以根据不同的业务需求和场景进行选择和组合。例如，事件驱动架构适合构建松耦合、可扩展的系统；异步设计模式可以提高用户体验和系统处理效率；并行处理可以加速任务执行；容器技术可以实现应用的快速部署和管理。