Arch Day 138
Arch Day 138: 云迁移策略 — 7R、Strangler Fig与大型机现代化
云迁移不是"把服务器搬到云上"，而是一次重新审视应用架构、优化运营模式的战略机会。选择正确的迁移策略(7R)决定了投入产出比。
2026-08-15
第五阶段 - 云架构深度云迁移7RStranglerFig大型机BluAge数据库迁移
日期: 2026-08-15 (Day 138) 阶段: 第五阶段 - 云架构深度 标签: #云迁移 #7R #StranglerFig #大型机 #BluAge #数据库迁移
核心概念
一句话定义
云迁移不是"把服务器搬到云上"，而是一次重新审视应用架构、优化运营模式的战略机会。选择正确的迁移策略(7R)决定了投入产出比。
知识点详解
1. 7R迁移策略
| 策略 | 描述 | 风险 | 周期 |
|---|---|---|---|
| Rehost | 原样搬迁 | 低 | 周 |
| Replatform | 用托管服务替换部分组件 | 中低 | 月 |
| Refactor | 云原生重构 | 高 | 季度 |
| Rebuild | 完全重新设计 | 最高 | 半年+ |
| Replace | SaaS替代 | 中 | 月 |
| Retain | 保留本地 | 低 | — |
| Retire | 淘汰 | 最低 | — |
2. 数据库零停机迁移（5阶段）
| 阶段 | 活动 | 时长 |
|---|---|---|
| Preparation | Schema分析、工具选择 | 1-2周 |
| Bulk Load | 并行加载历史数据 | 1-10天 |
| CDC | 实时变更同步(<1-5s延迟) | 持续 |
| Dual Write | 双写确保一致性 | 迁移期间 |
| Cutover | 渐进式读流量切换 | 数小时到数天 |
工具：Debezium+Kafka(开源)、AWS DMS(托管)、pgloader(PG迁移)
3. Strangler Fig Pattern + Service Mesh
增量式替换旧系统：
- Istio/Envoy做流量分配（新旧服务按百分比路由）
- Canary发布逐步迁移流量
- Feature flag控制进度，随时回滚
4. 大型机现代化
驱动因素: 71%大型机团队人手不足，COBOL外包$250+/小时
AWS Blu Age: COBOL→Java Spring Boot自动转换，**85-95%**自动化
重要变更: AWS Migration Hub Refactor Spaces 2025.11停止新客户；AWS Transform(AI驱动)取代旧版
5. 迁移反模式
| 反模式 | 后果 | 正确做法 |
|---|---|---|
| 一次性"大爆炸"迁移 | 风险集中，回滚困难 | 分批迁移，每批验证 |
| 只做Rehost不优化 | 云上成本更高 | Rehost后规划Replatform |
| 忽略数据迁移 | 迁移失败主因 | 数据迁移先行，充分测试 |
| 跳过性能基线 | 无法验证迁移后性能 | 迁移前建立性能基线 |
面试题
问题：如何为一个运行15年的核心银行系统制定迁移策略？
回答：1) 评估：识别所有依赖，建立性能基线；2) 外围先行：非核心系统(报表/管理后台)先Rehost/Replace；3) 核心系统Strangler Fig：新功能用微服务，通过API Gateway路由，逐步替换旧模块；4) 数据层：DMS做CDC实时同步，双写验证；5) 最后切换：预留回滚窗口。