标签：
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， 以上是今晚我的分享，关于架构与重构的心得，下面是交流时间，请大家提问：
互动讨论：
问：我认为架构必须考虑业务？否则很容易出现过度设计或者设计缺失
答：业务是应该要考虑的。但也不能过多了考虑，因为很可能会成为定制，而导致后期的不可扩展。
问：个人觉得架构和业务的关系很大，为什么说无关？
答：我认为的是，架构，是从业务开始，但最终决定架构的，其实是与业务无关的部分。
问：软件开发有句话很著名，就是没有银弹，考虑业务是为了弹性和扩展，并不会限制，重构的开始，可以从82法则开始。先找出那20%影响80%的地方
答：业务总是有着这样那样的条件，而这些条件，如果一旦成为架构的决定部分，则容易丢失架构原本的意图。
问：在业务与非业务之间，确实不好拿捏
答：嗯。有过这样一句话：架构靠业务，重构重功力。我非常认同后半句。
问：在架构领域里面，其实是分企业架构和技术架构的。我想你想更多的表达纯粹的技术架构。但是，其实，技术架构还是会被业务影响的，而且有时候影响很大
答：是的。我讲的是技术架构，不是业务架构。
问：可否举个印象最深的参与的客户重架构的例子，最大挑战，和如何梳理如何解决的
答：具体哪个企业就不提名了啊。 由于历史原因（人员、时间等），一个项目非常快地成功起来了，而且每年稳定盈收3亿元以上，但所有研发人员与运维人员早已不堪重负。代码结构混乱、耦合过重，我切实读过其中的一些结构和逻辑，一坨一坨，牵一发动全身，任何一个小的bug，都会搞一周才能fix甚至更久。项目到后来无法维护，业务更不能满足。 最后，在我的建议和带领下，研发部门组建了重构组，由两名架构师、一名安全顾问、一名数据顾问和N名程序员组成。首先梳理项目中的资源蓝图、结构蓝图、流程蓝图，然后选中其中一个最不起眼的流程，隔离层块与资源，然后对它进行深度的分析，找到症结点，并使用新的架构进行SOA，最终完成了这一个模块。然后历经数个模块的重构。整个项目脱胎换骨。
问：一个架构下 有2的n次方可以交叉选择的方案 如何多变量求解
答：在众多交叉选择的方案中，如果能选出一个离业务最相近，同时有随时可“掉头”可能性的方案，那就选择它； 如果仍然有多个方案，那么做好充分的准备，然后选最轻量的那个方案开始快速试错。
问：重构时模式用的多吗
答：嗯,模式不可或缺会使用，但目的一定要明确。资源、代码、流程，都会有很多模式可重用，这些模式的使用者和受益者，都是人，管理者、开发者、运维运营者，因此，对人友好是首要的。
问：这期间你需要了解业务，梳理业务流程吗？
答：无论架构或重构，对业务都是需要充分理解的。
问：重构分布式系统，往往牵扯太多，感觉需要及时重构
答：嗯，分布式系统是最难把控的。可以使用一些工具或服务来充分了解自己的系统。说一下，透视宝可以完成这个事情。
Neeke分享过后，收到一片赞声，瞬间收获很多粉丝，现场气氛很是热闹。
云智慧官网：www.cloudwise.com
标签：
原文地址：http://my.oschina.net/u/1792703/blog/494587
