架构师应该掌握哪些设计模式

今天去参加了北京博文视点出版社在上海办的一个Open
Party（http://www.douban.com/event/11051981/）。其中有两个topic给我很大的启发，一个是温昱的《架构
设计的事实与谬误》，另一个是老赵（@jeffz_cn）的《Web应用中的缓存》。

当然，我的收获未必是他们两位想要传达的主旨，只是引发了很多联想，所以也就不写思考的过程了，直接说一些结论吧。

1、架构设计需要关注需求，而需求有两大部分 ，一部分是与业务相关的需求，另一部分是与业务无关的需求。
2、与业务无关的需求，包括可重用性、高性能、可靠性、易用性、安全性等等。
3、经典的GoF的设计模式，其实只解决了（甚至只能说部分解决了）可重用性的需求。
4、在高性能的需求领域，也可以总结出很多设计模式，其中，老赵今天特别提出的缓存，是跨越N多领域的，提高性能的重要模式。
5、在我看来，要提高性能，无非这么三大思路：缓存、切分、并行。在三大思路之上，还有一个总的思路，就是找到性能瓶颈，然后尝试优化这个瓶颈。
6、缓存的思路，今天老赵已经谈得非常好了，每一个层次，有每一个层次的缓存实现思路和方案，有优点，有缺点。如果能够再展开谈一谈缓存模式的共性，就更棒了。也许可以总结为：针对80%的情况进行特殊处理，以更加快捷的方式减少CPU与IO。
7、切分，比如将数据分开存放、将静态内容与动态内容分开处理、将缓存分散在多个memcached服务器上等等等等，总的思路，是将原本的瓶颈分散化、将原本的问题，分别细化处理。
8、并行，当然也是一大门类，就不展开了，总得思路是：让计算机在同一个时间断内，做尽可能多的工作。
9、也许，应该有这么一本书：《高性能设计模式》，与“以可重用性为目标的设计模式”应该同等重要。
10、依此类推，还应该有《安全性设计模式》、《高可靠性设计模式》、《易用性设计模式》等等，这些跨应用、跨业务、跨领域的设计模式，都是架构设计师，应该深度掌握的设计模式。
11、也许，应该有出版社，组织高人，写这么一套《架构师设计模式丛书》出来。

评论

20 楼 qixinkui 2010-12-11  

模式往小了说就是惯用法；往大了说就是架构，风格；从多方面说就是剖面。

19 楼 fantasy 2010-12-08  

学习了，总结得非常有条理性很清楚。

18 楼 zhanghonglun 2009-09-27  

引用

5、在我看来，要提高性能，无非这么三大思路：缓存、切分、并行。在三大思路之上，还有一个总的思路，就是找到性能瓶颈，然后尝试优化这个瓶颈。

异步（不如消息系统）也是一种思路哦

17 楼 treblesoftware 2009-09-23  

物理硬盘操作，太浪费时间，还有网络通信的时间。不能光从软件本身考虑吧。

16 楼 night_stalker 2009-09-23  

庄表伟 写道

设计模式与开源库，是两个不能互相取代的东西。

比如，你在CPU设计领域，积累了很多经验，其中有一级缓存、二级缓存之类的实践经验。
这些经验，在新的领域，比如数据库服务器上，能用得上吗？

查询缓存，当然也是缓存的思路，但是，CPU硬件设计的思路，肯定不能直接照搬过来就用。

但是，假设能够跨N多的领域，将缓存这个模式讲清楚，就算将来做到一个全新的，从未接触过的领域，也可以用得上，不是吗？

如果共同点很多，稍稍修改或者做做 code transformation 就能拿过去用了。
如果共同点很少，只是都带“缓存”二字而已，讲了对其他领域的应用也没帮助 ……

从范畴的角度看：
一个范畴的代码模式，做 morphism，也就是态射（代码转换器）可以把模式 port 到另一个范畴。
人的脑子也是一个代码转换器，把 A 场景的模式态射到脑子里，再态射到另一场景领域，做的事情比机器高级不到哪去。

解决问题应该记题库，还是研究代数方程？
我觉得模式看过几个就足够了，这种量变不能达成质变，死抠住不放很难达到新的高度。

15 楼 whaosoft 2009-09-23  

总结的很好,很受启发

14 楼 庄表伟 2009-09-22  

night_stalker 写道

写开源的库实在好多了，如果是有用的模式，马上就能被 port 到其他语言和领域，不完善的地方也能得到别人的改进（当然，有时也可以很快死掉）。国际开源社区的力量是非常惊人的（这就是正宗、王道、天道，不怕不识货，就怕货比货，是骡是马拉出来遛遛就知道了），但是感觉国人参与得太少，在自己的小圈子里讲学 party 为乐，很少融进世界的潮流中去。

写库同时也可以减少他人的知识包袱：告诉你这个是干嘛的，不用重复思考，更无须听耶稣讲经，拿去用就行了。
能力好的可以添加语言特性甚至搞新语言，精力不济的也可以向语言、框架的设计者提个 issue 啊。

---

写一段代码，觉得不错，命名为一个模式，让子孙后代学习去 —— 遗臭万年。
不要说不能写成库，抽象不出来 —— 能力问题。

设计模式与开源库，是两个不能互相取代的东西。

比如，你在CPU设计领域，积累了很多经验，其中有一级缓存、二级缓存之类的实践经验。
这些经验，在新的领域，比如数据库服务器上，能用得上吗？

查询缓存，当然也是缓存的思路，但是，CPU硬件设计的思路，肯定不能直接照搬过来就用。

但是，假设能够跨N多的领域，将缓存这个模式讲清楚，就算将来做到一个全新的，从未接触过的领域，也可以用得上，不是吗？

13 楼 庄表伟 2009-09-22  

Saito 写道

    设计模式到底是在减少闭门造车还是在禁锢思想我觉得这是个值得商讨的事情.

    毕竟很多从java转向ruby的人很多先去找的是有没有什么设计模式. 然后把java这边的设计模式套过去用.. 还有象现在很多的后端处理.用java处理 .跟用其他的fp类似Erlang跟Scala的Actor模型也是不能相提并论的.. 让人们抛弃side-effects .. 还不如让他们放弃语言. 况且各种技术选型的瓶颈也不相同 ..

    综上所述.我写了本Java的高可靠性设计模式. 是不是就真的是最好的选择呢? 作为一个架构师而言. 单纯的考虑一种方案的应该不会犯这种错误吧.

任何知识，都有可能禁锢思想，所以，这个要看那个运用知识的人，能不能跳出来。

设计模式，作为一种思想，肯定是存在的，也在相当程度上，是成立的。不过，有些时候，内化在语言语法里，有些得靠自己去实现。作为一个起点和基础，是必须掌握的，当然，强行套用，总是不可取的。

不同的问题，有不同的解决方案。有些问题，是跨语言的，那么就需要一个跨语言的思路来统一考虑，当然，具体到实现，肯定扎根于某个语言来编程，那么也就必须考虑到具体语言的特性，以更好的实现解决方案。

12 楼 charles751 2009-09-22  

个人认为模式是具有指导性的思考方式，目的是引导大家在面对问题时怎样去思考，及怎样选择合理的解决办法。当然，并不反对GOF本身就总结了很多的宝贵经验。

但没有一个人的经验会涵盖各个领域，实践会遍布各个类型的应用，精通各个细节，所以个人认为掌握了多少模式不是最重要的，关键是要学会其面对问题时，怎样去思考，怎样去判断和选择。

11 楼 iaimstar 2009-09-22  

night_stalker 写道

文化差异。譬如九章算术，和设计模式书没什么区别，说白了就是解题经验、题型总结。可是后来中国数学就没什么发展了。
西方人就不同，最伟大的发明就是代数。碰到问题先列成方程，映射到数学语言，再用数学语言解决，不管你什么题型、什么模式，一列方程本质就出来了。

中国数学没发展那是因为从来没重视过数学，古代一群民间爱好者。。。都没有职业的

方程和模型，本身就是很抽象的东西，架构师的设计也很抽象，程序员很难全面的理解和体会，设计模式就是个很好的桥梁，架构师通过设计模式解释意图，程序员通过设计模式了解意图，它有它存在的意义

saito 写道

话说确实模式降低了程序员之间的交流成本.解决的一部分问题.但是我不保证他没有禁锢思想的东西存在. 为啥rails这种东西被DHH玩出来. 而精通模式的大牛们还在不停的耍弄接口. 是不是值得玩味呢? ..

没啥值得玩味的，动态语言达到设计模式的方式成本本身就很低廉，而且更容易理解，java这种破j8静态语言，没有抽象，接口和继承鸟毛都玩不出来，要搞灵活性，不玩接口玩什么啊。。。抓个动态脚本语言出来，什么面向接口编程，提都不用提，怎么写都算面向接口，完全可以靠约定搞定，天生就是灵活，设计模式基本都木有啥鸟用了，在ruby里面提设计模式，确实很多模式没啥可研究的，语言特性就已经把问题解决了

10 楼 xly_971223 2009-09-22  

老庄把上面提到的写本书肯定火

9 楼 night_stalker 2009-09-22  

文化差异。譬如九章算术，和设计模式书没什么区别，说白了就是解题经验、题型总结。可是后来中国数学就没什么发展了。
西方人就不同，最伟大的发明就是代数。碰到问题先列成方程，映射到数学语言，再用数学语言解决，不管你什么题型、什么模式，一列方程本质就出来了。

8 楼 Saito 2009-09-22  

    模式有一个好处 减少交流成本. 这是很对的. 但关系到模式对于双方的了解程度. 你跟hoooooopo这种纯粹的ruby程序员谈设计模式.你给他讲半天迭代器模式. 他会告诉你( ⊙ o ⊙ )啊！..原来我每天都在用设计模式. 其实他根本不知道这是设计模式的东西.. so ..

    话说确实模式降低了程序员之间的交流成本.解决的一部分问题.但是我不保证他没有禁锢思想的东西存在. 为啥rails这种东西被DHH玩出来. 而精通模式的大牛们还在不停的耍弄接口. 是不是值得玩味呢? ..

    btw: 博客的回复不能编辑. 导致我每次回复都要慎之又慎... 

7 楼 iaimstar 2009-09-22  

Saito 写道

    设计模式到底是在减少闭门造车还是在禁锢思想我觉得这是个值得商讨的事情.
 

有关模式的书真是不少
设计模式
实现模式
企业架构模式
反模式
读一读还是总有收获的
我觉的
设计模式本身标准意义大于对一个程序员的提高
程序员之间可以直接说出模式的名字，就可以简单的明白一些模块的结构了
所以我认为设计模式应该是基本能力他关乎程序员之间的交流，而不是评价一个程序员是否懂得什么叫可复用的软件设计。

而另外的一些模式，是一些经验的东西，写成书也不是逼着人们这么写，而是从开发经历中去发现一些badcode 的前生往事，追随作者的思考，传承经验，才是模式书籍的根本意义所在吧

6 楼 night_stalker 2009-09-22  

写开源的库实在好多了，如果是有用的模式，马上就能被 port 到其他语言和领域，不完善的地方也能得到别人的改进（当然，有时也可以很快死掉）。国际开源社区的力量是非常惊人的（这就是正宗、王道、天道，不怕不识货，就怕货比货，是骡是马拉出来遛遛就知道了），但是感觉国人参与得太少，在自己的小圈子里讲学 party 为乐，很少融进世界的潮流中去。

写库同时也可以减少他人的知识包袱：告诉你这个是干嘛的，不用重复思考，更无须听耶稣讲经，拿去用就行了。
能力好的可以添加语言特性甚至搞新语言，精力不济的也可以向语言、框架的设计者提个 issue 啊。

---

写一段代码，觉得不错，命名为一个模式，让子孙后代学习去 —— 遗臭万年。
不要说不能写成库，抽象不出来 —— 能力问题。

5 楼 Saito 2009-09-22  

    设计模式到底是在减少闭门造车还是在禁锢思想我觉得这是个值得商讨的事情.

    毕竟很多从java转向ruby的人很多先去找的是有没有什么设计模式. 然后把java这边的设计模式套过去用.. 还有象现在很多的后端处理.用java处理 .跟用其他的fp类似Erlang跟Scala的Actor模型也是不能相提并论的.. 让人们抛弃side-effects .. 还不如让他们放弃语言. 况且各种技术选型的瓶颈也不相同 ..

    综上所述.我写了本Java的高可靠性设计模式. 是不是就真的是最好的选择呢? 作为一个架构师而言. 单纯的考虑一种方案的应该不会犯这种错误吧.

4 楼 庄表伟 2009-09-21  

to:Saito
设计模式，是思考的起点，以减少闭门造车与重复思考的风险。
但是，设计模式不是设计的目标，更不是设计的终点。

to:狂放不羁
谢谢，去学习ing

to:night_stalker
很多模式，在多种领域与应用中存在，写一个库，不一定能解决问题。

3 楼 night_stalker 2009-09-21  

问题：总结出这么多模式，为什么不写个库？

2 楼 狂放不羁 2009-09-21  

缓存，切分，并行，异步对于大型系统非常的重要，这些ebay架构师曾经也谈到过。Technical Session: Best Practices for Large-Scale Web Sites -- Lessons from eBay

1 楼 Saito 2009-09-21  

    同情一下老庄.. 追寻过来回复一下..

    话说真的有必要有那么多的设计模式么?刨去业务. 将这些 安全性. 易用性. 等等的设计模式全都整理出来.那是不是还要一本整合这些所有模式的设计模式呢? .况且不同的系统技术选型之间也有很多差异.. 拿最平常的语言来说. GOF的设计模式就不适用于ruby嘛. 所以.我还是觉得很不靠谱.

     以上言论是我从别处copy的. 我不懂具体是什么意思. 随便粘贴了一下. 切勿跨省追捕.