从西直门立交桥谈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次方可以交叉选择的方案 如何多变量求解

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

问：重构时模式用的多吗

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

问：这期间你需要了解业务，梳理业务流程吗？

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

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

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