新项目上线，用户量不断增加，工作中继续不断发现问题，解决问题。花一点时间来总结一下自己对架构设计的理解。

小小的打个广告。这篇文章是发布在neil的微信公众号上。neil的文章都会第一时间发布在微信公众号上。欢迎小伙伴们关注。

微信公众号：互联网与作曲家 

• 武侠小说中的“万剑归宗”----极致的抽象思维

一点题外话。自己从小就是武侠迷，金庸古龙的经典作品都看过很多遍。最喜欢的女主，是《倚天屠龙记》中的赵敏：敢爱敢恨，邵敏郡主。其扮演者黎姿，是我心目中两位女神之一，性格与赵敏非常相似。另一位女神是周慧敏。最喜欢的男主，当属杨过：杨康之子，“有过则改之”，曾经年少轻狂；洗尽铅华之后，神雕大侠悟出黯然销魂掌，力挽狂澜。

武侠小说中，武功的最高境界都是“无招胜有招”，一切有具象的招式都是下乘。到了这种境界，草木皆可伤人。金庸小说中描写剑魔独孤求败，其武功修为有四个阶段。第四个阶段臻至化境，“四十岁之后不滞于物，草木竹石均可为剑。自此精进，渐入无剑胜有剑之境。” 从利剑，到软剑，再到无锋重剑，最后是草木竹石皆可为剑，其实就是一个将具体事物不断抽象的过程。最开始时，武功需要用剑的锋利去展现；接着变成只需要软剑；然后连剑刃也不需要了，重剑无锋，大巧不工；达到最高境界后，掌握了武力的真谛，可以将武功通过任何形式展现出来，“无剑胜有剑”。类比到架构设计上来，从最开始的C语言输出hello world, 到执着于“PHP是不是最好的语言”，再到对各种设计模式，架构思维了如指掌，最高境界就是能够应对任何复杂的业务需求，将架构设计做得像艺术品一样。什么时候能达到这种境界啊。流着口水YY中......

• 看山是山，看山不是山，看山还是山

宋代禅宗大师青原行思提出参禅的三重境界：参禅之初，看山是山，看水是水；禅有悟时，看山不是山，看水不是水；禅中彻悟，看山仍然山，看水仍然是水。直白一点就是说：人之初，性本善，大家刚开始的时候都是一张白纸，都很单纯，即，看山是山；随着阅历逐渐丰富，经历过一些沧桑后，感觉这个世界太艰难了，累觉不爱，看水不是水；心态继续蜕变，返璞归真后，重新以单纯的角度来看待这个世界，顿悟，看山仍然是山，看水仍然是水。这是这三重境界的本意。

这句禅语还可以用于抽象思维与具象思维的联系。“看山是山”，即分析具体问题；“看山不是山”，就是将具体的问题进行提炼，抽象，形成一套架构设计和解决方案，可以适用于所有类似的具体问题；“看山还是山”，就是一个验证解决方案的过程。将抽象出的架构用于解决具体的问题，根据效果来不断改进，优化原有的设计。这是一个从具象思维到抽象思维再回到具象思维的过程，我认为任何架构的设计都是基本符合这个过程的，抽象分析和具体分析，二者缺一不可。举个工作中的例子：同事A针对一个问题设计出了两套解决方案，这两套方案本身是完全对立的，而且由于问题的复杂性，两套方案都无法完美解决问题，需要评估各自的效果。同事A仅仅从抽象的理论上分析，两套方案的效果是一样的。但实际情况却是：因为不同位置的曝光率不同，会导致两套方案的效果出现极大的差距。可以简单总结下：抽象理论分析与具体问题分析都需要进行，并且二者的效果是互补的。

• 大道至简

大道至简，国外叫做奥卡姆剃刀原理，即解决方案应该趋于简单而不是趋于复杂。这个原则说起来容易，做起来却无比艰难。软件工程的问题越来越复杂，没有办法依赖简单的答案来解决。提一下“没有银弹”这篇经典的论文。该论文讨论了次要复杂度和必要复杂度。次要复杂度是指由人们本身所产生的问题，比如使用C++，java还是python. 这类问题是可以被比较快速地解决的。必要复杂度是指软件本身要解决的问题，比如复杂的业务场景，海量用户访问等等。设计模式有很多种，但没有一种是万能的。从复杂的问题中提取要点，不断进行抽象，再结合具体问题进行分析，在保证满足业务需求的前提下，尽可能地简化方案，优化方案，再考虑到未来可能变化的业务场景，避免过度设计。这大概就是架构师的功力所在了吧。

• 架构设计中的二八原则

二八原则适用于很多地方：20%的时间完成80%的工作，剩下20%的工作可能需要80%的时间才能完成。架构设计中需要考虑到各种异常情况的处理，很多时候异常情况的处理才是最花费时间的。但我认为异常处理可能是非常关键的。我们花20%时间完成了80%的工作，同样的，竞争对手也可以在很短的时间内完成80%的工作。那么，最后20%就是我们的可能的优势所在。好的用户体验，不只是让用户用得舒服，还需要不会让用户感到不舒服。那么，对异常情况的处理，可能正是保证体验的关键所在。

• 最近用到的架构思想

1. 配置化 配置化带来高度灵活性

2. 模块解耦合 每个模块只做一件事，保持单纯

3. 读写分离 提高性能的关键

4. cache 离业务层越近，cache命中程度越高，但可复用性越低

5. 读写一致性 海量服务优先保证性能，会故意损失一部分实时的数据一致性，但会绝对保证最终数据是一致的

本文转自NeilHappy 51CTO博客，原文链接：http://blog.51cto.com/neilhappy/1661826，如需转载请自行联系原作者