给飞驰的法拉利换引擎 - 谈边做业务边做架构重构
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（1）
摘要： 序言 对一个程序员来说，世界上最痛苦的事情是什么呢？ 有的人会说：编码的时候产品改需求！ 有的人会说：看别人不知所云的代码！ 有的人会说：定位一个百年不遇千年难寻的线上不定时偶尔出现的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系统为例，我们在重构完成后，又启动了多个优化的项目去优化这些问题，但此时的优化主要是团队内部完成即可， 和其它团队没有太多关联，优化的速度是很快的。如果没有重构就进行优化的话，每次优化都要拉一大堆关联业务的团队来讨论方案，效率非常低下！
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（2）
摘要： 【合纵连横】 【合纵】 架构重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免的会影响业务功能的开发。因此，要 想真正推动一个架构重构项目启动，需要花费大
【合纵连横】
【合纵】
架构重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免的会影响业务功能的开发。因此，要想真正推动一个架构重构项目启动，需要 花费大量的精力进行游说和沟通。注意这里我不是指要谈办公室政治，而是指要和利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和争执。
道理很简单，但如何做才是关键！
一般的技术同学谈到架构重构的时候，就会搬出一大堆技术术语：可扩展性、可靠性、性能、耦合、代码很乱。。。。。。但以我的实际经验来看，如果和非技术同学这样沟通， 效果如同鸡同鸭讲，没有技术背景的同学很难理解，甚至有可能担心我们是在忽悠TA。例如：
技术同学说：我们系统现在的可扩展性太差了，改都改不动！
产品同学想：咦，可扩展性，和扩胸运动有关么？。。。。。扩展什么呢，怎么会改不动呢，不就是找个地方写代码嘛。。。。。。
技术同学说：我们的可靠性太差，现在才3个9，业界都是4个9！
项目经理想：啥是3个9，三九感冒灵？。。。。。。4个9和3个9不就是差个9嘛，和可靠有什么关系。。。。。。
技术同学说：我们系统设计不合理，A业务和B业务耦合！
运营同学想：咦，耦合，莲藕还是藕断丝连？。。。。。。A业务和B业务本来就是互相依赖的呀。。。。。。耦合为什么不合理呢？。。。。。
以上的样例并无嘲笑产品运营和项目同学不懂技术的意思，而是说明有的技术术语并不是很好理解，在跨领域沟通的时候，很难达成一致共识。
除此以外，在沟通时还经常遇到的一个问题是凭感觉而不是凭数据说话。比如说：技术同学说“系统耦合导致我们的开发效率很低”，但是没有数据，也没有样例，单纯这样说， 其他同学很难有直观的印象。
所以在沟通协调的时候，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键！
以M系统为例，我们把“可扩展性”转换为“版本开发速度很慢，每次设计都要考虑是否对门户有影响，是否要考虑对其它业务有影响”，然后我们还收集了1个月里面的版本情 况，发现有几个版本设计阶段讨论1周甚至2周时间，但开发只有2天时间；而且一个月才做了4个版本，最极端的一个版本，讨论2周，开发2天，然后等了1个月才和门户系 统一起上线，项目经理和产品经理一听都被吓到了。
以S系统为例，我们并没有直接说可靠性是几个9，而是整理线上故障的次数、每次影响的时长，影响的用户，客服的反馈意见等。。。。。。然后再拿其它系统的数据一对比， 无论是产品还是项目还是运营，明显就看出系统的可靠性有问题了。
当然，如果以上技巧还不奏效，或者遇到极端情况，那就要考虑一些更加有效的手段了！比如说我们遇到一个产品人员，他认为技术优化和架构重构是研发的事情，他不关注，安 排开发资源的时候也不考虑重构和优化的投入，要研发自己解决！没办法，只能上升到上级领导层面协调，甚至我们都放出狠话“如果你不同意安排资源进行优化，下次出故障我 们就说产品不给人力进行优化和重构”。
【连横】
除了以上讨论的和上下游沟通协调外，有的重构还需要和其它相关或者配合的系统的沟通协调。由于大家都是做技术的，有比较多的共同语言，所以这部分的沟通协调其实相对来 说要容易一些，但也不是说想推动就能推动的，主要的阻力来自“这对我有什么好处”和“这部分我这边现在不急”。
对于“这对我有什么好处”这个问题，有的人会简单理解为这是自私的表现，认为对方不顾大局，于是沟通的时候将问题人为拔高，例如“你应该站在部门的角度来考虑这个问题 ”、“这对公司整体利益有帮助”。。。。。。等等。这种沟通效果其实很差，首先是这种拔高一般都比较虚，没法明确，不同的人理解不一样，无法达成共识；其次是如果对公 司和部门有利，但对某个小组没用甚至不利，那么可能是因为目前的方案不够好，还可以考虑另外的方案。
那如何才能有效的推动呢？我们的策略是“换位思考、合作双赢、关注长期”。简单来说就是站在对方的角度思考，重构对他有什么好处，能够帮他解决什么问题，带来 什么收益。
以M系统为例，当时有另外一个C系统和M系统通过数据库直连共用数据库，我们的重构方案是要去掉两个系统同时在底层操作数据库，改为C系统通过调用M系统接口来写入数 据库。这个方案对C系统来说，很明显的一点就是C系统短期的改动比较大，要将10几个读写数据库的地方改为接口调用，刚开始C系统也是觉得重构对他们没有什么作用，后 来我们经过分析和沟通，了解到C系统其实也深受目前这种架构之苦，主要体现在“数据经常出错要排查”（因为C系统和M系统都在写同一个数据库，逻辑很难保证完全一致） ，“要跟着M系统同步开发”（因为M系统增加表或者字段，C系统要从数据库自己读取出来，还要理解逻辑）、“C系统要连两个数据库，出问题不好查”（因为C系统自己还 有数据库）。。。。。。这些问题其实在M系统重构后都可以解决，虽然短期内C系统有一定的开发工作量，但从中长期来看，C系统肯定可以省很多事情，例如：数据问题排查 主要是M系统的事情了，通过M系统的接口获取数据，无需关注数据相关的业务逻辑等等。通过这种方式沟通协调，C系统很乐意跟我们一起做重构，而且事实也证明重构后对C 系统和M系统都有很大好处。
当然如果真的出现了对公司或者部门有利，对某个小组不利的情况，那可能需要协调更高层
级的管理者才能够推动，平级推动是比较难的。
对于“这部分我们现在不急”这个问题，有的人可能会认为这是在找借口问题，我也不排除这种可能性。但就算真的是找借口，那也是因为大家没有达成一致意见，可能对方不好 意思直接拒绝。所以这种情况就可以参考上面“这对我有什么好处”这个问题的处理方法来处理。
如果对方真的是因为有其它更重要的业务，此时勉为其难也不好，还是那句话：“换位思考”！因为大部分重构的系统并不是到了火烧眉毛非常紧急的时候才开始启动的，而是有 一定前瞻性的规划，如果对方真的有其它更加重要的事情，采取等待的策略也未尝不可，但要明确正式启动的时间，例如3个月后开始、6月份开始，千万不能说“以后”、“等 不忙的时候”这种无法明确的时间点。
除了计划上灵活一点，方案上也可以灵活一点：我们可以先不做这个系统相关的重构，先把其它需要重构的做完。因为大部分需要重构的系统，需要做的事情很多，分阶段处理， 在风险规避、计划安排等方面更加灵活可控。
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（3）
摘要： 【运筹帷幄】一般来说，需要架构重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互 相作用，集中爆发！到了真正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下
【运筹帷幄】
一般来说，需要架构重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真 正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。
可以想象一下，假如我们拿到一个架构问题列表，其中有50个问题，那我们应该怎么去把这50个问题最终解决呢？
最简单的做法是每次从中挑一个解决，最终总会把所有的问题都解决。这种做法操作起来比较简单，但效果会很差，为什么呢？
第一个原因是没有区分问题优先级，所有问题都一视同仁，没有集中有限资源去解决最重要或者最关键的问题，导致最后可能出现做了大半年，回头一看好像做了很多事情，但没 取得什么阶段性的成果。
第二个原因是没有将问题分类，导致相似问题没有统筹考虑，方案可能出现反复，效率不高。
第三个原因是会迫于业务版本的压力，专门挑容易做的实施，到了稍微难一点的问题的时候，就因为复杂度和投入等原因被搁置，达不到真正重构的真正目的。
以X系统为例，在我加入前，其实也整理了系统目前存在的问题，大的项包括：可用性、性能、安全、用户体验等，每个大项又包括十几二十个子项。但是实施的时候基本上就是 挑软柿子捏，觉得哪个好落地、占用资源不太多，就挑来做，结果做了半年，好像做了很多功能，但整体却没什么进展。
我加入后成立了一个“X项目”，在原来整理的问题基础上，识别出架构和业务目前存在的主要问题是“可用性不高”和“可扩展性”不足，其中可用性不高有的原因是因为硬件 资源不够用了，或者某些系统组件使用不合理，有的是因为架构上存在问题；可扩展性不足主要原因是系统耦合比较严重，这同时也是可用性不高的一个原因。
基于这些分析，我们制定了总体的策略：
上图是去年7月份的时候制定的，目前已经完成第一阶段和第二阶段的工作，第三阶段因为实际问题比我们预想的更加复杂，加上其它因素，目前还在进行中。
为什么确定这样一个策略呢？主要还是为了集中有限的资源，某个阶段集中解决某一类问题。这样做首先是效率高，因为阶段目标比较明确，做决策和方案的时候无需太多选择； 其次是每个阶段都能看到明显的成果，给团队很大的信心。比如说第一阶段的“救火”，做完之后，系统很少因为机器过载、缓存响应慢、虚拟机挂死等问题导致的故障了；完成 第二阶段的事项后，因为组件、外部系统故障导致系统故障的问题也很少了。完成前两个阶段后，我们就可以安心的做第三阶段的“服务化”工作了。
S系统的重构做法也是类似，但S系统当时面临的主要问题就是可用性不高，并没有系统耦合的问题，所以我们当时的策略是“先救火、后优化、再重构”，“救火”阶段做了扩 容（防止资源不足导致系统被压死）和Nginx一键倒换功能（故障时快速切换）；优化阶段将一些明显的可用性问题解决（包括性能问题等）；重构阶段将原来的单点数据库 改为多中心。
总结一下重构的做法，其实就是“分段实施”，将要解决的问题根据优先级、重要性、实施难度等划分为不同的阶段，每个阶段聚焦于一个整体的目标，集中精力和资源 解决一类问题。这样做有几个好处：
1）每个阶段都有明确目标，做完之后效果明显，团队信心足，后续推进更加容易
2）每个阶段的工作量不会太大，可以和业务并行
3）每个阶段的改动不会太大，降低了总体风险
具体如何制定“分段实施”的策略呢？以下经验可以参考：
- 划分优先级
将明显且又比较紧急的事项优先落地，解决目前遇到的主要问题。例如扩容在S系统和X系统中都是最优先实施的，因为如果不扩容的话，系统隔三差五一会来个响应超时报警， 一会来个过载报警，一会来个大面积不可用。。。。。。这些问题耗费大量的人力和精力，也就没法做其它事情了。
- 问题分类
将问题按照性质分类，每个阶段集中解决一类问题。例如X系统的第二阶段，我们将多个底层系统切换到UC统一的公共组件，提升整体可用性。
- 先易后难
这点与很多人的直觉不太一样，有的人认为应该先攻克最难的问题，所谓的“擒贼先擒王”，搞定最难的问题后其它问题就不在话下。这样看起来很美好，但实际上不可行。
首先，一开始就做最难的部分，会发现要搞定这个最难的问题，要先搞定其它容易的问题；其次，最难的耗时都比较长，占用资源比较多，如果一开始做最难的，可能做了一两个 月还没有什么进展和成果，会影响相关人员对项目的评价和看法，也可能影响团队士气；
第三，刚开始的分析并不一定全面，所以一开始对最难的或者最关键的事项的判断可能会出错。
采取先易后难的策略，能够很大程度上避免“先难后易”策略的问题。
首先，随着项目的推进，一些相对简单的问题逐渐解决，会发现原来看起来很难的问题已经不那么难了，甚至有的问题可能都消失了；
其次，先易后难能够比较快的看到成果，虽然可能不大，但至少能看到一些成效了，对后续的项目推进和团队士气有很大好处；
第三，随着项目的进行，原来遗漏的一些点，或者分析和判断错误的点，会逐渐显示出来，及时根据实际情况进行调整，能够有效的保证整个重构的效果。
给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（4）
摘要： 【文武双全】前面讲了那么多，看起来都是和项目管理相关的的，例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。
【文武双全】
前面讲了那么多，看起来都是和项目管理相关的的，例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。。。。。架构师怎 么变成了项目经理了，说好的技术呢？
真正的架构师，当然必须具备一定的项目经理技能，但更重要的还是技术能力，道理很简单：再好的饼，最后实现不了，都是扯淡！我将“项目管理能力”称之为“文”的能力 ，“技术能力”称之为“武”的能力，架构师必须文武双全，才能最终把事情搞定！
架构师的“武”体现在很多方面，既有微观层面的，例如如何设计一个高性能的并发框架（可以参考Disruptor，大量的技术细节，例如CPU cache，cache line，false sharing等）；也有宏观层面的，例如采用HBase还是用MySQL存储；还有和业务相关的，例如某个功能应该 如何设计才能具备可扩展性。业务层面的相关的技术问题，如果没有相关的业务背景，讲起来比较费劲，也不好理解，这里就不展开了。我们讲讲这些重构项目中和业务无关的一 些技术。
我被问到的最多的问题其实也是宏观层面的。其中一个主要的问题是“这些系统的业务都不一样，你之前也没有类似业务背景，你怎么识别出M系统重构的目标是数据解耦，S 系统重构的目标是高可用呢，X系统重构的目标是系统解耦呢？”
秘密就在架构设计和重构其实是有一定的通用的“道”，不管什么业务，这个“道”都是适合的，详细的阐述可以参考我的博客专栏《BAT解密：互联网技术发展之路》，这里我提炼一下就是3个关键词：复杂度、性能、可 靠性，也就是说，架构设计或者重构的主要目标是解决业务在这三方面遇到的问题。
以M系统为例，重构前性能不高，且只有单机，但由于是后台系统，用户都是内部用户，每天就几百个人使用而已，所以还不是关键问题；关键问题是“不合理的耦合带来的复 杂性”：将特定业务的数据和所有业务的公共数据耦合在一起，数据正确性难以保证，且每次修改都是“牵一发动全身”，效率很低，所以重构的目标就是将“不合理的耦合”进行拆分。
而对S系统来说，前期团队在设计的时候已经基于业务进行了拆分，各个子系统职责比较明确，边界清晰，所以复杂度不是主要问题；每天访问量都是亿级以上，之前的架构设 计上已经考虑了多机房和平行扩容的能力，所以性能也不是主要问题。主要的问题就是有一个全局单点，一旦这个单点故障，就会导致所有业务全部不可用，而游戏相关业务可靠 性要求又非常高，只要有5分钟不可用，客服电话已经被玩家打爆了，论坛也都被刷爆。所以我们重构的目标就是解决“全局唯一单点”的可靠性问题。
X系统的情况更加特殊。首先存在和M系统相同的“复杂度”问题，只是表现形式不一样而已：M系统是数据耦合导致的复杂度增加，X系统是业务全部放到一个系统中实现导致 的复杂度增加。其次是存在和S系统类似的“可靠性”问题，也只是表现形式有所差别：S系统是全局单点导致可靠性问题，X系统是有问题就整站挂掉的可靠性问题。所以我们 最初在讨论X系统重构的时候是定了两个目标：解决复杂性和可靠性的问题，但随着对问题的分析逐步深入，我们发现如果不解决复杂性问题，可靠性问题是无论如何都解决不了 的。所以最终我们调整目标，将X系统的重构目标聚焦在将“大而全的系统拆分为多个分工合作的子系统”。
从上面的3个实例我们可以看到，其实只要掌握了架构设计的“道”，不管什么业务，在宏观层面的判断和决策都可以用这一套方法论去应对。
明白了架构设计和架构重构宏观层面的关键之“道”，我们来看看微观层面的“术”：即我们如何才能设计出一个方案来满足复杂度、可靠性、性能的需求呢？
说出来你可能不相信，架构设计或者架构重构有一把“屠龙宝刀”，复杂性、性能、可靠性都可以通过这一个方法去搞定。这把屠龙宝刀就是“拆”！
数据耦合？ 系统太庞大？—— 将系统“拆”分为多个子系统。。。。。。
性能比较低？—— 将一台机器“拆”为两台，两台不够“拆”为4台。。。。。。
可靠性不行？—— 单点“拆”分为集群，单机房“拆”为双机房。。。。。。
具体的做法可以参考我的博文《十年磨一剑之架构设计》。
到目前为止，看起来架构设计好像很简单：“复杂性，性能，可靠性，拆”，感觉随便一个人掌握了这4个关键字就可以做架构设计或者重构了。。。。。。看起来架构师也不 过如此嘛！其实不然，“道”是很简单，但面对具体问题、具体业务的时候，将“道”落地实现才是关键！
以X系统为例，将原有大而全的X系统拆分为多个子系统，关键不在于是否要拆，而是在于“怎么拆”。是拆分为2个呢，还是4个呢，还是10个呢？。。。。。。好像都可 以，那又怎么取舍？例如：
随便取一个？。。。。。。好像心里没谱！
发个微信红包看最大的红包整数？。。。。。。好像是碰运气，选错了怎么办！
现在不是流行微服务么，咱们拆的越细越好，参考淘宝，拆分为100个？。。。。。。你看研发和运维要不要打死你！
不知道就让老大拍板吧？。。。。。。是你做架构设计还是老大做架构设计！
找一群人来投票 ？。。。。。。大家都选拆分最少的投，因为这样工作量最少！
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
所以，“拆”的方向是没问题的，但“细节决定成败”，“如何拆”才是体现架构师能力的关键。要具备这样的能力，需要大量的实践、积累、思考、探索，因此要想成 为一个牛逼的架构师是很难的，尤其是在国内这种过了30就不做技术的氛围下，更加需要对技术的热爱和不断的追求，同时要有比较好的机遇，才能够成长为真正的架构师。
对应到X系统的案例，我个人的经验就是7+-2原则，也就是说将系统拆分为5 ~ 9 个人能够维护的粒度，也就是说假如你的团队有20人，拆分成3 ~ 5个系统 是比较合适，即使再拆的更细，最低要保证3个人负责一个系统的粒度，如果出现一个人负责1个系统，甚至一个人要负责多个系统，就说明拆的太细了，会带来很多问题。
为何按照这个原则来拆分呢？科学研究证明，人脑同时关注的目标大约就是7+-2个，对于一个9个人负责的系统来说，每个人基本上都可以覆盖到系统的所有方面，如果20 个人才能维护一个系统，说明1个人可能要关注20个点，但人很难关注这么多的点的。
其次为何至少要3个人负责一个系统呢？这是从团队管理的角度出发的，如果2个人甚至1个人负责一个系统，首先是人员没有足够备份，一个人请假或者变动，整个系统的效率 就要受到影响；其次如果1个人负责一个或者多个系统，思考难免有遗漏，容易出问题。