architecture，这个词在希腊语中意为"首席工匠"。建筑师的使命是将零散的砖石筑成雄伟殿堂，而架构师的职责是将纷繁的代码编织成卓越系统。然而，架构并非一劳永逸的杰作，而是需要不断演化的生命体。
系统的架构会随着业务发展而演进。绝大部分情况下，这种演进通过架构重构实现，而非推倒重来。但相比全新的架构设计，架构重构对架构师的要求更为严苛——这就好比在飞行中的飞机上更换引擎，而不是在停机坪上建造新飞机。
为何重构如此艰难？因为业务已经上线，必须继续前行；关联方众多，牵一发动全身；旧架构的约束如影随形，限制了技术选择的自由。这些挑战要求架构师既要说动老板、镇住同事，又要做技术攻关、协调资源——十八般武艺，样样精通。
但不要被困难吓倒。真正的架构师，要在乱麻般的现状中找到线索，重新穿针引线，帮助业务腾飞。今天，我们来修炼架构重构内功心法的第一式：有的放矢。
当系统架构不满足业务发展时，表现形式多种多样：系统响应缓慢、数据错误、访问失败、宕机、数据库瘫痪、数据丢失、开发效率低下……
开始时，技术团队可能头痛医头、脚痛医脚，解决一个算一个。但如果这种情况持续半年甚至一年仍不见好转，团队开始讨论是否架构出了问题。
此时，架构师往往发现自己进入了迷雾森林——问题遍地、不知从何下手。有人搜集了100个问题，列成Excel表格，面对这样一份"清单"顿时懵了：这么多问题，要到猴年马月才能全部解决？
期望通过一次架构重构解决所有问题，这是不现实的。 架构师的首要任务是：从纷繁复杂的问题中识别出真正需要通过架构重构来解决的核心问题，集中力量快速解决，而不是试图解决所有问题。
否则，团队将陷入"人少事多头绪乱"的困境——累死累活大半年，最后发现什么都做了，但每个问题依然存在。
对于刚接手新系统的架构师或技术主管，尤其要警惕"新官上任三把火"的冲动，避免摊大饼式或运动式的重构和优化。
M系统是一个后台管理系统，负责管理所有游戏相关的数据。问题的根源是：系统耦合了P业务独有的数据和所有业务公用的数据，导致可扩展性极差。
举例来说：数据库某张表，一部分字段是所有业务公用的"游戏数据"，一部分是P业务系统独有的数据。开发人员修改这张表时，代码和逻辑变得异常复杂，效率极低。
重构目标：将游戏数据和业务数据拆分，解开两者的耦合，使两个系统都能独立快速发展。
重构效果：M系统和P业务后台系统的每月上线版本数是重构前的4倍！
S系统是游戏接入的核心系统。一旦S系统故障，大量游戏玩家无法登录。更严重的是，S系统不具备多中心能力，主机房宕机则整个业务不可用。
架构中，数据库主库是全局单点——一旦数据库主库不可用，两个集群的写业务全部瘫痪。
重构目标：实现双中心，任意一个机房都能提供完整服务，某个机房故障时另一个机房能全部接管。
重构效果：系统可用性从3个9提升到4个9，重构前最夸张的一个月有4次较大线上故障，重构后经历了机房交换机宕机、运营商线路故障、机柜断电等问题，但对业务都没有大的影响。
X系统是创新业务的主系统。在快速尝试和快速发展阶段，怎么方便怎么来，怎么快速怎么做，系统设计投入不足，很多功能都"塞"进同一个系统。
现在，系统已经改不动了：做一个新功能或新业务，需要花费大量时间讨论和梳理各种业务逻辑，一不小心就踩个大坑。
重构目标：将各个功能拆分到不同的子系统，降低单个系统的复杂度。
重构效果：各系统之间通过接口交互，看似增加了接口工作量，但整体开发速度和系统简单性都大幅提升，不再出现一个子系统问题影响所有业务的情况。
这三个重构案例，当时做分析和决策时，远没有现在看起来那么简单。
以M系统为例，当时接手后遇到的问题有很多：
从这么多问题中识别出重构目标，并非一目了然。如果试图一次性解决所有问题，人力和时间都远远不够！
架构师需要透过问题表象看到问题本质，找出真正需要通过架构重构解决的核心问题。
这要求架构师具备高超的分析和判断能力：既不能看到问题就想着架构重构，也不能只做系统优化而回避根本性问题。
判断原则：假设我们现在需要从0开始设计当前系统，新架构和老架构是否类似？
非核心问题的处理：原有发现的问题不能放任不管。以M系统为例，重构完成后，团队又启动了多个优化项目来解决非重构问题。此时优化主要由团队内部完成，与其他团队关联少，效率极高。如果不重构就做优化，每次优化都要拉一堆关联业务的团队来讨论方案，效率极其低下。