架构重构内功心法第一式：有的放矢

相比全新的架构来说，架构重构对架构师的要求更高，主要体现在：

• 业务已经上线，不能停下来
• 关联方众多，牵一发动全身
• 旧架构的约束
  因此架构重构对架构师的综合能力要求非常高，业务上要求架构师能够说服产品经理暂缓甚至暂停业务来进行架构重构；团队上需要架构师能够与其他团队达成一致的架构重构计划和步骤；技术上需要架构师给出让技术团队认可的架构重构方案。
  总之，架构重构需要架构师既要说的住老板，也要镇得住同事；既要技术攻关，又要协调资源；既要保证业务正常发展，又要在指定时间内完成目标…总之就是十八般武艺要样样精通。
  通常情况下，当系统架构不满足业务的发展时，其表现形式是系统不断出现各种问题，轻微一点的如系统响应慢、数据错误、某些用户访问失败等，严重的可能宕机、数据库瘫痪、数据丢失等，或者系统的开发效率很低。开始的时候技术团队只针对具体的问题去解决，解决一个算一个，但如果持续时间较长，例如持续了半年甚至一年都不见好转，此时有人想到了系统的架构是否存在问题，讨论是否是因为架构原因导致了各种问题。一旦确定需要进行架构重构，就会由架构师牵头来进行架构重构的分析。
  当架构师真正开始进行架构重构分析时，就会发现自己好像进了一个迷雾森林，到处都是问题，每个问题都需要解决，不知道出路在哪里，感觉如果要解决所有这些问题，然后汇总成一个100行的Excel表格，看到这样一个表格就蒙了：这么多问题，要到猴年马月才能解决完？
  期望通过架构重构来解决所有问题当然是不现实的，所以架构师的首要任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有问题。否则就会陷入人少事多头绪乱的处境，团队累死累活弄个大半年，最后发现好像什么都做了，但每个问题都依然存在。尤其是对于刚接手一个新系统的架构师或技术主管来说，一定要控制住“新官上任三把火”的冲动，避免摊大饼或者运动式的重构和优化。

重构案例

1、数据重构

M系统是一个后台管理系统，负责管理所有游戏相关的数据，重构的主要原因是因为系统耦合了P业务独有的数据和所有业务公有的数据，导致可扩展性比较差。其大概架构如下：

针对M系统存在的问题，重构的目标就是将游戏数据和业务数据拆分，解开两者的耦合，使得两个系统都能独立快速发展。重构的方案如下图所示。

重构后的效果非常明显，重构后的M系统和P业务后台系统每月上线版本数是重构前的4倍！

2、业务系统融合的重构

X系统是创新业务的主系统，之前在快速尝试和快速发展期间，怎么方便怎么操作。怎么快速怎么做，系统设计并为投入太多精力和时间，很多东西都塞到一个系统中，导致到了现在已经改不动了。做一个新功能或者新业务，需要花费大量时间来讨论和梳理各种业务逻辑，一不小心就踩个大坑。X系统的架构如下图所示。

X系统的问题和M系统比较类似，都是可扩展性存在问题，但其实根本原因不一样：M系统是因为耦合了不同业务的数据导致系统可扩展性不足，而X系统是因为将所有的功能都放到同一个系统中导致可扩展性不足；同时，所有功能都在一个系统中，也可能导致一个功能出问题，整站不可用。比如说某个功能把数据库拖慢了，整站所有业务跟着都慢了。
针对X系统存在问题。重构目标是将各个功能拆分到不同的子系统中，降低单个系统的复杂度。重构后的架构如下图所示（仅仅是示例，实际架构远比下图复杂）

重构后各个系统通过接口交互，虽然看似增加了接口的工作量，但整体来说，各系统的发展就比较易于扩展，而且影响也降低了许多。
这三个系统重构的方案，现在回过头来看，感觉是理所当然的，但实际上当时做分析和决策时，远远没有这么简单。以M系统为例，刚接手时遇到问题很多，如：

• 数据经常出错
• M系统是单机，单机宕机后所有后台操作就不能进行了。
• 性能比较差，有的操作耗时好久。
• 界面比较丑，操作不人性化。
• 历史上经过几手转接，代码比较混乱。
• 业务数据和游戏数据耦合，开发效率很低。
  从这么多问题中识别出重构的目标，并不是一目了然的；而如果想一下解决所有问题，人力和时间又不够！所以架构师需要透过问题表现看到问题本质，找到真正需要通过架构重构解决的核心问题，从而做到有的放矢，既不会浪费大量的人力和时间投入，有能解决核心问题。这对架构师的分析和判断能力要求非常高，既不能看到问题就想到架构重构，也不能只是针对问题进行系统优化。判断到底是采取架构重构还是系统优化，可能不同的架构师和团队有不同的看法。这里分享一个简单的做法：假设我们需要从0开始设计当前系统，新架构和老架构是否类似？如果差异不大，采用系统优化即可，如果差异较大，采取系统重构。