【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
1. 引言
前面讲了那么多，看起来都是和项目管理相关的的，例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。。。。。架构师怎么变成了项目经理了，说好的技术呢？
真正的架构师，当然必须具备一定的项目经理技能，但更重要的还是技术能力，道理很简单：再好的饼，最后实现不了，都是扯淡！我将“项目管理能力”称之为“文”的能力，“技术能力”称之为“武”的能力，架构师必须文武双全，才能最终把事情搞定！
2. 文武双全
架构师的“武”体现在很多方面，既有微观层面的，例如如何设计一个高性能的并发框架（可以参考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就不做技术的氛围下，更加需要对技术的热爱和不断的追求，同时要有比较好的机遇，才能够成长为真正的架构师。
3. 小结
对应到X系统的案例，我个人的经验就是7+-2原则，也就是说将系统拆分为5 ~ 9 个人能够维护的粒度，也就是说假如你的团队有20人，拆分成3 ~ 5个系统是比较合适，即使再拆的更细，最低要保证3个人负责一个系统的粒度，如果出现一个人负责1个系统，甚至一个人要负责多个系统，就说明拆的太细了，会带来很多问题。
为何按照这个原则来拆分呢？科学研究证明，人脑同时关注的目标大约就是7+-2个，对于一个9个人负责的系统来说，每个人基本上都可以覆盖到系统的所有方面，如果20个人才能维护一个系统，说明1个人可能要关注20个点，但人很难关注这么多的点的。
其次为何至少要3个人负责一个系统呢？这是从团队管理的角度出发的，如果2个人甚至1个人负责一个系统，首先是人员没有足够备份，一个人请假或者变动，整个系统的效率就要受到影响；其次如果1个人负责一个或者多个系统，思考难免有遗漏，容易出问题。
来源：oschina
链接：https://my.oschina.net/u/2858189/blog/753019