Floci 本地模拟 AWS 服务：把集成测试搬回本机，接住云服务间调用

一段上传文件的代码，单独测试并不难。难的是上传之后还要写入数据库、投递消息、触发函数，而开发环境必须把这些环节一起准备好。测试最终依赖的不只是代码，还有云账号、网络、权限，以及上一次运行有没有把资源清理干净。这也是云栈社区里不少开发者反复讨论的痛点。

Floci 做的是本地 AWS 服务模拟：让应用继续沿用熟悉的 SDK 和命令行，把请求交给本机的测试环境。这个今年 2 月创建的开源项目，在 9 月 15 日发布了 2.1.0，继续补齐基础设施声明和服务行为。比如 CloudFormation 新增对 API Key、UsagePlan 等资源的创建支持，API Gateway 也补上了更多鉴权语义。对维护云应用的人来说，这些变化关系到本地测试能不能覆盖真实调用路径。

我喜欢这个项目的一个具体选择：尽量保留开发者已有的工具。应用已经用 AWS SDK，就继续用它；测试脚本已经会创建 S3 桶、读取 DynamoDB 表，也不必全部改写成另一套专用接口。项目文档把模拟器作为兼容端点提供出来，迁移的起点因此是调整连接目标，再逐项检查业务所需的操作。

但“模拟云服务”有好几种深度。只返回一个固定 JSON，可以证明调用代码走到了某一行，却很难检验资源之间是否真正接上。Floci 对一些服务在进程内实现行为，对另一些需要运行引擎的服务，则使用 Docker 容器。例如 RDS 可以接真实的数据库引擎，Lambda 也有容器执行路径。它试图把一部分集成关系带回开发机，而不只是给接口套一层假响应。

这也解释了 2.1.0 中那些不容易做宣传标题的修复。API Gateway 开始执行更多授权检查，CloudFormation 能识别更多资源类型，Athena 对 Glue 表结构的处理更贴近预期。测试环境过分宽松时，错误配置很容易被放过去；行为逐渐收紧，才能让失败早点暴露。这里的价值需要用团队自己的测试用例验证，不能用“支持某服务”五个字替代。

按照 README，最小的 Docker Compose 文件可以这样写，保存为 compose.yaml：

services:
floci:
image:floci/floci:latest
ports:
-"4566:4566"

然后在该文件所在目录执行：

docker compose up

这是启动基础环境的演示配置。涉及真实容器执行的服务，还需要按对应文档准备 Docker 访问和额外配置。团队把它接入持续集成之前，也应把镜像版本固定下来，避免一次拉取最新镜像就改变了测试条件。

如果已经安装官方 Floci CLI 和 AWS CLI，README 还提供了一条更短的试用路径：

floci start
eval $(floci env)
aws s3 mb s3://my-bucket

前两步启动模拟器并向当前 shell 导入本地测试所需的环境变量，第三步沿用标准 AWS 命令创建桶。先在独立的测试终端里跑通这样一个小闭环，再接数据库、消息和函数，比一开始就迁入整套基础设施更容易定位兼容差异。

配图中的浏览器控制台来自项目官方的 Floci UI。它给本地资源增加了可视入口，但控制台和模拟器的能力要分开判断：某个服务有界面，不等于该服务的每个云端操作都已实现；界面上的资源数量也只是截图当时的状态。

Floci 适合承担开发和测试环境的一部分职责。生产云上的配额、延迟、权限边界，以及故障时的行为，仍然需要在真实环境中验证。我会先让它接住最常重复、最容易搭建的那段 集成测试，再根据实际兼容性扩大范围。能把一次本来要等云环境的验证缩短到本机完成，就已经值得认真试一轮。

项目地址： https://github.com/floci-io/floci