单体Laravel应用转微服务后部署至AWS Serverless实操问题咨询

一、部署模板选型及Laravel运行支持问题 #

• 模板选型：SAM和Bref并不冲突，可以搭配使用。Bref是专门为PHP适配Serverless运行环境的工具，自带PHP自定义运行时和Laravel专属适配层，解决Lambda原生不支持PHP运行的问题；SAM是AWS官方的基础设施即代码工具，用于标准化部署Serverless资源。
  • 如果你偏好AWS原生生态，直接用SAM模板+ Bref公开的PHP运行时层ARN即可完成部署
  • 如果你想减少配置成本，直接用Bref官方提供的Serverless Framework模板即可快速部署
• Laravel适配方案：安装bref/laravel-bridge扩展包，直接复用Bref提供的FPM运行时处理HTTP请求，控制台运行时处理Artisan命令、队列消费逻辑，无需修改核心业务代码即可适配Lambda运行环境。

二、接口与Lambda函数的映射规则及数据库共享配置 #

• 不需要每个接口对应独立Lambda函数：建议单个微服务对应一个Lambda函数即可，所有同服务的接口由API Gateway做路径路由后转发到同一个Lambda处理。单Lambda复用同一Laravel框架实例，能大幅减少冷启动次数、降低维护成本，只有单个接口调用量远超其他接口、有独立扩缩容需求时才单独拆分。
• 不需要拆分更多Laravel项目：你现有的两个服务对应两个独立Laravel项目的架构已经符合微服务边界，保持即可，每个项目对应一个Lambda函数。
• 多服务共用数据库配置：
  1. 先将Aurora的连接地址、账号密码等敏感信息存储到AWS Secrets Manager或者Systems Manager Parameter Store中
  2. 在SAM/Bref模板中给两个Lambda的执行角色配置上述配置存储服务的读取权限，将数据库连接信息注入到Lambda的环境变量
  3. 两个Laravel项目直接读取环境变量中的数据库配置即可实现访问，无需硬编码配置。注意要将Lambda和Aurora部署在同一个VPC下，配置安全组允许Lambda访问Aurora的5432端口即可。

最佳实践建议：两个微服务拆分独立的数据库实例或者独立库，不要跨服务访问同一张表，避免服务耦合。

三、API Gateway架构设计 #

• Lambda本身不会默认创建API Gateway，只有在部署模板中配置了API触发规则时，才会自动生成对应的API Gateway资源。
• 不需要搭建两层API Gateway：建议直接搭建一个面向用户的统一主API Gateway作为入口，按路径前缀直接路由到对应服务的Lambda即可，比如/api/auth/*路由到身份认证服务Lambda、/api/todo/*路由到待办事项服务Lambda。两层网关只会增加不必要的延迟和成本，没有额外收益。主API Gateway可以统一实现域名管理、限流、身份校验、日志监控等公共能力。

四、整体迁移落地步骤 #

1. 基础设施准备：部署VPC、私有子网、安全组，创建Aurora PostgreSQL集群，按服务拆分独立数据库，迁移原有业务数据到对应库中
2. 业务代码适配：两个Laravel项目安装Bref相关依赖，优化Laravel配置：关闭不必要的服务提供者降低冷启动时间、配置日志输出到标准输出、将session、缓存等放到ElastiCache Redis中
3. 部署配置编写：选择SAM或者Bref模板，配置Lambda资源、执行角色权限、主API Gateway路由规则
4. 测试验证：部署到测试环境，验证接口可用性、数据库读写正常、性能符合预期
5. 灰度切流：逐步将生产流量切到Serverless架构，监控CloudWatch指标，无问题后全量切流，下线原有单体服务

五、CI/CD集成方案建议 #

可以选择AWS CodePipeline或者GitHub Actions实现自动化集成，标准流程如下：

• 代码提交到对应服务的代码仓库时自动触发流水线
• 第一步执行依赖安装、单元测试、静态代码检查，不通过则中断流程
• 第二步构建Lambda部署包，替换对应环境的配置变量
• 第三步执行部署命令（sam deploy或serverless deploy）发布到对应环境
• 第四步执行自动化接口测试，验证服务可用性，验证不通过自动回滚

内容的提问来源于stack exchange，提问作者DevAntho