fakecloud是一款免费、开源的本地 AWS 云模拟器（LocalStack 替代品），覆盖 107 个服务、7,657 个操作，且全部通过 Smithy 一致性校验。它的核心亮点之一就是真实的跨服务联动：S3 上传对象能真的触发 Lambda 执行，EventBridge 事件能真的启动 Step Functions 状态机，SES 邮件事件能真的经 SNS 落到 SQS 队列——全部在本地http://localhost:4566上端到端跑通，无需 AWS 账号、无需认证 token。

本文带你拆解 fakecloud 的三大跨服务集成测试链路，看看它是如何做到"真实验证"而非"打桩假跑"的。

一、为什么跨服务集成测试这么难

在真实 AWS 上，服务之间的联动（S3 通知、事件总线、邮件收件规则）依赖事件驱动架构，本地测试面临三大难题：

• 💸成本高：每跑一轮 CI 都产生真实费用
• 🐌速度慢：远程调用 + 异步事件，单条用例动辄数秒
• 🎭不可观测：事件到底有没有触发下游？只能靠日志猜

fakecloud 的解法：单二进制（约 19 MB、300ms 启动）模拟全部服务，事件总线在进程内真实投递，下游服务收到事件后真实执行。

克隆仓库即可开始：

git clone https://gitcode.com/gh_mirrors/fak/fakecloud

安装后一条命令启动：

curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud

然后把任意 AWS SDK / CLI 指向--endpoint-url http://localhost:4566即可。

二、链路一：S3 → Lambda（对象上传真实触发函数执行）

对应的端到端测试是 lambda_integration.rs 中的s3_to_lambda_notification_executes_code。

测试流程拆解

关键设计："标记队列"验证法

很多模拟器只检查"通知有没有发出"，而 fakecloud 更进一步：它创建一个真实的 Python Lambda 函数（Docker 容器内运行），函数逻辑是把收到的事件写回一条 SQS 队列（见 lambda_integration.rs 中的python_sqs_writer_code）。

测试最后断言队列中必须出现marker: lambda-executed标记——如果 Lambda 没有真正执行，这个标记永远不会出现。这就是"端到端真实验证"的含义：

不 mock 下游，用可观察的副作用（队列消息）证明整条链路贯通。

三、链路二：EventBridge → Step Functions（事件驱动状态机）

对应测试 eventbridge.rs 中的eb_rule_starts_stepfunctions_execution。

测试流程拆解

1. 创建状态机：一个最简单的 Pass 状态（StartAt: PassState → End: true）
2. 创建 EventBridge 规则sfn-trigger，事件模式{"source": ["test.sfn"]}
3. put_targets把规则指向状态机 ARN
4. put_events投递一条匹配事件
5. 轮询list_executions，直到执行状态从RUNNING变为SUCCEEDED✅

这里有两个容易被忽视的细节：

• 执行是异步的：list_executions在状态机启动瞬间就会列出RUNNING执行，所以测试用wait_until轮询直到终态，而不是假设"PutEvents 返回 = 执行完成"（见 eventbridge.rs）
• 双向联动：不止 EventBridge 能触发 Step Functions，反向也成立——Step Functions 的 Task 状态可以直接调用aws.events:putEvents，投递逻辑在 interpreter_helpers.rs 中实现，并带执行作用域与角色校验

除了直接目标，事件还可以多级扇出：EventBridge → SNS → SQS 的完整链路在 multiservice.rs 的eventbridge_to_sns_to_sqs_chain中有验证。

四、链路三：SES → SQS（邮件事件端到端落地）

对应测试 ses.rs 中的ses_event_fanout_sns_destination。

测试流程拆解

SES 发送邮件 ──事件──▶ Configuration Set 事件目的地 ──▶ SNS Topic ──订阅──▶ SQS 队列 （Send + Delivery 两个事件类型）

测试还覆盖了更隐蔽的Bounce 模拟器场景：把邮件发给bounce@simulator.amazonses.com，fakecloud 会生成 Bounce 事件并经 SNS 投递到 SQS（ses.rs）。

进阶：SES 收件规则的多动作编排

如果你测试的是"入站邮件"场景，fakecloud 的 SES 支持完整收件规则执行，测试 ses_receipt_actions.rs 展示了单条规则同时执行 4 个动作：

• AddHeader注入自定义头 → 存入S3
• 触发SNS通知（含注入头的内容校验）
• Bounce生成退信邮件（550 / 5.7.1）
• 通知经 SNS →SQS双通道落地

通过内部 APIPOST /_fakecloud/ses/inbound注入一封入站邮件，即可驱动整条规则链，随后断言 S3 对象、退信、SQS 通知三者全部就位。

五、如何自己跑这些跨服务测试

所有跨服务测试集中在 e2e 测试套件中，核心文件：

运行方式（涉及 Lambda 真实执行的用例会启动 Docker 容器，本地无 Docker 时自动跳过）：

cargo test -p fakecloud-e2e --test lambda_integration cargo test -p fakecloud-e2e --test eventbridge cargo test -p fakecloud-e2e --test cross_service

调试技巧：内部 Introspection API

fakecloud 提供了一系列/_fakecloud/*内部端点，方便断言"服务内部发生了什么"：

这些端点在测试中的用法见 cross_service.rs。

六、小结

fakecloud 的跨服务集成测试设计有两条清晰的原则：

1. 断言可观察的副作用，而非中间态——用 SQS 标记消息、S3 对象、执行历史证明 Lambda 真的执行、规则真的触发
2. 测试代码即文档——crates/fakecloud-e2e/tests/ 下 367 个测试文件，每条链路都可以直接复制成你 CI 里的集成用例

不需要 AWS 账号、不需要付费层、启动 300ms，把整个事件驱动架构搬回本地——这正是 fakecloud 与 LocalStack 最本质的差异之一。

更多跨服务组合与每服务操作数明细，可参考仓库内的 README.md 与 website/content/docs/ 文档目录。