← 返回展示台

阿里云部署与不停机升级方案

前提：上线后不允许停机维护。本文给出可落地的部署拓扑、灰度流程与回滚预案。

---

一、环境划分

环境	用途	规格建议	数据
dev	开发自测	2C4G × 1	造数据
test	集成测试	4C8G × 2	脱敏数据
staging	预发（与生产同规格）	8C16G × 2	生产脱敏快照
prod	生产	8C32G × 3（最小）	真实

staging 必须与生产同规格，否则压测与容量评估全部失效。
这是最容易被省钱砍掉、然后在上线当天付出代价的一项。

---

二、生产最小可用拓扑（一期）

                    ┌──────────────┐
                    │  SLB / ALB   │  ← 公网入口，多可用区
                    └──────┬───────┘
                           │
              ┌────────────┴────────────┐
              │        WAF 3.0          │
              └────────────┬────────────┘
                           │
         ┌─────────────────┴──────────────────┐
         │      ACK 集群（3 节点，多可用区）     │
         │  ┌──────────────────────────────┐  │
         │  │ gateway (2 副本)              │  │
         │  │  ├─ 鉴权 / 限流 / 租户识别     │  │
         │  │  └─ 灰度路由                  │  │
         │  ├──────────────────────────────┤  │
         │  │ business-svc (3 副本)         │  │  ← 房源/合同/计费/工单
         │  │ integration-svc (2 副本)      │  │  ← 支付/OTA/签章/AR 集成
         │  │ agent-svc (2 副本)            │  │  ← Agent 能力
         │  │ job-worker (2 副本)           │  │  ← 账单生成/对账/outbox 投递
         │  └──────────────────────────────┘  │
         └─────────────────┬──────────────────┘
                           │
    ┌──────────┬───────────┼────────────┬──────────────┐
    │          │           │            │              │
┌───┴────┐ ┌───┴────┐ ┌────┴─────┐ ┌────┴────┐ ┌──────┴──────┐
│RDS PG  │ │Redis   │ │RocketMQ  │ │  OSS    │ │Elasticsearch│
│主+2只读│ │集群版  │ │专业版    │ │+ CDN    │ │ 3 节点      │
│多可用区│ │双副本  │ │          │ │         │ │             │
└────────┘ └────────┘ └──────────┘ └─────────┘ └─────────────┘

旁路（二期）：ClickHouse（IoT/报表）

规格建议（一期，100 万房源以内）

组件	规格	说明
ACK 节点	8C32G × 3	多可用区部署，单节点故障不影响
RDS PostgreSQL	16C64G，ESSD PL1 1TB，多可用区	主库
RDS 只读实例	8C32G × 2	①报表 ②C 端查询
Redis 集群版	8G × 3 分片，双副本	会话/缓存/锁
RocketMQ	专业版，4C8G	事务消息必需
OSS	标准存储 + CDN	图片/AR 资源
SLB/ALB	性能保障型	按流量选

⚠️ RDS 规格宁大勿小：数据库升级需要停机或切换，
而应用层扩缩容是滚动无感的。把资源余量留在数据库上。

---

三、不停机升级的标准流程

3.1 应用发布（无状态服务）

① 代码合并 → CI 构建镜像 → 推送 ACR
② staging 部署 → 自动化回归 + 冒烟
③ 生产灰度：
   ├─ 步骤1：部署 1 个新版本 Pod（占 1/4 流量）
   ├─ 步骤2：观察 30 分钟（错误率/延迟/业务指标）
   ├─ 步骤3：扩到 50% → 观察
   ├─ 步骤4：全量
   └─ 任一步异常 → 立即缩容新版本，流量回旧版本（秒级）
④ 旧版本 Pod 保留至少 30 分钟再下线（保证长连接平滑迁移）

技术前提（缺一不可）：

前提	不满足的后果
应用无状态（会话在 Redis）	无法多副本，无法滚动
优雅关闭（preStop + SIGTERM 处理）	请求被硬断，用户看到错误
健康检查（liveness + readiness 分离）	新 Pod 未就绪就接流量
数据库变更向后兼容	新旧版本数据冲突
接口幂等	重试导致重复扣款

3.2 数据库变更（最关键，最容易出事）

必须遵守 Expanding / Contracting 五步法。 以「账单增加 refunding 状态」为例：

阶段	操作	可回滚	说明
① Expand	放宽 CHECK 约束，允许新值	✅ 随时	纯 DDL，秒级，不锁表
② Deploy A	新代码可写新值，旧代码读到按 pending 处理	✅ 回滚代码即可	灰度期间两版共存
③ Migrate	后台分批把存量数据规范化	✅ 幂等可重跑	每批 5000 行，避免长事务
④ Deploy B	移除兼容旧状态的代码	✅	此时全量新代码
⑤ Contract	收紧约束、删废弃列	❌ 不可回滚	必须等所有旧实例下线

红线清单（CI 中应自动拦截）：

操作	判定	替代方案
ADD COLUMN ... NOT NULL 无默认值	🔴 禁止	先 nullable + 回填 + 加约束
RENAME COLUMN/TABLE	🔴 禁止	新增 + 双写 + 迁移 + 删除
ALTER COLUMN TYPE	🔴 禁止（大表）	新增列 + 转换 + 切换
CREATE INDEX（不带 CONCURRENTLY）	🔴 禁止	CREATE INDEX CONCURRENTLY
DROP COLUMN 后 2 个版本内	🟠 警告	延后删除
全表 UPDATE	🔴 禁止	分批（LIMIT + 循环）
VACUUM FULL	🔴 生产禁止	pg_repack
LOCK TABLE	🔴 禁止	调整业务逻辑

配套实现：DDL/09-分布式一致性.sql 中的 schema_migration 表带
is_destructive / is_online_safe 字段，应在 CI 中强制校验：
破坏性变更必须标记并走审批。

3.3 账单批生成这类「重任务」的不停机做法

每月 1 号生成数百万张账单，这是最容易造成停机的操作。

❌ 错误做法：一个大事务跑完，锁表数分钟。

✅ 正确做法：

① 按月/租户切分任务，投递到 MQ（每租户一个消息）
② worker 并发消费，每个任务独立事务（只处理一个租户的账单）
③ 幂等：bill 表的 idempotency_key 保证重复消费不会多生成（已验证）
④ 进度可查：任务表记录每个租户的处理状态
⑤ 失败可重试：单租户失败不影响其他租户
⑥ 限流：控制并发数，避免打满数据库

关键点：账单生成必须是「幂等 + 可断点续跑」的。

月中发现问题可以随时重跑，不会重复生成。

---

四、回滚预案

场景	回滚手段	目标时间
应用异常	缩容新版本 Pod / 切回旧镜像	< 1 分钟
新功能有问题	特性开关关闭（不发版）	< 10 秒
数据库变更引发问题	执行反向迁移脚本	< 5 分钟
数据写错	按业务单号精确修复（不做全库回滚）	视范围
主库故障	RDS 自动主备切换	30~60 秒（有闪断）
整个可用区故障	多可用区自动切换	1~3 分钟

必须提前准备的资产：

1. 每个数据库变更都配反向迁移脚本（写在同一个 PR 里）
2. 关键业务的数据修复脚本模板（按单号修复，非全表）
3. 一份回滚检查清单，演练过至少一次

---

五、监控与告警（上线前必须有）

层次	指标	告警阈值	工具
数据库	连接数使用率	> 80%	RDS 监控
数据库	主备延迟	> 10 秒	RDS 监控
数据库	慢查询数（>1s）	> 10 条/分钟	RDS 慢日志 + ARMS
数据库	死锁与长事务	长事务 > 30 秒	自定义告警
应用	接口 P99 延迟	> 500ms	ARMS
应用	错误率	> 1%	ARMS
业务	收租成功率	< 99%	自定义埋点
业务	支付回调失败数	> 0	对账任务
业务	outbox 积压量	> 1000	定时查询
集成	第三方接口失败率	> 5%	integration_call_log
对账	对账差异数	> 0	对账任务

只监控技术指标是不够的。 上面标粗的三项是业务指标：
收租成功率掉点、outbox 积压、对账差异 —— 这三项能最早发现业务级故障。

---

六、上线前检查清单

基础设施

• [ ] RDS 多可用区已开启，自动备份已验证可恢复
• [ ] 只读副本延迟正常（< 1 秒）
• [ ] Redis 集群双副本，故障切换已演练
• [ ] OSS 已配 CDN，防盗链已开
• [ ] WAF 已开启，限流规则已配

应用

• [ ] 无状态（会话在 Redis），优雅关闭已实现
• [ ] liveness / readiness 探针已配，且超时合理
• [ ] 数据库连接池大小已算过（见下）
• [ ] 所有对外接口幂等
• [ ] 重试策略已配（指数退避 + 抖动）

数据

• [ ] 大表已分区（bill / payment / room_calendar）
• [ ] 高频查询都有 tenant_id 前导索引（实测差距 1250 倍）
• [ ] autovacuum 已调优，监控已配（统计信息滞后导致 280 倍退化）
• [ ] 反向迁移脚本已准备
• [ ] 备份恢复演练已做过（必须实际演练，不能只看配置）

业务

• [ ] 支付对账任务已上线，差异告警已配
• [ ] outbox 投递任务在跑，积压告警已配
• [ ] 账单批生成的幂等已验证
• [ ] 灰度开关可用，回滚演练已做

连接池大小计算（重要）

应用连接数 = Pod数 × (每Pod最大连接数)
必须满足：应用连接总数 < RDS max_connections × 0.8

例：6 个 Pod × 每 Pod 20 连接 = 120 连接
    RDS 16C64G 的 max_connections 约 4000，安全

⚠️ 但连接数不是越多越好。PostgreSQL 的经验值是
活跃连接数 ≈ CPU 核数 × 2~4，超过后性能反而下降。
单 Pod 的连接池建议 10~20，靠多 Pod 横向扩展。

---

七、二期/三期演进路径

触发条件	演进动作
只读副本 CPU > 70%	增加只读副本
主库 CPU > 50% 持续	读写分离细化（C 端走副本）
报表拖慢主库	引入 ClickHouse / AnalyticDB
单库 > 2TB	按 tenant_id 分库（ShardingSphere）
单个大租户资源占用过高	该租户迁独立库（isolation_mode 已预留）
商城/直播上线	独立集群 + 独立库，与主业务物理隔离

分库的技术前提（现在就要准备）：

1. 所有表必须有 tenant_id（已满足）
2. 所有查询必须带 tenant_id（RLS 已强制）
3. 避免跨租户 JOIN（当前设计已避免）
4. 分布式 ID 生成（当前用 bigint identity，分库时需改雪花 ID）
5. 分布式事务方案确定（建议：避免跨库事务，用 Saga/最终一致）

第 4 点是个隐患：当前主键用 GENERATED ALWAYS AS IDENTITY，
分库后会冲突。建议一期就引入雪花 ID 或号段分配，
避免分库时大规模改主键。这是我在本设计中要提醒的改进项。

---

配套：../分布式架构/01-阿里云分布式架构.md