给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(4)—— 文武双全

标签: 架构设计架构重构架构师
6023人阅读 评论(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就不做技术的氛围下,更加需要对技术的热爱和不断的追求,同时要有比较好的机遇,才能够成长为真正的架构师。


 对应到X系统的案例,我个人的经验就是7+-2原则,也就是说将系统拆分为5 ~ 9 个人能够维护的粒度,也就是说假如你的团队有20人,拆分成3 ~ 5个系统是比较合适,即使再拆的更细,最低要保证3个人负责一个系统的粒度,如果出现一个人负责1个系统,甚至一个人要负责多个系统,就说明拆的太细了,会带来很多问题。

为何按照这个原则来拆分呢?科学研究证明,人脑同时关注的目标大约就是7+-2个,对于一个9个人负责的系统来说,每个人基本上都可以覆盖到系统的所有方面,如果20个人才能维护一个系统,说明1个人可能要关注20个点,但人很难关注这么多的点的。

其次为何至少要3个人负责一个系统呢?这是从团队管理的角度出发的,如果2个人甚至1个人负责一个系统,首先是人员没有足够备份,一个人请假或者变动,整个系统的效率就要受到影响;其次如果1个人负责一个或者多个系统,思考难免有遗漏,容易出问题。

================================================================================================

本文原创发表于CSDN和云栖社区,转载请注明出处:

CSDN:给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(4)—— 文武双全 

云栖:给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(4)

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:840707次
    • 积分:10524
    • 等级:
    • 排名:第1568名
    • 原创:139篇
    • 转载:5篇
    • 译文:9篇
    • 评论:787条
    博客专栏
    友情链接