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

从西直门立交桥谈IT架构与重构2015年8月13日 PM 20:00 Neeke君从一个战场奔赴至另一个战场，回到办公室，打开电脑，登陆微信，精彩的的微社群分享马上就要开始了！大家好，我是Neeke，中文名高驰涛，PHP开发组成员，现在云智慧担任高级架构师，负责公司产品的架构与研发工作。目前云智慧旗下有两款产品，监控宝与透视宝。前者主要做骨干网监控和IT基础设施监控，后者主要做面向业务、端到端的一体化APM解决方案。附上分享者的个人简介：高驰涛（Neeke），云智慧高级架构师，PHP 开发组成员，同时也是 PECL/SeasLog的作者。8 年研发管理经验，早期从事大规模企业信息化研发架构，09 年涉足互联网数字营销领域并深入研究架构与性能优化。2014 年加入云智慧，致力于 APM 产品的架构与研发。崇尚敏捷，高效，GettingReal。今天主要跟大家分享的，是近几年来我在网站、应用、信息系统等方面，架构与重构的一些经验与心得。架构，在普通技术人员眼里，是一个貌似很神秘的职业，感觉就像一群神秘武者，在从事着一些很神秘的工作，用一些貌似很深、很奇的东西，来让一些看似腐朽的项目或应用，产生一些微妙的变化。而对于重构，相对于架构来说，则更加的隐忍、更加让人难以捉摸。让我们从一张图片开始。没错，这张很美的夜景，是北京，西直门立交桥。它是我国立交桥建筑史上的一座里程碑。但同时，它也是一朵奇葩。大家注意看，左下角向右上角，方向是自西向东的，如果我要从左下，到右下，也就是自西向南行驶，大家觉得，应该怎么走？不卖关子，直接看答案吧。绿色的线路是我们期望的行驶路线，而黄色线路，才是现实中的行驶路线。也就是我们需要从西向东下桥，然后自南向北上桥，然后自东向西再下桥，然后自北向南，到达我们的方向。不是北京的司机，想从桥上下来，是很困难的。其实很多北京司机，也会在这里晕掉。但是，它却是一个非常棒的设计。为什么这样讲？OK，我们来分析一下这座立交桥的用户，或受众。很明显，对于这座桥，最容易想到的，有两个用户：行驶中的司机、指挥的交警。对于行驶中的司机来讲，这明显不是一个优秀的设计：1、不直接、容易晕菜；2、哪个弯没转对，很难再回到原来的道路；3、不可控制。但对于交警（或交管部门）来讲，这明显是一个非常优秀的设计：1、这里不需要交警，也不需要红路灯，节省了资源；2、由于全是单行道，不必掉头和对流，降低了事故率。当然，立交桥的设计者，也就是这次实例的架构者。关于架构，这是我想分享的一个点：优秀的架构，大多数是与业务无关的，如果从业务的角度来完成一次架构，很容易失败。我们再来看另外一个图片：照片上是一座危楼。（照片上的帅哥不认识..）楼与旁边的院墙，明显已经破败不堪。用很多大小粗细不一的木棍或支柱在做支撑。很多网站或应用，其实就像这座危楼，虽然已经破败不堪，但仍然有很多业务在里面持续地服务着，就像依然有很多居民会在里面居住。他们无奈、疲惫、很不开心，但有新需求产生时，仍然可能要增加更多的棍子或支柱，来支撑这座危楼。当网站或应用，已经到了让开发者、运营者、运维者，感觉无奈、疲惫时，重构的时机到来了。架构师在对应用进行重构时，首先要考虑哪些点呢？首先，不应该是对网站结构进行重新构建、把很多功能更优秀、更牛逼的组件加入进来吗？我要分享的是，在进行一次重构之前，千万不要这么想。脑子不能热，我们不是在钢铁侠，可以一手托起一座城市。我们也不是极客，牛逼、优秀的组件，就算能掌控得了，也不能组合得好。在重构时，着先要考虑的，是旧楼里的居民。也就是旧应用中的业务。原因是：1、如果不考虑旧业务，而进行重构，跟一个新项目有什么区别呢？2、旧业务在不停地迭代，如果要做新的架构，什么时候可以追得上来业务？从我成功进行重构了几个巨型应用项目的经验来看，我的做法不一定是正确的，但却是切切实实可行的：1、这座危楼已经有了非常多支撑点（bug、业务补丁、流程补丁），而让项目的迭代和维护举步维艰，那么应该先找这些支撑点进行分析，把相近的支撑点进行分组和整合2、将这些已经梳理好的支撑点，一组一组进行隔离（把业务解藕、把连带风险降低）3、把已经进行隔离好的支撑点，一个一个拿来进行深度解析（分清流程、层次、与关键点）4、将支持点进行规范化的重构与替换（逐个重构，最终完成基础结构的重构）形象一点讲：重造一座优秀的建筑，是很完美的，但会让所有人都更加疲惫；而将一座危楼的破旧部分作为基石，把它有机制地打碎重组，最终成为新建筑最牢固的地基，一次重构才是成功的。OK，以上是今晚我的分享，关于架构与重构的心得，下面是交流时间，请大家提问：互动讨论：问：我认为架构必须考虑业务？否则很容易出现过度设计或者设计缺失答：业务是应该要考虑的。但也不能过多了考虑，因为很可能会成为定制，而导致后期的不可扩展。问：个人觉得