架构之美
2009
机械工业出版社
Till Adam
366
王海鹏,蔡黄辉,徐锋
无
从编辑手里拿到厚厚的《架构之美》译稿时，恰巧是我刚刚讲完一场消息系统架构的讲座之后。而正是在昨天，一位想要创业的朋友跟我说要寻找一位懂得“架构”的高人与他一起创业。要知道与代码不同的是，“虚幻”的架构常常让人认为其有很多玄妙之处，只因它大多难以落在纸上。特别是与很多大师谈及架构时，经常落入他们的一些“陷阱”，并往往为自己达不到大师的精明与技巧而叹息。殊不知，被我们所津津乐道的这些架构，是他们在日常工作里经历了大量的错误、重复的尝试、无数的代码、长久的考验所积淀下来的只言片语。本书将数十人的经历与只言片语，经过深思熟虑后抽象出规律，使之可以不断复用。而另一方面，又将架构的过程娓娓道来，尝试让读者思考架构的过程与思路。在这里，更多的过程与思考被展现出来，更多的原因与为什么让我们了解。这本书里展现了很多绚丽的故事，犹如士兵阅读将军的传记一样，阅读本书将会让你更鼓起勇气追寻大师们的脚步，但永远要记住，每一滴汗水才真正是你成长路上的每一个记号，要在自己的工作里更深地去理解每一处不同，架构出属于自己的系统。感谢译者和出版者为我们带来这样一本传奇的架构故事书。
本书围绕5个主题领域来组织本书的内容：概述、企业应用、系统、最终用户应用和编程语言。本书让最优秀的设计师和架构师来描述他们选择的软件架构，剥开架构的各层，展示他们如何让软件做到实现功能、可靠、易用、高效率、可维护、可移植和优雅。
王海鹏，1994年毕业于华东师范大学。拥有理学士（物理）和文学士（英国语言文学）学位。独立的咨询顾问、培训讲师、译者和软件开发者。已翻译十余本软件开发书籍，主题涵盖敏捷方法学、需求工程、
UML 建模和测试。拥有15年软件开发经验，目前主要的研究领域是软件架构和方法
序
前言
第一部分 论架构
第1章 什么是架构
1.1 简介
1.2 创建软件架构
1.3 架构结构
1.4 好的架构
1.5 美丽的架构
1.6 致谢
1.7 参考文献
第2章 两个系统的故事：现代软件神话
2.1 混乱大都市
2.2 设计之城
2.3 说明什么问题
2.4 轮到您了
2.5 参考文献
第二部分 企业级应用架构
第3章 伸缩性架构设计
3.1 简介
3.2 背景
3.3 架构
3.4 关于架构的思考
第4章 记忆留存
4.1 功能和约束
4.2 工作流
4.3 架构关注点
4.4 用户反应
4.5 结论
第5章 面向资源的架构：在Web中
5.1 简介
5.2 传统的Web服务
5.3 Web
5.4 面向资源的架构
5.5 数据驱动的应用
5.6 应用面向资源的架构
5.7 结论
第6章 数据增长：Facebook平台的架构
6.1 简介
6.2 创建一个社会关系Web服务
6.3 创建社会关系数据查询服务
6.4 创建一个社会关系Web门户：FBML
6.5 系统的支持功能
6.6 总结
第三部分 系统架构
第7章 Xen 和虚拟化之美
7.1 简介
7.2 Xenoservers
7.3 虚拟化的挑战
7.4 半虚拟化
7.5 Xen 的变换形式
7.6 改变的硬件，改变的Xen
7.7 经验教训
7.8 延伸阅读
第8章 Guardian：一个容错操作系统环境
8.1 Tandem/16，将来所有的计算机都会像这样构建
8.2 硬件
8.3 机械布局
8.4 处理器架构
8.5 处理器间总线
8.6 输入/输出
8.7 进程结构
8.8 消息系统
8.9 文件系统
8.10 民间传说
8.11 弊端
8.12 后继者
8.13 延伸阅读
第9章 JPC：一个纯Java的x86PC模拟程序
9.1 简介
9.2 概念验证
9.3 PC架构
9.4 Java性能技巧
9.5 把4GB放入4GB：这不起作用
9.6 保护模式的危险
9.7 从事一项毫无成功希望的斗争
9.8 劫持JVM
9.9 最终灵活性
9.10 最佳安全性
9.11 第二次做会更好
第10章 元循环虚拟机的力量：Jikes RVM
10.1 背景
10.2 与运行时环境相关的传言
10.3 Jikes RVM简史
10.4 一个自足执行的运行时自举
10.5 运行时组件
10.6 经验教训
参考文献
第四部分 最终用户应用架构
第11章 GNU Emacs：滋长的特性是其优势
11.1 使用中的Emacs
11.2 Emacs的架构
11.3 滋长的特性
11.4 另外两个架构
第12章 当集市开始构建教堂
12.1 简介
12.2 KDE 项目的历史和组织结构
12.3 Akonadi
12.4 ThreadWeaver
第五部分 语言与架构
第13章 软件架构：面向对象与面向功能
13.1 概述
13.2 示例
13.3 面向功能解决方案的模块性评价
13.4 面向对象视图
13.5 面向对象模块性的评价和改进
13.6 代理：将操作封装到对象中
致谢
参考文献
第14章 重读经典
14.1 所有东西都是对象
14.2 类型是隐式定义的
14.3 问题
14.4 砖块和灰浆建筑架构
参考文献
跋
插图：第一部分 论架构第1章 什么是架构1.5 美丽的架构所有前面的方法都有助于我们判断一个架构是否“足够好”——也就是说，是否有可能指导开发者和测试者构建一个系统，并满足系统的利益相关人的功能和质量关注点。在我们每天使用的系统中存在着许多好的架构。但是，超越足够好的架构是怎样的呢？如果有一个“软件架构名人堂”，那会怎样？哪些架构会陈列在这个艺术馆的墙上？这个想法可能没有你想象的那么遥远——在软件产品线领域，这样的“名人堂”的确存在。（注1）进入“软件产品线名人堂”的条件包括获得商业上的成功、影响其他产品线的架构（其他产品线可能“借用、复制、窃取”这个架构）、拥有足够的文档从而让其他人“不必通过道听途说”就能够理解该架构。我们将为更一般的“架构名人堂”或“美丽架构艺术馆”的候选者设立怎样的条件呢？首先我们应该认识到，这是一个软件系统的艺术馆，而不是其他艺术馆，我们的系统构建的目的是为了使用。所以，我们也许从一开始就应该关注该架构的实用性：它应该每天被许多人使用。但是，在使用架构之前，它必须先构建，所以我们应该关注该架构的可构建性。我们会寻找那些具有定义良好的使用结构的架构，它们支持增量式构建，这样，通过每次构建迭代我们都能得到一个有用的、可测试的系统。我们也会寻找那些具有定义良好的模块接口、本来就很好测试的架构，这样，构建的过程就是透明的、可见的。接来下，我们想寻找那些展示了持久性的架构——也就是说，那些经过了时间考验的架构。我们生活在一个技术环境以从未有过的加速度变化的年代。美丽的架构应该预期到变更的需要，允许期望的修改能够容易而有效地进行。我们想寻找那些避免了“衰老地平线”（Klein2005）的架构，超过了这条“衰老地平线”，维护将变得代价极大，以至于不可能进行。
“本书的作者们在介绍软件架构的基本实践和最佳实践方面干得很漂亮，他们也同样漂亮地介绍了各式各样的现代系统。我特别喜欢他们谈及的架构的广泛性，从Emacs到Facebook，从非常正式的系统到非常有灵气的系统。简而言之，这是一本非常及时的书，对于软件架构的艺术、科学和实践是非常有益的贡献。” ——GradyBooch，IBM院士
《架构之美》荣获2009年度引进版优秀图书奖！健壮、优雅、灵活和易维护的软件架构是怎样炼成的?《架构之美》通过一系列优秀的文章回答了这个问题，这些文章来自于十几位当今一流的软件设计师和架构师。在每篇文章中，作者都向们展示了一个著名的软件架构，并分析了什么让其具有创新性，让其极其符合设计目标。《架构之美》Facebook的架构如何建立在以数据为中心的应用生态系统之上。Xen的创新架构对操作系统未来的影响。KDE项目的社区过程如何让软件的架构从粗略的草图演进为漂亮的系统。不断滋长的特征如何让GNUEmacs获得从未预料到的功能。JikesRVM自优化、自足执行的运行时环境背后的魔法。 获奖证书：
无
先说说《架构之美》是本什么类型的书，这本书就如同汇集了各个电视频道充斥的各类股评专家（当然是顶尖级的）的析股法则大全。而什么是成熟的架构师呢？简单来说，就是能够取各家之所长，因地制宜，形成适合自己设计场景的架构设计规律法则。 看了一部分，觉得写得还是比较诚恳的，有以下感想记录以备忘： 1 COC规约背后的法则就是架构设计上最重要的一条：概念完整性（处理问题的一致性）， 同时，架构设计上的相对简单也才可能保证概念完整性，一致性。这也是架构能够比较务实，利于推广的重要因素。 2 软件的架构其实是和公司的组织结构及开发流程相互影响的。当然大多数情况下是软件的架构是被动者。但好的软件架构设计原则反作用于组织机构及开发流程也不是不可能的。 3 没有完美的架构。架构师就是力求做一个务实的“平衡美人”。不能一边坐拥着间接、长远才见效、容易视而不见的幕后优点，一边又对为了实现前者随之带来的小小应付成本挑三拣四，这样很容易捡了芝麻丢了瓜。。。 4.好的架构就是要分离关注点，也即“庖丁解牛，分而治之”。降低耦合性，这样复杂性也随着降低了，让参与系统各个方面的开发测试人员只需了解自己需要了解的模块，不需要了解整个系统，就能并行地进行工作了。只有这样才能开发出超越了单个人智慧所...能理解的复杂软件生态系统平台。对于复杂系统的大部分参与人员：“知其然，也要知所以然”未必适用。 5.虽然大部分程序开发人员也隐含行使了架构师的角色与职责，但架构不能这样以一种自动而隐晦的方式存在，应该适时地有意识地因地制宜的主动做出架构层面上的设计及重构工作。要不然，就像北京城市建设这样，时间成了唯一的架构因素，基于明清时代遗留的皇城根一环一环地摊大饼。。。到那时候，着急也没用了。。 6. 不要虚妄地进行所谓的自主创新：大多数场景下（尤其中国）：我们面临的架构设计其实更多的是架构选型，这没什么丢人的，孤芳自赏型地闭门造车只能是自娱自乐。就连中国飞豹歼击机总设计师也要面临架构选型：是选落后但忒熟悉不容易犯错的苏联设计规范，还是先进但忒心里没谱的美国设计规范？而如果选用落后的苏联规范，虽然初期上手很快，但中后期根本就达不到军委下达的新一代歼击型轰炸机的技术功能指标。事实是总设计师最终选择了后者，虽然有风险，不熟悉，但有成功的希望，60周年国庆飞豹也上天飞过天安门了。。 阅读更多 ›
一半的内容都是国内应用比较少的领域：操作系统、虚拟机。 大部分的内容都是我不熟悉的领域，比较感兴趣的是： 1：第三章：伸缩性架构，说的是一个游戏的架构，无法分区，需要扩展，另外客户端要有大量的运算，作者采用的是一个尽量减少延迟，“任何存在时间超过一个任务的数据都被视为持久的”，也就是把每个事务的数据都持久化。 2：第四章记忆留存。说的是一个远程照相馆作业系统。程序（包括数据库结构和数据）远程自动更新。程序判断数据库版本是否与代码版本相同的做法与Michael上周提的思路相同：用一个数据库中的表来保存版本号。 3：第十一章：GNU Emacs：滋长的特性是其优势 介绍了一个功能超强大的文本编辑器Emacs。这个文本编辑器是一个开源软件，20年以来不断有志愿者增加它的功能，架构确没发生过大的变化。 感觉这些作者水平还挺高。这本书还值得一看。
我原本以为清华的<UML 2.0 学习指南>已经达到了翻译差的巅峰,当翻开这本书之后,我发现我错了.自持语文成绩很好的我,有生以来第一次感觉到英语会比汉语更亲切...一本神书,就这么被机械工业的同胞们击沉了.
并顺致问候翻译们的老妈，真是糟蹋出版社的纸和我们的钱了！
学计算机的都知道， 英文不能太烂。我看《人月》都是看原文的， 看着看着， 不小心把CET6给过了， 嘿嘿……再有个例子， 我看《MICROSOFT WINDOWS INTERNAL》潘爱民翻译的， 很好的一本书， 作者也很用心翻译了， 但是， 翻译得真的麻麻……只看这本书的目录， 我觉得这本书内容很不错， 少有的好书。不过就算真的想买， 也买英文原文的好了， 看翻译的， 浪费钱呐。
粗看了下翻译，觉得好烂啊，英文好的话一定看原版哦
不介绍实例，不介绍原理。目录看似很nb，内容空泛，基本就是介绍了几个已经项目是做什么的，然后就没然后了。
很喜欢在卓越购书,到货快,货物品像也很不错!!!
基本的语文水平都没有，段不分段，行不分行，看了太难受，还这老贵
我很讨厌这种一堆人翻译过来的书。要看就看原版吧，真不要看翻译的。
不好意思, 这么晚才来评论.
需要的就是最好的，不错
对于学习架构很有帮助
架构是系统设计的一部分，清晰的架构有助于减少功能重复。坏的架构设计会招致更坏的架构设计，好的架构定义过程会生成优美的架构。UNIX系统和万维网（Web）架构是优美架构之典范。
看起来比较旧，纸质一般，内容还可以
买给同事的 正版 全五分
部门工作需要购买的此书，对工作上又帮助。书拿到手里感觉质量还是可以的，上午定的书下午就到了！真是亚马逊好有效率！！赞赞赞
业余性读物，可以开阔下视野
无可挑剔，看了一年多，体会良多
什么叫做构架
书看着还行吧，一般般。
提供新的视角
架构之美
确实使关注的一些值得关注的问题,但是看着确实有点不知所云.或许使翻译的问题,但也由作者的问题吧,讲述自己的理论的方法出了点小问题貌似
构架在最初构想的时候，可以脱离实际，思考出解决问题的最佳途径，但是在实施过程中，必须要考虑细节。比如书中SUN公司的DardStar，单纯从构架角度，不可谓不理想，但是试想一群没做过MMO的人在实验室给MMO设计构架现实吗？其结果就是构架看上去很美，解决了表面上的关键问题，但是没有解决实际问题，到头来构架不堪重用，最后，当Oracle把SUN收购之后，第一个开出掉的就是这个项目。
读这本书可以让我们更好的从构架角度思考问题，但是在实施的时候，工程师可能会发现构架上的各种问题，为了避免工程阶段的问题，每个构架师也应该有很强的工程和业务领域知识，否则只能是华而不实-beautiful的构架。
记得看这本书英文原版的时候，我就一直在问自己一个问题中国有没有架构师。后来在MSN签名上把这句话放了上去，结果行业里一位朋友说，中国还是有架构师的，真是远远没有名片上印着“架构师”头衔的多。
这么悲观啊，呵呵
中国肯定不缺专家....自从盖茨老大顶上了一个首席架构师的名号之后，这个名称在国内也火了起来。5年软件经验就可以当首席架构师了
基本上没有老外真正意义上的架构师，中国的架构师90%都是从事架构选型的工作,当然能做好这个已经相当难了。
中国软件起步晚，还是和国外有差距的
响屁不臭，臭屁不响