从西直门立交桥谈IT架构与重构

APM 产品的架构与研发。崇尚敏捷,高效,GettingReal。


今天主要跟大家分享的,是近几年来我在网站、应用、信息系统等方面,架构与重构的一些经验与心得。

架构,在普通技术人员眼里,是一个貌似很神秘的职业,感觉就像一群神秘武者,在从事着一些很神秘的工作,用一些貌似很深、很奇的东西,来让一些看似腐朽的项目或应用,产生一些微妙的变化。

而对于重构,相对于架构来说,则更加的隐忍、更加让人难以捉摸。让我们从一张图片开始。

没错,这张很美的夜景,是北京,西直门立交桥。它是我国立交桥建筑史上的一座里程碑。

但同时,它也是一朵奇葩。

大家注意看,左下角向右上角,方向是自西向东的,如果我要从左下,到右下,也就是自西向南行驶,大家觉得,应该怎么走?不卖关子,直接看答案吧。

绿色的线路是我们期望的行驶路线,而黄色线路,才是现实中的行驶路线。 也就是我们需要从西向东下桥,然后自南向北上桥,然后自东向西再下桥,然后自北向南,到达我们的方向。不是北京的司机,想从桥上下来,是很困难的。其实很多北京司机,也会在这里晕掉。但是,它却是一个非常棒的设计。

为什么这样讲?

OK,我们来分析一下这座立交桥的用户,或受众。

很明显,对于这座桥,最容易想到的,有两个用户:行驶中的司机、指挥的交警。对于行驶中的司机来讲,这明显不是一个优秀的设计:

1、不直接、容易晕菜;

2、哪个弯没转对,很难再回到原来的道路;

3、不可控制。

但对于交警(或交管部门)来讲,这明显是一个非常优秀的设计:

1、这里不需要交警,也不需要红路灯,节省了资源;

2、由于全是单行道,不必掉头和对流,降低了事故率。

当然,立交桥的设计者,也就是这次实例的架构者。

关于架构,这是我想分享的一个点:

优秀的架构,大多数是与业务无关的,如果从业务的角度来完成一次架构,很容易失败。

我们再来看另外一个图片:

照片上是一座危楼。楼与旁边的院墙,明显已经破败不堪。用很多大小粗细不一的木棍或支柱在做支撑。很多网站或应用,其实就像这座危楼,虽然已经破败不堪,但仍然有很多业务在里面持续地服务着,就像依然有很多居民会在里面居住。他们无奈、疲惫、很不开心,但有新需求产生时,仍然可能要增加更多的棍子或支柱,来支撑这座危楼。当网站或应用,已经到了让开发者、运营者、运维者,感觉无奈、疲惫时,重构的时机到来了。

架构师在对应用进行重构时,首先要考虑哪些点呢?

首先,不应该是对网站结构进行重新构建、把很多功能更优秀、更牛逼的组件加入进来吗?

我要分享的是,在进行一次重构之前,千万不要这么想。

脑子不能热,我们不是在钢铁侠,可以一手托起一座城市。

我们也不是极客,牛逼、优秀的组件,就算能掌控得了,也不能组合得好。

在重构时,着先要考虑的,是旧楼里的居民。也就是旧应用中的业务。

原因是:

1、如果不考虑旧业务,而进行重构,跟一个新项目有什么区别呢?

2、旧业务在不停地迭代,如果要做新的架构,什么时候可以追得上来业务?

从我成功进行重构了几个巨型应用项目的经验来看,我的做法不一定是正确的,但却是切切实实可行的:

1、 这座危楼已经有了非常多支撑点(bug、业务补丁、流程补丁),而让项目的迭代和维护举步维艰,那么应该先找这些支撑点进行分析,把相近的支撑点进行分组和整合

2、将这些已经梳理好的支撑点,一组一组进行隔离(把业务解藕、把连带风险降低)

3、把已经进行隔离好的支撑点,一个一个拿来进行深度解析(分清流程、层次、与关键点)

4、将支持点进行规范化的重构与替换(逐个重构,最终完成基础结构的重构)

形象一点讲:

重造一座优秀的建筑,是很完美的,但会让所有人都更加疲惫;

而将一座危楼的破旧部分作为基石,把它有机制地打碎重组,最终成为新建筑最牢固的地基,一次重构才是成功的。

提问:


问:我认为架构必须考虑业务?否则很容易出现过度设计或者设计缺失

答:业务是应该要考虑的。但也不能过多了考虑,因为很可能会成为定制,而导致后期的不可扩展。

问:个人觉得架构和业务的关系很大,为什么说无关?

答:我认为的是,架构,是从业务开始,但最终决定架构的,其实是与业务无关的部分。

问:软件开发有句话很著名,就是没有银弹,考虑业务是为了弹性和扩展,并不会限制,重构的开始,可以从82法则开始。先找出那20%影响80%的地方

答:业务总是有着这样那样的条件,而这些条件,如果一旦成为架构的决定部分,则容易丢失架构原本的意图。

问:在业务与非业务之间,确实不好拿捏

答:嗯。有过这样一句话:架构靠业务,重构重功力。我非常认同后半句。

问:在架构领域里面,其实是分企业架构和技术架构的。我想你想更多的表达纯粹的技术架构。但是,其实,技术架构还是会被业务影响的,而且有时候影响很大

答:是的。我讲的是技术架构,不是业务架构。

问:可否举个印象最深的参与的客户重架构的例子,最大挑战,和如何梳理如何解决的

答:具体哪个企业就不提名了啊。  由于历史原因(人员、时间等),一个项目非常快地成功起来了,而且每年稳定盈收3亿元以上,但所有研发人员与运维人员早已不堪重负。代码结构混乱、耦合过重,我切实读过其中的一些结构和逻辑,一坨一坨,牵一发动全身,任何一个小的bug,都会搞一周才能fix甚至更久。项目到后来无法维护,业务更不能满足。  最后,在我的建议和带领下,研发部门组建了重构组,由两名架构师、一名安全顾问、一名数据顾问和N名程序员组成。首先梳理项目中的资源蓝图、结构蓝图、流程蓝图,然后选中其中一个最不起眼的流程,隔离层块与资源,然后对它进行深度的分析,找到症结点,并使用新的架构进行SOA,最终完成了这一个模块。然后历经数个模块的重构。整个项目脱胎换骨。

问:一个架构下 有2的n次方可以交叉选择的方案 如何多变量求解

答:在众多交叉选择的方案中,如果能选出一个离业务最相近,同时有随时可“掉头”可能性的方案,那就选择它;  如果仍然有多个方案,那么做好充分的准备,然后选最轻量的那个方案开始快速试错。

问:重构时模式用的多吗

答:嗯,模式不可或缺会使用,但目的一定要明确。资源、代码、流程,都会有很多模式可重用,这些模式的使用者和受益者,都是人,管理者、开发者、运维运营者,因此,对人友好是首要的。

问:这期间你需要了解业务,梳理业务流程吗?

答:无论架构或重构,对业务都是需要充分理解的。

问:重构分布式系统,往往牵扯太多,感觉需要及时重构

答:嗯,分布式系统是最难把控的。可以使用一些工具或服务来充分了解自己的系统。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值