3. 环境规划：开发环境、测试环境、预发布环境、生产环境划分与资源规划
在供应链控制塔事件溯源项目中，合理的环境划分是保障交付质量与运维稳定性的基石。本章将定义四套标准环境（DEV、TEST、STAGING、PROD）的职责边界、资源规格与网络隔离策略，并给出基于 Kubernetes 命名空间与云资源的规划方案。
3.1 环境职责与隔离策略
每个环境对应一个独立的 Kubernetes 集群或强隔离命名空间组，通过网络策略（NetworkPolicy）与云防火墙实现南北向与东西向流量管控。
| 环境 | 代号 | 主要用途 | 数据策略 | 访问控制 |
|---|---|---|---|---|
| 开发环境 | DEV | 开发人员自测、单元集成、本地联调 | 脱敏样本数据，可随时重建 | 仅开发团队 VPN + 堡垒机 |
| 测试环境 | TEST | QA 功能测试、接口自动化、性能基准 | 脱敏全量数据，每日重置 | QA 团队 + 开发只读 |
| 预发布环境 | STAGING | 生产灰度验证、压测、UAT 验收 | 脱敏近生产数据，与生产隔离 | PM + QA Lead + 运维 |
| 生产环境 | PROD | 线上真实业务，SLA 99.99% | 真实数据，严格备份与审计 | 仅运维 + 审批临时授权 |
环境隔离原则： DEV 与 TEST 可共用同一集群的不同命名空间，但 STAGING 与 PROD 必须使用独立集群，且 PROD 集群不允许部署任何非生产负载。
3.2 资源规划清单
以下资源规划基于事件溯源架构的核心组件：事件存储（Event Store）、消息队列（Kafka）、计算引擎（Flink/Spark）、API 网关与监控告警。所有环境均采用高可用部署，生产环境额外配置跨可用区容灾。
| 组件 | DEV | TEST | STAGING | PROD |
|---|---|---|---|---|
| Kubernetes 节点 | 3 台 4C8G | 5 台 8C16G | 7 台 16C32G | 10 台 32C64G × 2 AZ |
| Event Store (PostgreSQL) | 1 主 1 从 4C8G | 1 主 2 从 8C16G | 1 主 2 从 16C32G | 1 主 3 从 + 同步备 32C64G |
| Kafka 集群 | 3 节点 4C8G | 3 节点 8C16G | 6 节点 16C32G | 9 节点 32C64G × 2 AZ |
| Flink 作业管理器 | 1 台 4C8G | 1 台 8C16G | 2 台 16C32G HA | 3 台 32C64G HA |
| API 网关 (Kong/Istio) | 1 实例 2C4G | 2 实例 4C8G | 2 实例 8C16G HA | 4 实例 16C32G HA |
| 监控 (Prometheus + Grafana) | 1 套 2C4G | 1 套 4C8G | 1 套 8C16G HA | 1 套 16C32G HA + 异地 |
| 对象存储 (MinIO/S3) | 2 节点 2C4G | 2 节点 4C8G | 4 节点 8C16G | 6 节点 16C32G 纠删码 |
成本估算参考： 以阿里云按量计费为例，DEV 环境月均约 ¥3,500，TEST 约 ¥8,200，STAGING 约 ¥18,000，PROD 约 ¥65,000（含跨 AZ 流量与备份存储）。建议对 STAGING 与 PROD 采用预留实例节省 30%~40% 成本。
3.3 环境网络拓扑与部署流水线
下图展示了四套环境之间的网络隔离关系与 CI/CD 制品流转路径。代码从 DEV 开始逐级晋升，最终到达 PROD。
3.4 环境配置管理
所有环境差异通过 ConfigMap 与 Secret 管理，禁止在代码中硬编码环境变量。推荐使用 Kustomize 或 Helm 进行多环境参数化部署。
# 目录结构示例：基于 Kustomize 的环境配置
event-sourcing-deploy/
├── base/
│ ├── kustomization.yaml
│ ├── deployment.yaml
│ ├── service.yaml
│ └── configmap.yaml
├── overlays/
│ ├── dev/
│ │ ├── kustomization.yaml
│ │ ├── configmap-patch.yaml
│ │ └── resource-limits.yaml
│ ├── test/
│ │ ├── kustomization.yaml
│ │ ├── configmap-patch.yaml
│ │ └── hpa.yaml
│ ├── staging/
│ │ ├── kustomization.yaml
│ │ ├── configmap-patch.yaml
│ │ └── ingress-tls.yaml
│ └── prod/
│ ├── kustomization.yaml
│ ├── configmap-patch.yaml
│ ├── pdb.yaml
│ └── network-policy.yaml
关键提醒： 生产环境的 Secret（如数据库密码、Kafka 证书）必须使用外部密钥管理服务（如 AWS Secrets Manager、Vault），禁止以明文形式存储在 Git 仓库中。STAGING 与 PROD 的密钥应完全独立，不可复用。
3.5 环境生命周期与清理策略
为控制成本并避免数据残留，各环境应设置自动化的生命周期管理规则。
- DEV： 每晚 22:00 自动销毁非保留命名空间，次日 08:00 按需重建。数据保留不超过 7 天。
- TEST： 每次测试任务完成后触发清理脚本，数据库每日凌晨 03:00 重置为基线快照。
- STAGING： 灰度验证结束后保留 48 小时用于回滚验证，之后自动释放节点资源，仅保留基础架构。
- PROD： 不自动销毁，但需定期（每月）进行灾难恢复演练，验证备份有效性。
自动化工具链： 使用 Terraform 管理云资源生命周期，结合 Jenkins Pipeline 或 Argo Workflows 实现环境创建、部署、测试、销毁的全流程自动化。建议为每个环境创建独立的 Terraform Workspace。