给飞驰的法拉利换引擎 - 谈边做业务边做架构重构
摘要： 序言 对一个程序员来说，世界上最痛苦的事情是什么呢？ 有的人会说：编码的时候产品改需求！ 有的人会说：看别人不知所云的代码！ 有的人会说：定位一个百年不遇千年难寻的线上不定时偶尔出现的bug！ 有的人会说：找不到女（男）朋友！ 。
序言
对一个程序员来说，世界上最痛苦的事情是什么呢？
有的人会说：编码的时候产品改需求！
有的人会说：看别人不知所云的代码！
有的人会说：定位一个百年不遇千年难寻的线上不定时偶尔出现的bug！
有的人会说：找不到女（男）朋友！
。。。。。。。。。。。。。。。。。。。。。。。。。。
但 我要说，这些痛苦其实都不算什么，要么是多花点时间去解决（比如说改需求、看代码），要么是多花点心思（比如说找另一半、定位疑难bug），而我接下来说 的这个事情才是最痛苦的，既要说得动老板，也要镇得住同行；既要技术攻关，又要协调资源；既要保证业务正常发展，又要在指定时间内完成目标。。。。。。总 之就是十八般武艺要样样精通。
这个事情就是“架构重构”，比“架构重构”还要痛苦的就是“边做业务边架构重构”！我们的产品形象的形容为“给飞驰的法拉利跑车换引擎”，为何这样说呢？
首先：业务不能停，不能为了架构重构而终止业务的开发，将法拉利停下来换引擎，别人都跑远了；
其次：业务不能出问题，不能因为架构重构导致业务无法运行，法拉利修出问题跑不了，别人也跑远了；
第三：要根本解决问题，而不是修修补补，不是给法拉利引擎加点油，清洁一下就可以了，而是要换上新的引擎。
巧合的是，我加入UC后到现在已经做了3个系统的架构重构了（戏称“救火队长”），而且每个系统的特点都不一样，过程中各种各样的问题都遇到过，坑也踩过，也积累了一些经验。接下来就给大家分享一下。
【有的放矢】
我接手的第一个系统是一个后台系统，负责管理整个阿里游戏的游戏相关的数据（以下简称M系统），重构的主要原因是因为系统耦合了P业务独有的数据和所有业务公用的数据，导致可扩展性比较差。其大概架构如下：
举一个最简单的例子：数据库中的某张表，一部分字段是所有业务公用的“游戏数据”，一部分字段是“P业务系统”独有的数据，开发的时候如果要改这张表，代码和逻辑都很复杂，改起来效率很低。
针对M系统存在的问题，我们的重构目标就是将游戏数据和业务数据拆分，解开两者的耦合，使得两个系统都能够独立快速发展。
重构的方案如下：
重构后的效果非常明显，重构后的M系统和P业务后台系统每月上线版本数是重构前的4倍！
我 接手的第二个系统，是负责游戏接入的核心系统（以下简称S系统）。S系统是游戏接入的核心系统，一旦S系统故障，大量游戏玩家就不能登录游戏，而S系统并 不具备多中心的能力，一旦主机房宕机，整个S系统业务就不可用了。其大概架构如下，可以看出数据库主库是全局单点，一旦数据库主库不可用，两个集群的写业 务都不可用了：
针对S系统存在的问题，我们的重构目标就是实现双中心，使得任意一个机房都能够提供完整的服务，在某个机房故障的时候，另外一个机房能够全部接管所有业务。
重构方案如下：
重构后系统的可用性从3个9提升到4个9，重构前最夸张的一个月有4次较大的线上故障，重构后虽然也经历了机房交换机宕机、运营商线路故障、机柜断电等问题，但对业务都没有什么大的影响。
我 接手的第三个业务系统，是属于创新业务（以下简称X业务）。由于是创新业务，之前的业务快速尝试和快速发展期间，怎么方便怎么操作，怎么快速怎么做，系统 设计并未投入太多精力和时间，很多东西都塞到同一个系统中，导致到了现在已经改不动了，做一个新功能或者新业务，需要花费大量的时间来讨论和梳理各种业务 逻辑，一不小心就踩个大坑。X系统的架构如下：
X 系统的问题看起来和M系统比较类似，都是可扩展性存在问题，但其实根本原因不一样：M系统是因为耦合了不同业务的数据导致系统可扩展性不足，而X系统是因 为将业务相关的所有功能都放在同一个系统中，导致系统可扩展性不足；同时，所有功能都在一个系统中，也可能导致一个功能出问题，导致整站不可用。比如说某 个功能把数据库拖慢了，整站所有业务跟着都慢了。
针对X系统存在的问题，我们的重构目标是将各个功能拆分到不同的子系统中去，降低单个系统的复杂度。重构后的架构如下（仅仅是示例，实际架构远比下图复杂）：
重构后各个系统之间通过接口交互，虽然看似增加了接口的工作量，但整体来说，各系统的发展和开发速度比原来快了很多，系统也相对更加简单，也不会出现某个子系统有问题，所有业务都有问题。
这三个系统重构的方案，现在回过头来看，感觉是理所当然的，但实际上当时做分析和决策的时候，远远没有这么简单。
以M系统为例，当时我们接手后遇到的问题有很多，例如：
- 数据经常出错；
- M系统是单机，单机宕机后所有后台操作就不能进行了；
- 性能比较差，有的操作耗时好久；
- 界面比较丑，操作不人性化；
- 历史上经过几手转接，代码比较混乱；
- 业务数据和游戏数据耦合，开发效率很低。。。。。。
从这么多问题中识别出重构的目标，并不是一目了然的；而如果想一下全部解决所有的这些问题，人力和时间又不够！
所以架构重构首要的任务是从一大堆纷繁复杂的问题中识别出真正要通过架构重构来解决的问题，集中力量快速解决，而不是想着通过架构重构来解决所有的问题。 否则的话，就会陷入人少事多头绪乱的情况，团队累死累活弄个大半年，最后发现好像什么都做了，但每个问题都依然存在。尤其是对于刚接手一个新系统的架构师 或者技术主管来说，一定要控制住“新官上任三把火”的冲动，避免摊大饼式或者运动式的重构和优化，谨记“步子大了会扯到蛋”的教训 ！
那 原来发现的那些问题怎么办呢？当然不能放任不管。以M系统为例，我们在重构完成后，又启动了多个优化的项目去优化这些问题，但此时的优化主要是团队内部完 成即可，和其它团队没有太多关联，优化的速度是很快的。如果没有重构就进行优化的话，每次优化都要拉一大堆关联业务的团队来讨论方案，效率非常低下！