架构之美 精选版

本文转载：

架构之美

【作 者】 Till Adam

精选版
Diomidis Spinellis 等着
王海鹏 等译
顶级行业专家揭密软件设计之美
免费在线版本
(免费在线费在线版)
登录China-Pub网站购买这本书的完整版本
更多信息请登录本书的官方网站
InfoQ 中文站出品
本书由 InfoQ 免费发放中文站。如果您从其他渠道获得本书，请注册InfoQ 支持中文站
免费下载更多的出版商和出版商InfoQ 企业软件开发系列图书。
本书主页为
http://infoq.com/cn/minibooks/beautiful-architecture
注：选择封面图片 http://www.flickr.com/photos/ladymolly/444785397/
欢迎免费下载
商务合作：sales@cn.infoq.com 提供读者反馈/内容：editors@cn.infoq.com
目录
推荐序 ...i
译者序...v
作译者简介... vii
第1 章架构概述...1
1.1 简介...1
1.2 创建软件架构...7
1.3 架构结构...11
1.4 好的架构...15
1.5 美丽的架构...16
致谢...18
参考文献...19
第2 两个系统的故事:现代软件神话...21
2.1 混乱大都市...22
2.2 设计之城...28
2.3 解释什么问题...35
2.4 轮到你了...36
参考文献...36
第3 张伸缩架构设计...37
3.1 简介...37
3.2 背景...38
3.3 架构...42
3.4 思考架构...47
第4 章数据增长：Facebook 平台的架构...52
4.1 简介...52
4.2 建立社会关系Web 服务...57
4.3 创建社区关系数据查询服务服务...64
4.4 建立社会关系Web 门户：FBML...72
4.5 支持系统...85
4.6 总结...90
推荐序一
如何看到一滴水的美丽？
支付宝(中国)公司业务架构师
作者《大道至简》
周爱民（aimingoo）
【一】
架构是一个过程，而不是结果。
【二】
在大多数人的谈论中，架构是一个目标产物，而作为架构师的责任就是去生产它。所以
无论如何，架构可以做，也应该有一些做的方法、技术和技巧。
有人问我:架构的主要产出是什么？我的答案是:图。有两层含义:一层含义
意思是用来引导实施者，就像建筑师描绘的蓝图一样；另一层意思是架构师头脑清晰
目标系统。如果架构师头脑中没有系统清晰的图像，他就无法画出来。
【三】
画家画的无非是物我。画家最后画的是我看到的。因此，画家的笔最终描绘了
他自己心里的映像。
【四】
艺术是不可能被“生产”出来的，生产出来的，叫“艺术品”。
【五】
架构这个过程，是架构师洞见系统内在结构、规律、原则和逻辑的过程。真正的架构师
是可以将自己放在系统中去的（例如作为系统中的任何一个角色），只有清晰地理解系
统，才能简洁地描述它。而当架构师拿出了他所描述的“作品”的时候，架构这一过程
就已经结束了。
【六】
一滴水滴落的过程中，有多少个形态的变化？
InfoQ企业软件开发丛书《架构之美》精选版
推荐序二
架构的架构
北京无限讯奇信息技术有限公司产品技术高级总监
黄冬
从编辑手里拿到厚厚的《架构之美》译稿时，恰巧是我刚刚讲完一场消息系统架构的讲
座之后。而正是在昨天，一位想要创业的朋友跟我说要寻找一位懂得“架构”的高人与
他一起创业。要知道与代码不同的是，“虚幻”的架构常常让人认为其有很多玄妙之处，
只因它大多难以落在纸上。特别是与很多大师谈及架构时，经常落入他们的一些“陷阱”，
并往往为自己达不到大师的精明与技巧而叹息。殊不知，被我们所津津乐道的这些架构，
是他们在日常工作里经历了大量的错误、重复的尝试、无数的代码、长久的考验所积淀
下来的只言片语。
本书将数十人的经历与只言片语，经过深思熟虑后抽象出规律，使之可以不断复用。而
另一方面，又将架构的过程娓娓道来，尝试让读者思考架构的过程与思路。在这里，更
多的过程与思考被展现出来，更多的原因与为什么让我们了解。
这本书里展现了很多绚丽的故事，犹如士兵阅读将军的传记一样，阅读本书将会让你更
鼓起勇气追寻大师们的脚步，但永远要记住，每一滴汗水才真正是你成长路上的每一个
记号，要在自己的工作里更深地去理解每一处不同，架构出属于自己的系统。
感谢译者和出版者为我们带来这样一本传奇的架构故事书。
InfoQ企业软件开发丛书《架构之美》精选版
推荐序三
美丽架构的含义
腾讯R&D研发总监(Tencent Director Of R&D Development)
资深技术专家（Senior Technology Expert）
王速瑜
古人形容美女之美：“⋯⋯增之一分则太长，减之一分则太短⋯⋯”，深刻地揭示了“恰
到好处”的美丽含义。当我拿到《架构之美》书稿时，我发现美丽的含义如此相似。
美丽至简。美丽的架构应尽可能简单，但不要过于简单。书中通过多种例子表达了这个
最基本的道理。我见过很多大型的软件架构，从大型的电信网络管理系统，到大规模应
用的互联网架构，以及企业级的ERP软件，系统总是遵循从无到有，从简单到复杂，再
到简单这样的过程。最终，支撑这些大型系统稳定可靠运行的就是这个最基本的道理。
美丽的架构应尽可能精益，并且是演进式发展的。当你架构一个亿万人同时在线的大规
模网站系统的时候，你无法从一开始就提供最完善的解决方案，它应该是随着用户的增
长而可扩展的。精益的思想让你避免了过度设计，也使架构不断演进，趋于完美。书中
从企业级应用架构、用户级应用架构等多个角度提供了相应的解决方案，对于架构师无
不是一顿美味的大餐。
深夜看完这本书稿后，我发现，架构之美并不简单，它没有定法。但是，它将为架构师
们提供一把进入“美丽架构艺术馆”大门的钥匙。拿起它，您将会开启这扇大门！
InfoQ企业软件开发丛书《架构之美》精选版
推荐序四
美丽架构之道
《构建高性能Web站点》作者
Web架构实践者
郭欣
我无法给架构下一个简单的定义，因为任何定义都会束缚你对架构的无限想象。不可否
认，架构师早已出现在人类几千年前的各项生产活动中，比如建筑、音乐。而在计算机
软件及Web领域，架构的设计直接影响着系统的生产，比如开发过程和效率、代码和组
件复用性等，同时也影响着系统的可用性、可伸缩性、性能、容量可预测性等。
本书更加关注架构之美。美丽的架构同样无法定义，可它却一定是自然的、简单的、可
复用的、人文的，甚至是外行人也可以细细品味其思想的。当我看到超市的多个收银台
排满长队时，便想到服务器并发处理性能和容量；当我看到十字路口的车辆等待转弯时，
便想到它通过缓存思想来提高交通吞吐率。
那么如何设计出美丽的架构呢？从代码逻辑到物理网络，从单机到分布式，无数的技术
可供架构师选择，如分层、组件化、服务化、标准化、缓存、分离、队列、复制、冗余、
代理等，不过它们仍然只是“术”的范畴，而何时何处如何恰到好处地使用它们才是
“道”的范畴，比如顿悟变化的道理，在博弈中寻找平衡，以系统化的角度来分析问题，
寻找相对与绝对的奥秘、开放的心态⋯⋯
然而，这个领域实在是太年轻了，我们需要更多的例子和经验，本书将让你大开眼界！
InfoQ企业软件开发丛书《架构之美》精选版
译者序
架构与美
王海鹏
人们在生活和工作中发现美并创造美，软件开发和架构设计也不例外。
架构之美体现了关注点的分离与结合。在软件设计中，设计师需要考虑多方面的关注点。
漂亮的架构设计让这些关注点尽可能分离，然后以最简单的机制结合在一起，从而得到
高内聚、低耦合的系统。例如在Darkstar项目中，架构师们考虑的重点就是如何将多人
在线游戏的游戏逻辑与系统的可伸缩性分离开来，让游戏的开发者只要遵守少量的规则，
就能够像编写单机游戏一样编写大规模多人在线游戏。又如REST架构风格，体现了对
资源命名、请求处理和资源物理表现形式的关注点分离。资源的名称与请求资源时服务
器的处理方式无关，请求者无需知道服务器端采取的技术，并且请求者本来就不关心服
务器端的处理技术。资源的物理表示形式可以通过内容协商来决定，使系统可以支持多
种物理表示形式，并可以方便地扩展。
架构之美注重表达的简洁性。“Don’t Repeat Yourself”，好的架构致力于消除各种类型
的信息重复。从结构化程序设计中的子程序和函数，到面向对象程序设计中的继承，无
不体现了对表达简洁性的特殊偏爱。在敏捷方法学中，消除重复则是重构的主要目的之
一。爱因斯坦说：“让它尽可能简单，但不要过于简单。”我们需要考虑所有必须考虑的
关注点，然后用简洁漂亮的架构体现我们的关注。同时，简洁的架构之美也降低了软件
的总体成本，从这个意义上说，“简洁性”又可以称为“经济性”。
架构之美需要解决实际问题，它既是艺术，也是生活。软件像建筑一样，它的美不能脱
离它的实用价值。Bjarne Stroustrup说，人类文明运行于软件之上。每一个软件都有自
己的架构，这些架构有的很美，有的不太美。从艺术的角度来说，美是创造矛盾并解决
矛盾。架构的多关注点和表达简洁性就是一种矛盾，美丽的架构提供了这一矛盾的解决
方法，让我们的内心产生一种愉快的感觉。
InfoQ企业软件开发丛书《架构之美》精选版
架构之美需要经过专业的学习才能更好地欣赏和创造。和所有的艺术之美一样，不是说
不经过专业学习就不能欣赏，但是经过了专业的学习，就能更好地欣赏这种美的种种精
妙之处。如果想要创造出这种美，那就必然要经过长期的专业学习。
架构之美经过时间打磨。像Facebook面向数据的Web服务、FQL和FML架构，是在对应不
同实际需求的过程中逐渐发展起来。在应用程序架构形成的过程中，设计者不断面对新
的关注点需求，不断对已有的架构进行修改，并发展出新的架构组件。这就是所谓的
“演进式架构”。只有变化是永恒不变的。在架构设计初期，设计者会将一些关注点有意
推迟到将来考虑，例如持久和并发。对于这些暂不考虑的关注点，设计者对它们的实现
方式尽可能不做任何假定，从而保留更多的可能性，让不同关注点之间的耦合尽可能小。
架构之美没有定法。虽然有一些法则可供我们参考，却没有非如此不可的。《金刚经》
云：“一切贤圣，皆以无为法而有差别。”
参加本书翻译工作的人员还有蔡黄辉、徐锋、王海燕、李国安、周建鸣、范俊、张海洲、
谢伟奇、林冀、钱立强、甘莉萍。
在这本书的翻译过程中，我受益良多，因此郑重地向大家推荐它。
xii 译者序
InfoQ企业软件开发丛书《架构之美》精选版
作译者简介
作者简介
Till Adam在年轻时学习了哲学、比较文学、美国研究和音乐学，职业是音乐人。由于
没有发财和出名，他转而攻读科学硕士，学习了数学、计算机科学和商业。多年从事自
由软件的经历（特别是对KDE的贡献）教会了他编程，也为他带来了在Klarälvdalens
Datakonsult AB工作的机会，目前他在该公司负责协调KDE的开发和其他与自由软件相
关的活动。他和他的妻子、女儿住在德国柏林。
Jim Blandy在1990年至1993年间为自由软件基金会维护GNU Emacs，和Richard Stallman
一起发布了Emacs的第19个版本。他是Subversion版本控制系统的最初设计者之一。他也
是CVS版本控制系统、GNU调试器（GDB）、Guile扩展语言库和一个编辑基因序列的
Emacs程序的贡献者。他现在为Mozilla公司工作，工作内容是SpiderMonkey，即Mozilla
的Javascript编程语言的实现。Jim和他的妻子、两个女儿住在俄勒冈州的波特兰。
Mirko Boehm从1997开始就是KDE的开发者，在1996年至2006年间是KDE e.V.委员会的
成员。他毕业于德国汉堡Helmut Schmidt大学的商业专业。在他的闲暇时间里，他阅读
纸版书籍、与家人在一起，试图远离计算机。他目前在德国柏林为Klarälvdalens
Datakonsult AB工作，负责跨平台软件和嵌入式软件开发。
Christopher Dennis自2005年JCP项目开始时就是项目的主要开发者。Chris在牛津大学
读博士时开始使用Java。此前，他使用过各种编程语言，从十六进制小键盘上编写的
Z80机器码到PHP和JavaScript。他对特殊情况、编码技巧和偶尔有点丑陋的临时编码很
有兴趣，喜欢用各种语言编写紧凑的、优雅的代码。
Dave Fetterman是Facebook的工程经理，他在那里创建了Facebook平台项目。在2006
年加入Facebook之前，他是一名软件工程师，参加Microsoft开发者部门的项目，包
括.NET的通用语言运行环境（CLR）。他喜欢为其他开发者创建软件，也喜欢对愿意听
的人发表长篇大论。他拥有应用数学的学士学位，并在2003年获得了哈佛大学的计算机
科学硕士学位。
Keir Fraser是XenSource的创始人之一，XenSource现在是Citrix Systems公司的一部分。
他也是Xen系统管理程序的首席架构师。Keir在2002实现了Xen的第一个版本，作为他
InfoQ企业软件开发丛书《架构之美》精选版
在剑桥计算机实验室攻读博士学位时的一项娱乐。在该项目成为大规模的社区合作的过
程中，他继续作为主要的开发者。他因在无锁并发控制方面的工作于2004年获得了博士
学位，并在同年成为一名教师。
Pete Goodliffe是一名程序员、专栏作家、演说家和作家，从来不在同一软件领域做过
多的停留。Pete的热门书籍《Code Craft》(No Starch Press)是对整个编程追求的实际而
有趣的调查—大约600页，真是了不起！他对制革很有热情，而且不穿鞋。
Georgios Gousios是一名职业研究者，接受的教育和软件工程有关，热衷于软件开发。
目前，他正在希腊的雅典经济与商业大学完成他的博士论文。他的研究兴趣包括软件工
程、软件质量、虚拟机和操作系统，他拥有英国曼彻斯特大学的科学硕士学位。
Gousios为多个开源软件项目贡献过代码，并参与了各种学术项目和商业项目的研究与
开发。他是SQO-OSS项目的项目经理、设计权威和主要开发成员，为评估软件质量探索
一些创新的方法。在他的学术生涯中，Gousios在会议和杂志上发表了10篇技术论文。
Gousios是ACM、IEEE、Usenix Association和Technical Chamber of Greece的成员。
Dave Grove是IBM的T.J. Watson研究中心动态优化组的一名研究员。他的主要研究兴趣
包括分析和优化面向对象语言、虚拟机设计和实现、JIT编译、在线反馈导向的优化和
垃圾收集。他在1998年参加了Jalapeño项目，是这个优化编译器和适应式优化系统首个
实现的主要贡献者。自Jalapeño在2001年作为Jikes RVM开放源码以来，他一直是Jikes
RVM核心团队和指导委员会的活跃成员。
John Klein是软件工程研究所（SEI）的高级技术人员，他的研究方向是“众系统之系
统”的架构方法，并帮助个人、团队和组织机构改进他们的软件架构能力。在加入SEI
之前，John是Avaya公司的首席架构师。在Avaya，他负责开发多模式的代理、通信分析
的架构，以及为各种客户交互产品创建并改进架构。在此之前，John是Quintus的一名软
件架构师，在那里他设计了第一款获得商业成功的多渠道集成联系中心产品，并导致了
Quintus兼并了另外两家公司，实现了产品组合的技术集成。在加入Quintus之前，John
曾为多家视频会议和视频网络业的公司服务。他的职业生涯开始于Raytheon，在那里他
为雷达信号处理、多光谱图像处理、并行处理架构和算法提供硬件和软件解决方案。
John拥有Stevens技术学院的学士学位和Northeastern大学的硕士学位。他是ACM和IEEE
计算机学会的成员。
Greg Lehey的漫长职业生涯在德国和澳大利业度过，他曾为德国空间研究所工作，也
曾为Univac、Tandem、Siemens-Nixdorf和IBM等计算机制造商工作，也曾作为一些没名
气的软件公司的大客户，还曾做过独立的咨询顾问。他的活动范围很广，包括从内核开
发到产品管理，从系统编程到系统管理，从处理卫星数据到为油泵编程，从生产
xiv 作译者简介
InfoQ企业软件开发丛书《架构之美》精选版
CD-ROM到把自由软件移植到DSP指令集上。他是FreeBSD核心团队的成员，也是澳大
利业UNIX用户协会的主席。他是FreeBSD和NetBSD项目的开发者，也是《Porting
UNIX Software》和《The Complete FreeBSD, Fourth Edition 》(O’Reilly)的作者。他还
以编写商业应用软件而闻名。Greg在2007年退休，将多出来的时间用于品味生活。现在，
休闲活动占据了他的大多数时间，但这还不够，他还听古典木纹唱片、烹饪、酿啤酒
（他开发了一个计算机控制的发酵系统）、做园艺、骑马和摄影。他也对一些历史题材感
兴趣，包括古代的难解的欧洲语言。他的主页是：http://www.lemis.com/grop/。
Panagiotis Louridas在20世纪80年代通过一台Sinclair ZX Spectrum开始涉足计算机。从
那时起，他就开始用机器语言进行编程，而且非常喜欢编程。他在雅典大学信息系获得
了计算机科学学士学位，在曼彻斯特大学获得了计算机硕士和博士学位。这些年来，他
一直为私人机构开发软件，现在，他在希腊研究和教育网络（GRNET）工作。他也是
雅典经济与商业大学（AUEB）软件工程和安全（SENSE）研究组的成员。他发表的文
章范围很广，从人类学到加密，从仪表展示到软件工程。他特别喜欢寻找计算机世界和
其他领域的联系。
Stephen J. Mellor在为软件开发创建有效的工程方法方面，是国际公认的先行者。在
1985年，他出版了广为阅读的Ward-Mellor三卷本《Structured Development for Real-Time
Systems》(Prentice Hall)；在1998年，他的书首次定义了面向对象分析。Stephen还在
2002年出版了《Executable UML: A Foundation for Model-Driven Architecture》(Addison-
Wesley Professional)。他最近的一本书《MDA Distilled: Principles of Model-Driven
Architecture》(Addison-Wesley Professional)在2004年出版。他在对象管理组织（OMG）
中活动积极，是为UML添加可执行动作的协会的主席，他最近完成了可执行UML的标准。
他是敏捷宣言的签名者之一。他是OMG架构委员会的两任成员，IEEE软件顾问委员会的
主席，最近，他成为Mentor Graphics的嵌入式软件部门的首席科学家。
Bertrand Meyer是ETH Zurich的软件工程教授，也是Eiffel软件的首席架构师，他领导
并设计了EiffelStudio环境和大量的库。他是一些畅销书的作者，其中包括获得Jolt大奖
的《Object-Oriented Software Construction》(Prentice Hall)。他也因为在对象技术和
Eiff e l方面的工作获得了ACM软件系统大奖和Dahl-Nygaard大奖，并获得了S t .
Petersburg州立技术大学的荣誉博士学位。他的研究对象涉及面向对象技术、编程语言、
软件验证（包括测试、并发和规范方法）。他也是一名活跃的顾问和讲师。
William J. Mitchell是MIT架构和媒体艺术与科学系的Alexander Dreyfoos教授，他领导
着MIT媒体实验室和MIT设计实验室的Smart Cities团队。他以前曾担任MIT架构和计划
学院的院长。他最近的新书是《World’s Greatest Architect》和《Imagining MIT》（都由
作译者简介xv
InfoQ企业软件开发丛书《架构之美》精选版
MIT出版社出版）。
Derek Murray是剑桥大学计算机实验室的博士生。他在2006年加入Xen项目，主要工作
是通过重新设计控制栈来改进Xen的安全性。他现在的研究主要是改进大规模分布式系
统的容错性，但他还是偶尔会涉及系统核心。Derek在2006年从爱丁堡大学获得了高性
能计算专业的硕士学位，2005年获得了Glasgow大学的计算机学士学位。
Rhys Newman在十多年前于牛津大学完成博士学位时，就开始使用Java，那时Java还
只有几年历史。在他早期的研究中，他利用纯Java环境展示了高性能实时场景处理的实
现方法，即使当时还是使用早期JIT化的JVM。从那时起，他同时在学界和业界工作，
一次次证明Java平台实际上有多灵活、多高效、多快。在超过20年的软件工程生涯中，
他获得了多个业界杰出技术奖项，最近他回到了牛津，承担了网格计算领域的突破性研
究工作。JPC是最新研究工作的一部分。
Michael Nygard致力于在全国帮助开发者提高水平和减少痛苦。他和他遇到的每一个人
分享他对改进的热情和活力，有时甚至没有得到对方的同意。Michael花了20年中的大
部分时间学习对专业程序员有意义的事，他关心艺术、质量和技艺。他总是愿意在那些
全职的、真心投入工作的开发者（那些“觉醒的”开发者）身上花时间。在另一方面，
他不能容忍缺乏兴趣或浪费潜力。Michael在近20年来一直是专业的程序员和架构师。
在这段时间里，他为美国政府、军方、银行、金融业、农业和零售业交付了运营系统。
通常，Michael都要面对他自己开发的系统。这种实际运营的经历改变了他对软件架构
和开发的看法。他参与了一个Tier 1零售网站的初期开发，并且常常作为其他在线业务
的“流动解决问题专家”。这些经验让他对在相当不友好的环境下构建高性能、高可靠
性的软件有了独特的看法。最近，Michael编写了《Release It! Design and Deploy
Production-Ready Software》(Pragmatic Programmers)，该书获得了2008年的Jolt生产力
大奖。他的其他文字可以在http://www.michaelnygard.com/blog上读到。
Ian Rogers是曼彻斯特大学高级处理器技术研究组的研究员。他的博士研究工作是关于
Dynamite二进制翻译器的，该技术实现了商用，现在是许多二进制翻译器产品的一部分，
包括Apple的Rosetta。他最近的学术研究工作一直是编程语言设计、运行时环境和虚拟
机环境，特别是如何自动创建它们并有效地使用并行技术。他是Jikes研究虚拟机的主要
贡献者，是开发团队的核心成员。
Brian Sletten是自由的、受过艺术教育的软件工程师，关注forward-learning技术。他曾
担任过系统架构师、开发者、现场指导者和培训师。他在世界各地的会议上发表演讲，
xvi 作译者简介
编辑注： 此书由机械工业出版社引进出版，书名为《代码质量》（注释版），书号为：978-7-
111-22671-0。
InfoQ企业软件开发丛书《架构之美》精选版
并为一些在线出版物编写关于面向Web技术的文章。他的经验涉及国防、金融和商业领
域。他曾设计并建造了网络矩阵式交换控制系统、在线游戏、3D仿真/可视化环境、因
特网分布式计算平台、P2P和基于Web的语义系统。他拥有William and Mary大学的计算
机科学学士学位，目前居住在弗吉尼亚的Fairfax。他是Bosatsu咨询公司的总裁，该公
司为Web架构、面向资源的计算、语义Web、高级用户界面、可伸缩系统、安全和其他
20世纪末21世纪初的技术提供专业的咨询服务。
Diomidis Spinellis是希腊雅典经济与商业大学管理科学与技术系的副教授。他的研究领
域包括软件工程、计算机安全和编程语言。他也编写了两本“开放源码方面”的书，由
Addison-Wesley出版：《Code Reading》（获得了2004年的软件开发生产力大奖）和
《Code Quality》（获得了2007年软件开发生产力大奖，编辑注）。他也写了几十篇科学论
文。他是IEEE Software编辑委员会的成员，负责定期的“Tools of the Trade”栏目。
Diomidis是FreeBSD的提交者，也是UMLGraph和其他开源软件包、库和工具的开发者。
他拥有软件工程的硕士学位和计算机科学博士学位，都是在Imperial College London获
得的。Diomidis是ACM的高级成员，也是IEEE和Usenix Association的成员。
Jim Waldo是Sun微系统实验室的杰出工程师，负责研究下一代大规模分布式系统。他
目前是Project Darkstar的技术负责人，该系统是针对大规模多人在线游戏和虚拟世界而
设计的多线程、分布式基础设施。在此之前，他曾是Jini的首席架构师，Jini是基于Java
的分布式编程系统。Jim编写了《The Evolution of C++: Language Design in the
Marketplace of Ideas》（MIT出版社），也是《The Jini Specification《Addison-Wesley》
的合著者之一。他曾是美国国家学术委员会的共同主席，编辑并出版了《Engaging
Privacy and Information Technology in a Digital Age》一书。Jim也是哈佛大学的辅助教
师，在计算机科学系教授分布式计算和策略与技术相关的内容。Jim拥有马萨诸塞大学
（Amherst）的哲学博士学位。
David Weiss拥有Union College的计算机科学学士学位，并拥有马里兰大学的计算机科
学硕士和博士学位。他目前是Avaya实验室的软件技术研究部的领导，他关注软件开发
效率改进的普遍问题和Avaya软件开发过程改进的特殊问题。在第二个问题上，他领导
了Avaya软件技术研究中心。以前，他曾是朗迅技术贝尔实验室软件生产研究部的主任，
该部门负责研究如何改进软件开发的效率。在加入贝尔实验室之前，他是软件生产力协
会（SPC）复用和度量部门的主任，该协会由14个大型的美国航空公司组成。在加入
SPC之前，Weiss博士在技术评估办公室度过了一年的时间，在那里他与同事共同完成了
Strategic Defense Initiative的技术评估。在1985—1986学年，他是Wang Institute的访问
学者，在许多年里，他一直是华盛顿特区Naval研究实验室（NRL）计算机科学和系统
部门的研究员。他也是一名程序员和数学家。Dave的主要研究方向是软件工程领域，特
作译者简介xvii
InfoQ企业软件开发丛书《架构之美》精选版
别是软件开发过程和方法学、软件设计和软件测量。他最为人知的是发明了软件测量的
“目标-问题-测量指标”方法，软件系统模块化结构的工作，以及软件生产线工程的工作。
他是Synthesis过程及其后继FAST过程的共同发明人。他与别人共同编著了两本书：
《Software Product-Line Engineering》和《Software Fundamentals: Collected Papers of
David L. Parnas》（都由Addison-Wesley出版）。
译者简介
王海鹏1994年毕业于华东师范大学。拥有理学士（物理）和文学士（英国语言文学）
学位。独立的咨询顾问、培训讲师、译者和软件开发者。已翻译十余本软件开发书籍，
主题涵盖敏捷方法学、需求工程、UML建模和测试。拥有15年软件开发经验，目前主
要的研究领域是软件架构和方法学，致力于提高软件开发的品质和效率。
蔡黄辉江苏启东人。1999年毕业于上海交通大学，毕业后一直从事软件开发工作，主
要使用Java做Web方面的底层开发。现居住在上海。联系方式： caihuanghui @
hotmail.com。
徐锋中国系统分析员顾问团（CSAI）软件工程首席顾问，中国软件技术大会杰出贡献
专家，资深咨询顾问。主要研究领域为需求工程、系统分析与设计、软件估算，致力于
推动软件工程方法论的落地应用。曾在《程序员》等媒体发表了《实战OO》、《项目管
理三步曲》、《大话Design》等多个专栏文章，著有《软件需求最佳实践》、《UML面向对
象建模基础》等多本书籍，翻译了《UML 2.0实战》、《AOSD中文版》、《Cloud to Code
中文版》等多本相关技术书籍。
xviii 作译者简介
InfoQ企业软件开发丛书《架构之美》精选版
第1 章
架构概述
John Klein
David Weiss
1.1 简介
建筑师、音乐家、作家、计算机设计师、网络设计师和软件开发者都在使用“架构”这个
术语，其他人也用（你有没有听说过“食物架构”？），然而不同的用法其结果也不同。
建筑与交响乐完全不同，但都有架构。而且，所有的架构师都在谈论他们工作中的美，以
及因此而导致的结果。建筑师可能会说，一座建筑应该提供适合工作或生活的环境，而且
它应该看起来很美。音乐家可能会说，音乐应该能演奏，包含能够辨明的主题，而且它应
该听起来很美。软件架构师可能会说，系统应该对用户友好、响应及时、可维护、没有重
大错误、易于安装、可靠，应该通过标准的方式与其他系统通信，而且也应该是美的。
这本书为你提供了一些美丽架构的详细例子，它们来自于各类计算机系统。相对来说，
计算机是比较年轻的一个学科。因为年轻，所以不像建筑、音乐或写作等领域那样，有
那么多的例子；也因为年轻，则需要更多的例子。我们希望这本书能满足这种需要。
在你开始研究这些例子之前，我们希望你考虑以下两个问题：1) 什么是架构？2) 美丽
的架构都有哪些特性？你会在这一章中看到架构的不同定义，每个学科都有自己的定义，
所以我们将首先探讨不同学科中的架构有何共同点，以及人们试图用架构解决哪些问题。
具体来说，架构有助于确保系统能够满足其利益相关人的关注点，在构想、计划、构建
和维护系统时，架构有助于处理复杂性。
13
InfoQ企业软件开发丛书《架构之美》精选版
1
然后我们将介绍架构的定义，展示如何将这个定义应用于软件架构，因为软件是本书后
面大部分例子关注的核心。这个定义的关键在于，架构由一组结构组成，这些结构的设
计目的是让架构师、构建者，以及其他利益相关人看到他们的关注点是如何得到满足的。
在本章末尾，我们将讨论美丽架构的特性，并引用一些例子。美的核心在于概念完整性—
即一组抽象和规则，在整个系统中尽可能简单地应用它们。
在讨论中，我们将“架构”作为一个名词，它意味着一组工件，包括像蓝图和构建规范
这样的文档。这些工件描述了要构建的对象，在这种描述中，该对象被视为一组结构。
某些人也把“架构”作为一个动词，用来描述创建这些工件的过程，包括由此而导致的
工作。然而，正如Jim Waldo和其他人曾指出的，没有什么过程可以保证你学了以后就
能创造出好的系统架构，更不必说美的架构了（Waldo 2006），所以我们将更关注工件，
而非过程。
架构：“建造的艺术或科学；特别是设计和建造人类使用的建筑时的艺术或实
践，同时考虑到美学因素和实用因素。”
—《The Shorter Oxford English Dictionary》（小型牛津英语字典，第5版）
在所有学科中，架构都提供了一种方式来解决共同的问题：确保建筑、桥梁、乐曲、书
籍、计算机、网络或系统在完成后具有某些属性或行为。换言之，架构既是所构建系统
的计划，确保由此得到期望的特性，同时也是所构建系统的描述。维基百科上说：“根
据这方面已知最早的著作，即Vitruvius的‘On Architecture’，好的建筑应该美观
（Venustas）、坚固（Firmitas）、实用（Utilitas）；架构可以说是这三方面的一种平衡和
配合，没有哪一个方面比其他方面更重要。”
我们谈到交响乐的“架构（architecture）”，反过来，又将架构（architecture）
称为“凝固的音乐”。
—Deryck Cooke, 《The Language of Music》（音乐的语言）
好的系统架构展示了架构完整性。也就是说，它来自于一组设计规则，这组规则有助于
减少复杂性，并可以用于指导详细设计和系统验证。设计规则可能包含特定的抽象，这
些抽象总是以同样的方式使用，诸如虚拟设备等。这些规则可能表现为一种模式，如管
道和过滤器。在最理想的情况下，存在一些可以用于验证的规则，如“在设备失效时，
所有某一类的虚拟设备都可以用任何其他同类的虚拟设备代替”，或“所有竞争同一资
源的进程必须具有相同的调度优先级”。
当代的架构师可能会说，待构建的对象或系统必须具有以下特征：
• 具备客户要求的功能。
• 能够在要求的工期内安全地构建。
14 第1章
InfoQ企业软件开发丛书《架构之美》精选版
2
• 性能足够好。
• 可靠的。
• 可用的，并且使用时不会造成伤害。
• 安全的。
• 成本是可以接受的。
• 符合法规标准。
• 将超越前人及其竞争者。
我们将计算机系统的架构定义为一组最小的特征集，它们决定了哪些程序将运
行，以及这些程序将得到什么结果。
—Gerrit Blaauw 和Frederick Brooks, 《Computer Architecture》（计算机体系结构）
我们从来没有看到过一个复杂系统能够很好地满足上述特征。架构是一种折中—决定
改进其中一个特征常常会对其他特征产生负面影响。架构师必须确定怎样做是足够好的，
方法就是发现特定系统的重要关注点，以及充分满足这些关注点的条件。
架构观点中的常见思想是结构，每种结构都由各种类型的组件及其关系构成：它们如何
组合、相互调用、通信、同步，以及进行其他交互。组件可以是建筑中的支架横梁或内
部腔室、交响乐中的旋律、故事中的章节或人物、计算机中的CPU和内存、通信栈中的
层或连接到一个网络上的处理器、协作的顺序过程、对象、编译时的宏、构建时的脚本。
每个学科都有自己的一套组件和组件间的相互关系。
从更大的范围来说，术语“架构”总是意味着“不变的深层次结构”。
—Stewart Brand, 《How Buildings Learn》
面对不断增长的系统复杂性，以及它们内部和相互之间的交互，由一组结构形成的架构
提供了对付复杂性的主要手段，目的是确保得到的系统具备所要求的特征。结构为我们
提供途径，将系统化解为一些交互的组件。
每种结构都是为了帮助架构师理解如何来满足特定的关注点，如可变性或性能。展示某
些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关
注点都已得到满足。
网络架构：构成一个网络的通信设备、协议和传输链路，以及它们的组织方式。
—http://www.wtcs.org/snmp4tpc/jton.htm
架构概述15
InfoQ企业软件开发丛书《架构之美》精选版
3
1.1.1 建筑师的角色
在设计、构建和修复建筑时，我们指定关键的设计师为“建筑师（architects）”，并赋予
他们广泛的职责。建筑师准备建筑最初的草图，展示外观和内部布局，与客户讨论这些
草图，直至所有相关方都达成一致意见，认为展示的就是他们想要的。这些草图是抽象：
它们关注建筑中某些方面的适当细节，而忽略其他的内容。
当客户和建筑师在这些抽象上达成一致意见之后，建筑师会准备或监督准备更为详细的
图纸，以及相关的文字规格说明。这些图纸和规格说明描述了建筑的许多“实质性”细
节，如管道、壁板材料、窗户玻璃和电线等。
在极少的情况下，建筑师简单地将详细规划交给建造者，建造者将根据规划完成项目。
对更重要一些的项目，建筑师会继续参与，定期检查工作，并且可能会建议变更，或接
受来自建造者和客户的变更建议。如果建筑师监督项目，仅当他确认项目充分符合了规
划和规格说明的要求，项目才算完工。
我们请一名建筑师是为了确保：1）设计满足客户的需要，包括前面提到的那些特征；2）
设计具有概念完整性，处处运用了相同的设计原则；3）设计满足法规和安全的要求。
建筑师职责的一个重要方面是确保设计概念在实现时得到一致的体现。有时候，建筑师
也充当建造者和客户之间的协调人。哪些决定需要由建筑师做出，哪些决定由其他人做
出，人们对这个问题常有不同意见，但我们清楚，建筑师将做出重要决定，包括所有对
结构的可用性、安全性和可维护性产生影响的那些决定。
音乐作曲与软件架构
虽然人们常用建筑架构设计来类比软件架构，但音乐作曲可能是更好的
类比。建筑师创建的是相对静止的结构（该架构必须考虑到人员和服务
在建筑内的移动，以及承重结构）的静态描述（蓝图或其他图纸）。在
音乐作曲和软件设计中，作曲家（软件架构师）创建一段音乐的静态描
述（架构描述和代码），这段音乐以后将演奏（执行）许多次。在音乐
和软件中，设计都依靠许多组件的交互来得到期望的结果，结果依赖于
演奏者、演奏环境，以及演奏者所做的诠释。
1.1.2 软件架构师的角色
软件开发项目需要一些人在软件构建时扮演架构师的角色，就像构建或修复建筑时传统
的建筑师的角色一样。但是，对于软件系统来说，从来就弄不清楚哪些决定属于架构师
的职责范围，哪些决定要留给实现者。定义架构师在软件项目中做什么，比建筑师的类
16 第1章
InfoQ企业软件开发丛书《架构之美》精选版
4
似定义更困难， 原因有3 个因素： 缺少传统、产品无形性和系统复杂性。（ 参见
Grinter[1999]，其中描述了软件架构师如何在一个大型软件开发组织中实现她的职责。）
具体来说：
• 建筑师可以回顾几千年的历史，看看过去的建筑师都做过些什么。他们可以参观
并研究那些矗立了几百年的建筑，有时甚至有上千年历史的建筑，而它们仍在使
用。在软件业，我们只有几十年的历史，并且我们的设计常常是不公开的。此外，
建筑师拥有并利用标准来描述他们制作的图纸和规格说明，这让现在的建筑师能
够从记录下来的架构历史中受益。
• 建筑是有形的产品，在建筑师制作的规划和工人修造的建筑之间存在着明显的区别。
架构复用
圣索菲亚大教堂（Hagia Sophia，上图），建造于公元6世纪，率先使用了所
谓的“穹顶”结构来支撑巨大的圆形屋顶，它是拜占庭建筑之美的代表。
在1100年之后，Christopher Wren使用了同样的设计来建造圣保罗大教堂的
穹顶（St. Paul’s Cathedral，下图），它成为伦敦的地标性建筑。这两座建筑
在今天仍在使用。
架构概述17
InfoQ企业软件开发丛书《架构之美》精选版
5
在大的软件项目中，常常会有许多架构师。某些架构师相当专注于特定领域，如数据库
和网络，他们一般作为团队的一部分，但目前我们假定只有唯一一位架构师。
1.1.3 软件架构的含义
如果认为“架构”是一个简单的实体，能够用一份文档或一张图纸来描述，那就错了。
架构师必须做出许多设计决定。要想有用，这些决定必须用文档记录下来，这样就能够
进行复审、讨论、修改和批准，然后作为后续决定和构建时的约束。对于软件系统，这
些设计决定包括行为上的和结构上的。
外部行为描述展示了产品如何与它的用户、其他系统和外部设备进行交互，这应该表现
为需求。结构描述展示了产品如何划分为多个部分，以及这些部分之间的关系。我们还
需要内部行为描述，用于描述组件之间的交互接口。结构上的描述常常展示相同部分的
一些不同视图，因为不可能把所有信息以有意义的方式组织到一张图纸或一份文档中。
一个视图中的组件，可能是另一个视图中一个组件的一个部分。
软件架构常常表现为分层的层次结构，这种层次结构将几种不同的结构放在一张图中。
20世纪70年代，Parnas指出“层次结构”这个术语已经被滥用，然后精确地定义了它，
并给出了几个不同结构的例子，它们在设计不同系统时实现了不同的目的（Parnas 1974）。
将架构的结构描述为一组视图（view），每个视图关注不同的部分，现在已成为了广泛
接受的标准架构实践（Clements等2003; IEEE 2000）。我们将使用“架构”这个词来代
指一组有标注的图纸和功能描述，它说明了设计和构建一个系统时所使用的结构。在软
件开发社区中，针对这样的图纸和描述，人们使用并建议了许多不同的形式。在
Hoffman和Weiss（2000，第14章和第16章）的著作中可以看到一些例子。
一个程序或计算系统的软件架构是系统的一种结构或一组结构，它包含软件元
素、这些元素的外部可见的属性，以及元素之间的关系。
“外部可见”的属性是其他元素对该元素可以做出的假定，诸如它提供的服务、
执行时的特征、错误处理、共享资源的使用等。
—Len Bass、Paul Clements和Rick Kazman
《Software Architecture in Practice, Second Edition》
1.1.4 架构与设计
架构是系统设计的一部分，它突出了某些细节，并通过抽象省略掉另一些细节。所以，
架构是设计的一个子集。关注实现系统组件的开发者可能不会特别关心所有组件如何装
配在一起，而是主要关注少数组件的设计和开发，包括他们必须遵守的架构约束和可以
应用的规则。因此，开发者和架构师面对的是系统设计的不同方面。
18 第1章
InfoQ企业软件开发丛书《架构之美》精选版
6
如果说架构关注的是组件之间的关系和系统组件外部可见的属性，那么设计还要关注这
些组件的内部结构。例如，如果一组组件包含了一些信息隐藏的模块，那么这些外部可
见的属性就构成了这些组件的接口，内部的结构与模块内的数据结构和控制流一同考虑
（Hoffman和Weiss 2000，第7章和第16章）。
1.2 创建软件架构
到目前为止，我们已经讨论了一般意义上的架构，并分析了软件架构与其他领域的架构
之间有何相似与差异。接下来我们将注意力转到“如何”设计软件架构。当架构师创建
软件系统的架构时，她应该关注什么？
软件架构师的首要关注点不是系统的功能。
这是正确的—软件架构师的首要关注点不是系统的功能。
例如，如果我们请你来设计一个“基于Web的应用”，你首先问我们页面布局和导航树，
还是问下面这些问题：
• 谁提供应用主机托管？托管的环境有什么技术限制吗？
• 你想运行在Windows服务器上还是在LAMP栈上？
• 你想支持多少并发用户？
• 应用需要怎样的安全性？有需要保护的数据吗？应用将运行在公网上还是在私有
的内部网上？
• 你能为这些答案排列优先级吗？例如，用户数是否比响应时间更重要？
根据我们对这些问题和一些其他问题的回答，你就可以开始画出系统架构的草图。我们
还没有谈到应用的功能。
好吧，我们承认耍了点计谋，因为我们问的是“基于Web的应用”，这是一个大家熟悉
的领域，所以你已经知道了哪些决定会对你的架构产生最大的影响。类似地，如果我们
问的是一个电信系统或一个航空电子控制系统，在这些领域有经验的架构师将考虑到一
些功能需求。但是，你仍然可以不必过多担心功能就开始设计架构。你关注的是需要满
足的品质。
品质关注点指明了功能必须以何种方式交付，才能被系统的利益相关人所接受，系统的
结果包含这些人的既定利益。利益相关人有一些关注点，架构师必须重视。稍后，我们
将讨论为了确保系统具有要求的品质，通常会提出的一些关注点。正如我们前面所说的，
架构师的一项职责是确保系统设计能满足客户的需要，我们将利用品质关注点来帮助我
们理解这些需要。
架构概述19
InfoQ企业软件开发丛书《架构之美》精选版
7
这个例子突出了成功架构师的两项关键实践：让利益相关人参与以及同时关注功能和品
质。作为一名架构师，你首先问我们想从系统中得到什么，有怎样的优先级。在实际项
目中，你会找出其他的利益相关人。典型的利益相关人和他们的关注点包括：
• 投资人，他们想知道项目是否能够在给定的资源和进度约束下完成。
• 架构师、开发人员和测试人员，他们首先考虑的是最初的构建和以后的维护与演进。
• 项目经理，他们需要组织团队，制定迭代计划。
• 市场人员，他们想通过品质特点实现与竞争者的差异化。
• 用户，包括最终用户、系统管理员，以及安装、部署、准备、配置人员。
• 技术支持人员，他们关注帮助平台电话呼入的数目和复杂性。
每个系统都有自己的品质关注点。有些关注点可能定义得很好，如性能、安全、可伸缩
性等。但是，另一些同样重要的关注点却可能没有详细规定，如可变性、可维护性和可
用性等。利益相关人希望把功能放到软件上，而不是放到硬件上，这主要是为了很容易、
很快速地修改，然后通常在品质关注方面又对可变性轻描淡写。这很奇怪，不是吗？哪
些改变能够迅速、容易地实现，哪些改变需要花时间并且很难实现，架构决定将对此产
生重要影响。所以，架构师难道不应该在理解功能需求的同时，也理解利益相关人在
“可变性”这样的品质方面的期望吗？
当架构师理解了利益相关人的品质关注点之后，接下来该做些什么？考虑折中。例如，
对信息加密将加强安全性，但会损失性能。利用配置文件将增加可变性，但会降低可用
性，除非我们能够验证配置是有效的。我们是否应该对这些文件使用标准的表示方式，
如XML，还是使用自己发明的格式？创建系统的架构将涉及许多这样的艰难折中。
架构师的第一项任务，就是与利益相关人协作，理解这些品质关注点和约束，并为它们
排列优先级。为什么不从功能需求开始？因为通常有许多种可能的系统分解方式。例如，
从数据模型开始可能得到一种架构，而从业务处理模型开始则可能得到不同的架构。在
极端的情况下，系统没有分解，被开发成单一的软件。这可能会满足所有的功能需求，
但可能不会满足品质需求，如可变性、可维护性、可伸缩性等。架构师通常必须进行架
构层面的系统重构，例如为了满足伸缩性或性能的要求，将单机部署迁移到分布式部署，
从单线程转向多线程，或者将硬编码的参数移到外部配置文件中，因为原来从不改变的
参数现在需要修改了。
尽管有许多架构都能满足功能需求，其中却只有一少部分能够满足品质需求。让我们回
到Web应用的例子。请考虑提供Web页面的诸多方式—Apache和静态页面、CGI、
Servlet、JSP、JSF、PHP、Ruby on Rails、ASP.NET等。选择其中的一种技术是一种架
构决定，它将对你满足特定品质需求的能力产生重要影响。例如，像Ruby on Rails这样
20 第1章
InfoQ企业软件开发丛书《架构之美》精选版
8
的方式可能提供快速推向市场的好处，但可能更难维护，因为Ruby语言和Rails框架都
在不断地快速发展。也许我们的应用是基于Web的电话，我们需要让电话“响铃”。如
果你为了满足性能的要求，需要从服务器向Web页面发出真正异步的事件，那么基于
Servlet的架构可能更容易测试和修改。
在真实的项目中，满足利益相关人的关注点需要做出更多的决定，而不仅是选择一个
Web框架。你是否真的需要一个“架构”，并需要一名“架构师”来做出这些决定？谁
将做出这些决定？是编程人员吗？他们可能会做出许多无意识的、隐含的决定。还是由
架构师来做出这些决定？他们全面了解整个系统、利益相关人和系统的演进，然后做出
明确的决定。不论哪种方式，你会有一个架构。它是否应该明确地形成并记入文档？或
者它应该是隐式的，需要通过阅读代码才能发现？
当然，这种选择通常不是这么死板。但是，随着系统的规模、复杂度和开发人员数目的
增长，这些早期决定以及它们的记录方式将产生越来越大的影响。
我们希望你现在已经理解，如果你的系统要满足其品质要求，架构决定是很重要的，你
需要注意架构，有意识地做出这些决定，而不只是“让架构自动出现”。
如果系统非常大，情况会怎样？我们之所以运用“分而治之”这样的架构原则，一个原
因就是为了降低复杂性，让工作能够并发进行。这让我们能够创建越来越大的系统。架
构本身是否能够分解为多个部分，这些部分是否能由不同的人并行开发？考虑到计算机
的架构，Gerrit Blaauw和Fred Brooks断定：
⋯⋯如果，在采取了所有让任务能够由单人处理的方法之后，架构任务仍然巨
大而复杂，不能由一人来完成，那么产品肯定是太复杂了，以致不实用且不应
构建。换言之，单个用户必须能够理解计算机的架构。如果计划的架构不能由
一个人设计，那它也不能被一个人理解。（1997）
你是否需要理解架构的所有方面，才能使用它？架构会分离关注点，所以在大多数情况
下，利用架构来构建或维护系统的开发人员或测试人员，不需要一下面对全部的架构，
而是只要面对必要的部分，就能完成指定的功能。这让我们能够创建超出个人可以理解
的、更大的系统。但是，在我们完全忽略IBM System/360（最长寿的计算机架构之一）
创造者的建议之前，让我们先来看看他们为什么这样说。
Fred Brooks说，概念完整性是架构最重要的特征：“最好是让系统⋯⋯反映一组设计思
想，而不是让系统包含许多好的思想，而这些思想却彼此独立而不协调”（1995）。正是
这种概念完整性，让开发者在知道了系统的一部分之后，能够迅速理解系统的另一部分。
概念完整性来自于处理问题的一致性，如分解的判据、设计模式的应用和数据模式。这
让开发者运用在系统中的一部分工作的经验，来开发和维护系统的其他部分。同样的规
架构概述21
InfoQ企业软件开发丛书《架构之美》精选版
9
则应用于整个系统各处。当我们转向“众系统之系统”时，在集成了这些系统的架构中
也必须保持概念完整性。例如，可以选择发布/订阅消息总线这样的架构风格，然后将
这种风格统一地应用于“众系统之系统”的系统集成中。
架构团队的挑战在于，在创建架构时保持同一种思考方式和同一种哲学。让团队保持尽
可能小，让他们在充分沟通、高度协作的环境工作，让一两个“首席架构师”担任仁慈
的独裁者，最终做出所有决定。这种架构模式常见于成功的团队，不论是公司开发还是
开源开发，由此而得到的概念完整性是美丽架构的一种特性。
好的架构师通常来自于更好的架构师提供的现场指导（Waldo 2006）。原因之一可能是
有一些关注点几乎在所有项目中都会出现。我们已经提到过一些，但这里有一份更完整
的清单。每个关注点都以问题的方式表述，架构师在项目过程中可能需要考虑它。当然，
具体系统会有其他关键的关注点。
功能性（Functionality）
产品向它的用户提供哪些功能？
可变性（Changeability）
软件将来可能需要哪些改变？哪些改变不太可能发生，不需要特别容易进行这些改变？
性能（Performance）
产品将达到怎样的性能？
容量（Capacity）
多少用户将并发使用该系统？该系统将为用户保存多少数据？
生态系统（Ecosystem）
在部署的生态环境中，该系统将与其他系统进行哪些交互？
模块化（Modularity）
如何将编写软件的任务分解为工作指派（模块），特别是这些模块可以独立地开发，
并能够准确而容易地满足彼此的需要？
可构建性（Buildability）
如何将软件构建为一组组件，并能够独立实现和验证这些组件？哪些组件应该复用
其他的产品，哪些应该从外部供应商处获得？
产品化（Producibility）
22 第1章
InfoQ企业软件开发丛书《架构之美》精选版
10
如果产品将以几种变体的形式存在，如何开发一个产品线，并利用这些变体的共
性？产品线中的产品以怎样的步骤开发（Weiss和Lai 1999）？在创建一条软件产品
线时，要进行哪些投资？开发产品线中不同变体的选择，预期会得到怎样的回报？
特别是，是否可能先开发最小的有用产品，然后再添加（扩展）组件，在不改变以
前编写的代码的情况下，开发产品线的其他成员？
安全性（Security）
产品是否需要用户认证，或者必须限制对数据的访问？数据的安全性如何得到保
证？如何抵挡“拒绝服务”攻击或其他攻击？
最后，一个好的架构师会认识到，架构会影响组织机构。Conway指出，系统的结构会
反映构建它的组织机构的结构（1968）。架构师可能会认识到，Conway法则可以反过来
应用。换言之，一个好的架构可能对组织机构产生影响，让组织机构发生改变，从而更
有效地从该架构构建出系统。
1.3 架构结构
那么，好的架构师如何来处理这些关注点？我们曾经提到过，需要将系统组织成一些结构，
每种结构都定义了特定类型的组件之间的具体关系。架构师的主要关注点就是对系统进行
组织，让每种结构有助于解答一个关注点所定义的问题。关键的结构决定将产品划分为组
件，并定义了这些组件之间的关系（Bass、Clements和Kazman 2003; Booch、Rumbaugh和
Jacobson 1999; IEEE 2000; Garlan和Perry 1995）。对于任何产品，都有许多结构需要设计。
每种结构都必须单独设计，这样它就表现为一个独立的关注点。在接下来的几节中我们会
讨论一些结构，你可以利用它们来考虑前面列表中的关注点。例如，“信息隐藏结构”展示
了如何将系统组织成一些工作指派。这种结构也可以用作改变的路线图，展示了建议的改
变，以及哪些模块支持这些改变。针对每种结构，我们描述了一些组件及其之间的关系，
正是这些组件和关系确定了这种结构。对照前面的列表，我们认为下面的结构是最重要的。
1.3.1 信息隐藏结构
组件与关系：主要组件是一些“信息隐藏模块”，每个模块都是针对一组开发人员的工
作指派，每个模块都包含了一种设计决定。如果一项决定可以改变，同时又不影响任何
其他模块，我们就说这项设计决定是一个模块的秘密（Hoffman和Weiss 2000，第7章和
第16章）。模块间最基本的关系是“整体-部分”关系。如果“信息隐藏模块A”的秘密
是“信息隐藏模块B”的秘密的一部分，那么A就是B的一部分。请注意，必须能够在改
变A的秘密的同时，不改变B的其他部分。否则，根据我们的定义，A就不是B的一个子
模块。例如，许多架构都有一些虚拟设备模块，它们的秘密是如何与特定的物理设备通
架构概述23
InfoQ企业软件开发丛书《架构之美》精选版
11
信。如果虚拟设备分成不同类型，那么每种类型可能构成该虚拟设备模块的一个子模块，
其中每种虚拟设备类型的秘密将是如何与这种类型的设备进行通信。
每个模块都是一份工作指派，包含了一组要写的程序。根据不同的语言、平台、环境，
“程序”可以是能在计算机上执行的方法、过程、函数、子程序、脚本、宏或其他指令
序列。第二种信息隐藏模块结构是基于程序和模块之间的“包含”关系。如果模块M的
一部分工作指派是要编写程序P，那么M就包含P。请注意，每个程序都包含在一个模块
中，因为每个程序必然是某些开发人员的工作指派的一部分。
这些程序中的一些可以通过模块的接口来访问，而另一些则是内部的。模块也可能通过
接口发生关系。A模块的接口是一组假定，这些假定包括该模块之外的程序可以对该模
块做出的假定，也包括该模块中的程序对其他模块的程序和数据结构所做的假定。如果
改变B的接口就要求A也发生改变，那么我们就说A“依赖”B的接口。
“整体-部分”结构是层次状的。在这个层次结构的叶节点上的模块不包含可识别的子模
块。“包含”结构也是层次状的，因为每个程序都只包含在一个模块之中。“依赖”关系
不一定是层次状的，因为两个模块可能互相依赖，要么是直接互相依赖，要么是通过一
个较长的“依赖”关系形成的环。请注意，“依赖”不应该与后面小节中定义的“使用”
混淆起来。
信息隐藏结构是面向对象设计方法的基础。如果一个信息隐藏模块设计为一个类，这个
类的公有方法就属于该模块的接口。
满足的关注点：信息隐藏结构的设计应该能满足可变性、模块化和可构建性的要求。
1.3.2 使用结构
组件与关系：根据前面我们的定义，信息隐藏模块包含一个或多个程序（在上一小节中
定义）。当且仅当两个程序共享一个秘密时，它们才属于同一个模块。“使用结构”（Uses
Structure）的组件是一些可以单独调用的程序。请注意，程序可以相互调用，或被硬件
调用（例如，被一个中断例程调用），调用也可能来自于不同命名空间的程序，如操作系
统例程或远程过程。而且，调用发生的时间可以是任何时候，从编译时到运行时。
只有在相同绑定时间操作的程序之间，我们才考虑形成一种使用结构。首先只考虑运行
时操作的程序可能最容易。以后，我们也可以考虑那些编译时或载入时操作的程序之间
的使用关系。
如果程序B必须存在并满足其规格说明，程序A才能满足其规格说明，我们就说A使用了
B。换言之，B必须存在且操作正常，A才能操作正常。使用关系有时候也称为“要求存
在正确的版本”。进一步的解释和例子，参见（Hoffman和Weiss 2000）的第14章。
24 第1章
InfoQ企业软件开发丛书《架构之美》精选版
12
使用结构确定了我们可以构建并测试怎样的工作子集。在软件系统的使用结构中，期望
的属性是它定义了一种层次结构，这意味着其中不出现环。如果在使用关系中出现环，
那么环中所有程序都必须存在且正常工作，才能让其他的程序正常工作。由于也许不能
够创建完全没有环的使用关系，架构师可能将使用环中的所有程序作为单一的程序，以
这种方法来创建子集。子集必须要么包含全部程序，要么都不包含。
如果在使用关系中没有环，软件采用的就是一种层次结构。在最底层，即第0层，是所<