本地为主、云为辅
核心系统与敏感数据留在本地，云上承担训练、测试与弹性扩容。这种形态改动小、合规压力低，适合监管要求明确、系统耦合深的行业；代价是弹性有限，云上资源更多是补充而非主力，扩容节奏仍受本地约束。
云为主、本地留敏感
大部分业务上云，只有敏感数据与关键算法留在本地，通过接口调用。灵活度高，但对网络质量与接口设计依赖大，需做好超时、重试与降级；否则一次链路抖动就会影响主流程，用户侧感受非常直接。
双活
两侧同时承载业务，按流量或用户分流。可用性高，代价是数据同步、冲突处理与运维复杂度显著上升，适合对连续性要求极高的场景；多数业务并不需要为此付出长期成本，主备往往已经够用，双活的代价要提前说清。
云上灾备
本地为主、云上保留可恢复副本，故障时切换。成本相对可控，但要定期演练恢复，否则备份可用性无从验证；还要明确恢复顺序与数据回补方式，避免恢复完成后发现数据对不上，反而引发新的争议。
与网络身份一起定
形态决定流量方向，流量方向决定网络与身份方案。先定形态再补网络，常出现跨侧调用绕行、权限重复建设的问题；三者应在同一轮设计里确定，并留出后续调整空间，否则每次业务变化都要动架构。
适用与不适用
适合谁
- 正在规划上云范围与顺序、已梳理系统依赖的企业
- 已有本地系统、需要弹性扩容的团队
- 要对多套候选架构做取舍的架构师
不适合谁
- 全部业务已在一个环境稳定运行的组织
- 网络与身份尚未梳理、无法评估集成成本的项目
典型场景
某制造集团计划把营销系统上云、生产系统留本地。架构组先画数据流向图，确认生产数据不出本地，再选择云为主、本地保留接口的形态。同步方案只做单向汇总，避免双向冲突，网络按调用峰值预留带宽，上线前用一条业务线做了两周验证。
可执行步骤
- 画出系统清单与数据流向图，标出每类数据的产生与消费位置，避免遗漏系统
- 标出必须留在本地的系统与数据，请业务与安全共同确认并留档，形成书面结论
- 按业务连续性要求选择形态，比较主备、双活与灾备的代价，明确取舍理由
- 同步确定网络、身份与监控方案，避免后期补丁式建设，争取一次设计到位
- 用小范围业务验证后再推广，记录问题与调整措施，形成验证报告，并留档备查
常见坑
- 只定机房位置，不定流量方向，集成阶段反复改方案，工期一再顺延，业务方逐渐失去耐心，进度随之被拖慢。
- 双活未设计冲突处理，数据不一致时难以追责，业务方逐渐失去信任，后续推广阻力很大，责任难以界定。
- 灾备只做备份不演练，真故障时无法按时恢复，恢复目标形同虚设，检查时也拿不出证据，恢复能力无从验证。
- 忽略身份体系，跨侧权限重复建设，离职回收遗漏形成越权入口，审计时难以解释，整改往往牵连多个系统。
- 两套环境配置靠人工同步，版本逐渐分叉，同一问题在两处表现不同，排障时间成倍增加，回归范围也被放大。
自检与验收清单
- 系统清单与数据流向图是否完成并评审，是否经过评审
- 必须留本地的范围是否由业务与安全确认，是否有书面结论
- 形态是否与网络身份方案同步确定，责任是否划分
- 数据同步方向与冲突策略是否定义，是否有冲突策略
- 是否用小范围业务先行验证再推广，是否记录验证结果
常见问题
混合云是不是过渡方案？
对部分企业是过渡，对另一些是长期架构。监管要求、历史资产与业务耦合度决定其必要性，不必为了概念统一而强行收敛，也不应把混合当成永久不变的默认答案，组织能力也要跟上。
双活和灾备怎么选？
看可接受的停机时间与投入。双活切换快但复杂，灾备成本低但恢复需要时间。多数业务用灾备即可，核心交易类才考虑双活，还要评估团队是否具备相应的运维能力，不能只看切换速度。
上云顺序有建议吗？
通常先迁外围与新建系统，再考虑核心系统。核心系统迁移前要完成依赖梳理与回退方案，避免一次性大范围切换，把风险集中在同一时间段，也不要把所有团队的节奏绑在一起。