系统的架构是不断演化的，少部分架构演化可能需要推倒重来进行重写，但大部分的架构演化都是通过架构重构来实现的，相比全新的架构设计来说，架构重构对架构师的要求更高，主要体现在：
- 业务己经上线，不能停下来
架构重构时，业务己经上线运行了，重构既需要尽量保证业务继续往前发展，又要完成 架构调整，这就好比“给飞行中的波音 747 换引擎”；如果是新设计架构，业务还没有上线，则即使做砸了对业务也不会有什么影响 - 关联方众多， 牵一发动全身
架构重构涉及的业务关联方很多，不同关联方的资源投入程度、业务发展速度、对架构痛点的敏感度等有很大差异，如何尽量减少对关联方的影响，或者协调关联方统一行动， 是一项很大的挑战；如果是新设计架构，则在新架构上线前，对关联方没有影响 - 旧架构的约束
架构重构需要在旧的架构基础上进行，这是一个很强的约束，会限制架构师的技术选择 范围；如果是新设计架构，则架构师的技术选择余地大得多，即使是我们决定推倒重来，完全抛弃旧的架构，设计新的架构，新架构也会受到旧架构的 约束和影响，因为业务在旧架构上产生 的数据是不能推倒重来的，新架构必须考虑如何将旧架 构产生的数据转换过来
因此 ， 架构重构对架构师的综合能力要求非常高，业务上要求架构师能够说服产品经理暂缓甚至暂停业务来进行架构重构：团队上需要架构师能够与其他团队达成一致的架构重构计划和步骤；技术上需要架构师给出让技术团队认可的架构重构方案
总之，架构重构需要架构师既要说得动老板，也要镇得住同行； 既要技术攻关，又要协调资源；既要保证业务正常发展，又要在指定时间内完成目标…… 总之就是十八般武艺要样样精通
有的放矢通常情况下，系统架构不满足业务的发展的情况下，就会以各种形式出现问题，例如系统响应慢、数据错误、某些用户访问失败，严重了可能是宕机，数据库瘫痪、数据丢失等，亦或者系统的开发效率很低，然而期望通过架构重构来解决所有问题是不现实的，因此架构师首要任务就是从一大堆问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是一下子想解决所有问题
案例1-不合理的耦合
如图所示，M系统只负责管理游戏相关数据，但系统耦合了P业务的数据，但P业务是个独立系统，还耦合了其他业务的数据，针对于此类相似问题，重构的目标则是将游戏数据拆分出来，与P业务数据分离，使得两者能够快速独立发展
如图所示，不难看出数据库主库是全局单点，一旦数据库主库不可用，两个集群的写操作都不可用，此类相似问题的重构目标则是实现双中心，使得任意集群都能够提供完整的服务
如图所示，可以看出大量功能集中在了同一个系统X中，可扩展性不足，并且还可能导致一个功能出问题，整站不可用，例如某个功能将数据库拖慢了，整站所有业务都跟着变慢，因此重构目标是先将各个功能拆分到不同的子系统中，降低单个系统的复杂度
