Serverless 多环境管理如何实现？

环境隔离：多环境的基石

Serverless 应用中，开发、测试、预发布、生产等环境必须做到物理或逻辑隔离，避免环境间相互干扰。

账号级隔离是最推荐的方式。为每个环境创建独立的云账号（或 AWS Organization 下的独立 OU），从根源上杜绝资源混淆。比如生产环境使用 prod-account，测试环境使用 test-account，即使在错误操作时也不会影响其他环境的资源。

资源级隔离适用于团队规模较小的场景。在同一账号下，通过命名规范区分资源：函数命名为 dev-user-service、staging-user-service、prod-user-service。API Gateway 的 stage、DynamoDB 的表名前缀、S3 的 bucket 名都遵循同样的规范。

权限隔离同样关键。开发环境可以给开发者较宽的权限，而生产环境的操作权限应该严格收口到 CI/CD 流水线，禁止人工直接部署或修改配置。

配置管理：让每个环境有独立身份

不同环境的配置差异是多环境管理中最容易出问题的环节。

环境变量是最基础的配置方式。AWS Lambda 支持在函数级别设置环境变量，Serverless Framework 通过 ${opt:stage} 或 ${self:provider.stage} 在不同 stage 下注入不同的值。关键原则是：业务代码中永远不要硬编码环境特定的值，统一从环境变量读取。

密钥管理必须使用专门的 Secrets Manager，而非明文环境变量。AWS Secrets Manager 和 Parameter Store（SecureString 类型）是常用方案。在 Serverless Framework 中，可以这样引用：

yaml
environment:
  DB_PASSWORD: ${ssm:/${self:provider.stage}/db/password~true}

~true 表示自动解密。这样 dev 和 prod 各维护一条 SSM 参数，代码无需改动。

配置文件分层也是常见做法。将公共配置放在 serverless.yml，环境特定配置放在 serverless-dev.yml、serverless-prod.yml 中，通过 Serverless Framework 的变量系统合并：

yaml
custom: ${file(./serverless-${self:provider.stage}.yml)}

部署策略：安全发布的核心

多环境不仅是隔离，还要确保代码从开发到生产的流转过程可控、可回滚。

蓝绿部署适合 API 类服务。维护两套完全相同的 Lambda + API Gateway 部署，通过 DNS 权重或 API Gateway 的 canary setting 切换流量。切换瞬间完成，回滚同样只需切换回去。

金丝雀发布是更精细的流量控制方式。AWS Lambda 支持 Alias + Weighted Routing，将 10% 的流量导向新版本，90% 留在旧版本，观察错误率和延迟指标后再决定是否全量发布。

滚动更新在 Serverless 场景下实际上是"即时替换"——Lambda 的新版本部署是原子的，不存在传统意义上的滚动过程。但对于 ECS Fargate 等 Serverless 容器服务，滚动更新仍然适用，可以通过 minimumHealthyPercentage 和 maximumPercent 控制替换节奏。

工具支持：三大框架的多环境方案

Serverless Framework

通过 stage 参数区分环境，这是最核心的机制：

yaml
service: user-service
provider:
  name: aws
  stage: ${opt:stage, 'dev'}
  environment:
    STAGE: ${self:provider.stage}

部署时指定 sls deploy --stage prod，所有资源自动带上 stage 后缀。配合 serverless.yml 的变量系统，可以实现一套代码、多环境部署。

AWS SAM

SAM 使用 Parameters 和 Conditions 实现环境差异化：

yaml
Parameters:
  Stage:
    Type: String
    Default: dev
    AllowedValues: [dev, staging, prod]

Conditions:
  IsProd: !Equals [!Ref Stage, prod]

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      MemorySize: !If [IsProd, 1024, 256]

通过条件逻辑，prod 环境可以分配更多内存，dev 环境则用最小配置降低成本。

Terraform

Terraform 的 Workspace 是天然的多环境方案：

bash
terraform workspace new dev
terraform workspace new prod
terraform apply -var-file="env/${terraform.workspace}.tfvars"

每个 Workspace 维护独立的状态文件，同一套 HCL 代码通过 terraform.workspace 内置变量切换配置。模块化则让不同环境的资源定义保持 DRY。

最佳实践总结

配置与代码分离是多环境管理的第一原则。任何环境特定的值都不应该出现在代码仓库中，通过环境变量、SSM 参数或独立的配置文件注入。

版本控制一切配置。包括 serverless.yml、Terraform 模块、CI/CD 流水线定义。配置的变更也应该走 Code Review，避免某人在生产环境中手动修改参数。

CI/CD 自动化部署是硬性要求。生产环境的部署必须由流水线触发，禁止人工执行 sls deploy --stage prod。推荐使用 GitHub Actions 或 GitLab CI，在合并到 main 分支时自动部署到 staging，打 tag 后部署到 production。

环境一致性经常被忽视。dev 环境应该尽量复用与 prod 相同的基础设施模板，只是规模缩小。如果 dev 用 SQLite 而 prod 用 DynamoDB，环境差异本身就会引入风险。使用 Serverless Framework 或 SAM 的同一套模板，通过参数调节规模，是更稳妥的做法。