给飞驰的法拉利换引擎 - 谈边做业务边做架构重构(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个人负责一个或者多个系统,思考难免有遗漏,容易出问题。

相关文章
|
9天前
|
机器学习/深度学习 数据处理 数据安全/隐私保护
|
9天前
|
存储 边缘计算 人工智能
云计算与分布式系统架构:驱动数字化时代的创新引擎
本文将探讨云计算与分布式系统架构在数字化时代中的重要性,介绍其基本概念和原理,并探讨其在推动技术创新、提升企业效率和满足用户需求方面的作用。同时,还将提出未来发展的趋势和挑战,为读者提供对云计算与分布式系统架构的深入理解。
|
7月前
|
安全 持续交付 开发者
Docker 架构解析:多角度解析 Docker 引擎与容器运行时
Docker 架构解析:多角度解析 Docker 引擎与容器运行时
58 0
|
7月前
|
持续交付 虚拟化 Docker
Docker 架构解析:理解 Docker 引擎和容器运行时
Docker 架构解析:理解 Docker 引擎和容器运行时
546 1
|
9天前
|
存储 Dragonfly NoSQL
Tair 对 Redis 引擎架构之争的看法
本文详细讲解了阿里云自研数据库Tair的发展以及介绍。
73373 1
|
9月前
|
运维 负载均衡 关系型数据库
【运维知识进阶篇】用Ansible Roles重构LNMP架构(Linux+Nginx+Mariadb+PHP),实现4个项目一键部署
【运维知识进阶篇】用Ansible Roles重构LNMP架构(Linux+Nginx+Mariadb+PHP),实现4个项目一键部署
118 0
|
9天前
|
SQL 关系型数据库 MySQL
Presto【基础 01】简介+架构+数据源+数据模型+特点(一篇即可入门支持到PB字节的分布式SQL查询引擎Presto)
Presto【基础 01】简介+架构+数据源+数据模型+特点(一篇即可入门支持到PB字节的分布式SQL查询引擎Presto)
65 0
|
9月前
|
人工智能 并行计算 安全
国内首个政务领域 Web 引擎 SIG 成立!龙蜥联合儒特科技打造全新一代 Web 架构
龙蜥社区联合儒特科技成立的 Web 引擎 SIG 组,表明了龙蜥对前沿尖端技术探索的前瞻性。
|
10月前
|
存储 弹性计算 运维
互娱NoSQL架构优化 —— 暨MongoDB“在线换引擎”技术服务指南”
XX工作室是某大客户核心游戏工作室,其核心业务是国内二次元RPG手游,采用实时开放世界对战模式,整体采用阿里云方案,本次专项攻坚主要对于玩家在游戏期间各类游戏属性交互(包含过图、物品、面板、剧情等)的核心业务模块进行优化,其中涉及NoSQL部分由于在专项优化期间存在诸多细节,特此提炼出来给各位有类似互娱业务场景进行参考。
|
10月前
|
JSON 缓存 API