架构重构比全新设计难在三点

系统的架构是不断演化的，少部分架构演化需要推倒重来进行重写，但绝大部分架构演化是通过架构重构来实现的。相比全新的架构设计，架构重构对架构师的要求更高，主要体现在三点：第一，业务已经上线，不能停下来——架构重构时业务已经上线运行，重构既要尽量保证业务继续往前发展，又要完成架构调整，这就好比”给飞行中的波音747换引擎”；而如果是新设计架构，业务还没上线，即使做砸了对业务也不会有太大影响。第二，关联方众多，牵一发动全身——架构重构涉及的业务关联方很多，不同关联方的资源投入程度、业务发展速度、对架构痛点的敏感度都有很大差异，如何尽量减少对关联方的影响、或协调关联方统一行动，是一项很大的挑战；而新设计架构在上线前对关联方没有影响。第三，旧架构的约束——架构重构需要在旧架构基础上进行，这是很强的约束，会限制架构师的技术选择范围；而新设计架构的技术选择余地大得多。即使决定推倒重来、完全抛弃旧架构去设计新架构，新架构依然会受旧架构约束和影响，因为业务在旧架构上产生的数据不能推倒重来，新架构必须考虑如何把旧架构产生的数据转换过来。正因如此，架构重构对架构师的综合能力要求非常高：业务上要能说服产品经理暂缓甚至暂停业务来配合重构；团队上要能与其他团队达成一致的重构计划和步骤；技术上要给出让技术团队认可的重构方案——既要说得动老板，也要镇得住同事，既要技术攻关又要协调资源，既要保证业务正常发展又要在指定时间内完成目标。

结构图：

flowchart TB
  A["架构重构 vs 全新架构设计"]
  A --> B["难点①业务不能停<br/>好比给飞行中的波音747换引擎"]
  A --> C["难点②关联方众多，牵一发动全身<br/>各方投入/节奏/痛点敏感度差异大"]
  A --> D["难点③受旧架构约束<br/>即使推倒重来，旧数据也无法推倒重来"]
  B --> E["要求架构师：<br/>说服业务方+协调团队+技术攻关三线作战"]
  C --> E
  D --> E