实用软件架构：从系统环境到软件部署.html.pdf

《实用软件架构：从系统环境到软件部署.html.pdf》由会员分享，可在线阅读，更多相关《实用软件架构：从系统环境到软件部署.html.pdf（69页珍藏版）》请在三一文库上搜索。

1、题献 此书谨献给我过世的父亲Dibakar Mitra先生（19402015）。2015年年初，我的父亲离开了我们，我的生命中就此出现了一个悲伤的缺口，我无法自拔，难 以接受这个事实。父亲给了我莫大的动力，使我相信自己具有更强大的力量，能够去成就一番事业。作为他的独子，我想让父亲能够因我而骄傲。他的钱夹里装着我 的名片，时常在同事和朋友面前夸我（他有时连自己的名片都不带，但总是会带上我的名片）。 就在我成为IBM杰出工程师（Distinguished Engineer，DE）的45天之前，父亲离开了我们，他是多么想看到我获得这项荣誉啊。我最大的遗憾就是没办法拿 起电话告诉他这个消息。他离世前，

2、跟我说的最后一句话是“别担心，你今年肯定会成为DE的”。说完这话不久，他就接上了呼吸机。我的家乡，印度的加尔各 答，有一家号称医术极好的医院，但就是在这家医院里，顽强求生的父亲最终因为医疗事故离开了我们。我至今依然难掩内心的悲愤之情。 愿父亲安息。我祈求自己能在余生中以某种形式抚慰您的灵魂。儿子永远爱您。 译者序 软件开发工作是由需求引领的，而需求会随着业务的发展逐渐变得庞杂。为了对持续变化的需求进行有效的管理，很多开发者与软件公司都建立了软件架构这样 一个概念。尽管软件业与传统的实物产业不同，但它依然可以通过良好的架构指导项目的设计、编码、测试、部署以及维护等诸多阶段。从这个意义上讲，软件架

3、构 与其他行业的架构之间有相通的地方。 然而，这并不是一本泛论架构的图书，它谈论的是软件架构，并且尤为关注软件架构中的实际做法。与题材类似的其他书籍相比，本书在核心理念、结构安排以 及术语使用等方面都有自己的特色。 本书的核心理念体现在恰到好处（just enough）这个词上。架构固然应该对实现起指导作用，但这个指导作用应该留有一定的余地，使我们可以对架构进行反 思，并根据项目的发展情况对其做出调整。软件架构要想做得务实，就需要把握住恰到好处的原则，架构师要知道应该把模块细化到何种程度，才能使开发团队在既 定的大方向下灵活地进行发挥。 在结构的安排上，作者首先简介了贯穿全书的Elixir项目

4、，后续各章分别用该项目来做案例研究，以演示软件架构的某一个方面，把这些方面拼合起来就可以形 成一套完整的案例。把该案例与工作中的实际项目进行对比，或许会对大家有所启发。接下来，作者谈了软件架构的含义和意义，并指出了描述架构所用的几种视 点。然后，作者明确提出架构中需要关注的7个方面，并且用7章的篇幅来详细地进行讲解，使我们明白怎样才能恰到好处地应对这些方面。本书最后给出3个专题， 分别介绍了大数据时代的分析架构、作者在多年工作中所积累的经验，以及业界经常谈论的25个架构话题。 在术语的使用上，作者经常采用两种或三种称呼来指代同一个概念，这不仅反映了该概念所具有的多重意义，而且还使读者感受到一种

5、现象：不同的人在不同的 情境下称呼同一个概念时，关注的重点是有所区别的。由于作者就职于IBM公司，因此译者在翻译术语时，优先考虑采用IBM网站上已有的译法，对于同时具有多种 译法的术语，则酌情采用其中较常见的一种或两种。 纵观全书，作者清晰地描绘了软件架构工作的执行脉络，并指出了从系统环境到软件部署等诸多环节中所应注意的各种问题。需要提醒大家的是，软件架构必须 通过适当的代码及硬件配置得以体现，因此，架构应该尽量与实际的编码及测试工作相契合，而且要与后两者保持互动。 在翻译过程中，我得到了机械工业出版社华章公司诸位编辑和工作人员的帮助，在此深表谢意。 由于译者水平有限，错误与疏漏之处，请大家发

6、邮件至，或访问 评指正。 爱飞翔 序 软件架构这个词，有些人听了觉得开心，有些人听了要皱眉头，而更多的人对它漠不关心，尤其是那些整天忙着敲代码，没时间思考设计问题的人。 我们知道，软件密集型的系统都是有架构的。有一些架构是刻意而为的，有一些架构是偶然浮现出来的，还有很多架构隐藏在成千上万个小的设计决策中，而这 些设计决策，正源于我们敲出来的那些代码。 Tilak先生在本书中精彩地讲解了一些切实可行而且非常实用的方式与方法，以帮助我们架构出复杂的系统。作者是一位拥有实际经验的架构师，他通过一系列 案例研究，解释了“架构是什么”以及“架构不是什么”这两个问题，同时还讲解了在软件密集型的系统中，如何

7、使架构成为开发、交付及部署过程的一部分。如果 大家了解我，那一定知道我对软件架构这个主题有一些强烈的个人观点，然而在我读过的关于这个主题的那么多本书和那么多篇文章中，我确实觉得Tilak所说的这 套方法是建立在坚实的基础之上的，而且他的方法特别容易理解，也特别容易施行。 软件架构并不是一项纯粹的技术，其中还要考虑人的因素。本书正是抓住了这个重要的因素Tilak把自己在架构工作中汲取的经验教训合理地穿插在本书中， 我很欣赏这一点。 架构是个重要的过程，这个过程不仅不能妨碍系统的构建，而且还必须在恰当的时机以合适的资源和特别实用的方式构建出正确的系统。 Grady Booch IBM院士及软件工程

8、首席科学家 前言 软件架构这个学科已经有半个世纪的历史了。此概念于20世纪60年代引入，它的灵感来源于建筑物的架构，其中涉及在开始盖楼之前拟定的一些蓝图，这些蓝 图描述了建筑师对建筑物的结构所制定的设计方案与规格说明。建筑物的蓝图给出了建筑物在功能方面的设计方案，也就是楼层的空间布局示意图，以及每个建筑工 件（例如门、窗、房间、浴室、楼梯等）的尺寸。在使建筑物得以运作的那些方面，蓝图也提供了详细的设计方案，例如承载建筑结构的地基、电线、水管和输气管 道的设计，以及下水道系统等，要想使建筑物的功能全面运转并发挥效用，这些方面都是不可缺少的。 信息技术（information technology

9、，IT）中的软件架构，其真正灵感来源于建筑架构学中的土木工程（civil engineering）这一学科。据此，我们可以把软件 架构大致分成功能架构（functional architecture）和操作架构（operational architecture）两大类。软件架构在20世纪70年代开始得到大规模实践，到了20世纪 90年代，它已经成为IT界的主流，此时各种架构模式也相继涌现。这些模式会随着工作中反复出现的一些用法而演化，所谓反复出现（recurrence），是指这些用法 会一直重复地出现在日常应用中。我们之所以能从软件架构中提炼出架构模式，是因为有一个先决条件已经得到了满足。这个

10、条件就是软件架构已经得到了充分的实 践，从而成为业界的主流做法，并且已经作为一门正式的研究与实践学科，得到了业界的认可。 IT系统的复杂度越来越高，因此各种IT项目都会频繁而且广泛地运用软件架构技术。软件架构的方式也随着运用面的扩大而变得丰富起来，并且还涌现出了很多 流派，它们采用不同的观点来看待软件的架构，并根据其在开发软件系统时所取得的实际经验来总结并推广各自的观点。软件架构的流派和观点变得越来越多，这使 很多IT工作者都不知道应该采信哪个流派的观点。大家不妨回想一下，看看自己有没有对下面这些问题表示过困惑？ 我读过很多架构方面的书籍，也看过很多期刊和杂志，但是我究竟应该怎样把这些互不相同

11、的架构流派汇整起来呢？ 这些流派中有哪些方面是我比较喜欢的？ 这些方面是否可以互补？ 如果我是一名架构师，面对着一个时间和预算都受限制的复杂软件系统，那么应该从哪里开始实现它呢？ 我是否能成为一名成功的软件架构师？ 笔者也曾陷入这样的困惑中。软件架构师所要面对的一项艰难挑战，就是寻找一种最佳的方式，来确定系统或应用程序的架构，并对其进行设计。对软件架构的 要义进行把握，既是一种科学，又是一种艺术。我们要用适当的描述语言来定义系统的软件架构，并对其加以分析和理解，从这个层面来看它是科学。同时，我们还 要用清晰、明确并且简洁的方式把这个架构描绘出来，以便与不同的利益相关者就系统的解决方案架构进行有

12、效的沟通，从这个层面来看它又是艺术。软件架构师怎 样才能抓住关键的架构工件（architecture artifact）1，从而清晰地描述出整个解决方案呢？这正是难点所在。过度的设计和过多的文档，会拖慢项目的进度，并 给项目的交付带来风险，而对软件架构所做的不恰当处理，则会使开发者无法领悟这套架构，这是个很关键的问题。如果开发者不能很好地理解软件的架构，那么他 们就无法恰当地遵循技术方面的规范和限制，也无法恰当地使用这套架构来设计并开发系统中的各个部件。在软件开发的整个生命周期中，这个问题只会越来越严 重。 2008年，笔者在IBM developerWorks网站上写了一系列专门谈论软件架构

13、的文章。在连续发布4部分之后，由于某些个人原因，没有再往下写。接下来的几 年，笔者看到了一些网友提出的问题，也收到了一些称赞，然而除此之外，还有另一类信息促使我进行更多的思考。比如，下面这两个问题： “先生您好。我正在参考您的系列文章来撰写硕士论文。请问下一部分的文章什么时候发布？” “Mitra先生，我们采用您所说的框架做了IT项目，但是项目暂停了，因为您的下一篇文章还没出来。求助。” 某一天早晨，我忽然感觉读者确实需要一本架构方面的书籍，它必须写得简单、明确、易于理解、便于描述，而且最为重要的是，它必须足够实用，能够执行。 这本实用的书籍要能够给IT工作者和软件工程专业的学生带来较大的帮助

14、，使他们明白怎样对软件系统进行架构。过了一段时间之后，我终于决定开始写书了。本书 代表着软件架构领域中的集体智慧、经验、学问和知识，这些内容是笔者根据自己从业18年来的经历收集而成的。本书面对的读者有很多，其中包括： 软件架构师。书中会给出一些实用而且可以反复运用的指导原则，以帮助软件架构师来研发软件的架构。 项目经理。本书将会帮助读者理解并领会系统架构中的关键元素，它们是良好的架构所必备的元素，本书还会解释怎样才能在进行项目规划时把架构活动控制 得恰到好处。 高校学生。本书将会帮助大家理解怎样把软件架构中的理论转述成实际的问题，并对其加以实现。无论技术如何发展，本书都可以当作长期的参考资料。

15、 教师。通过本书，教师可以帮助学生把软件架构中的各种理论与实际工作联系起来，使学生变成能够应对实际项目的软件架构师。 首席管理者（C-level executive）2或高层管理人员。本书将会帮助他们意识到研发良好的系统架构所必备的要素，对于IT界的任何一种创新活动来说，这种意 识都会给公司带来间接的好处，使他们可以更好地领悟IT架构在整个公司中的基础地位。 笔者想把这本书写成一本实用的教程，使读者可以按照里面所说的方法，通过多个阶段的演进来迭代式地构建出软件的架构。书中会指出各种架构工件的运用方 式，使大家可以把这些清晰、简明、精准而且易懂的工件，恰到好处地运用在实际的应用场景中。在整本书中

16、，笔者会以较为随意的方式来使用“软 件”（software）“系统”（system）和“解决方案”（solution）这三个词，由于它们在本书中指的都是架构（architecture），因此这三者之间是可以互换的。 笔者之所以要采用这种不拘于字面意思的交替指称方式，是为了使大家明白：在IT界，这三个词之间的界限其实是相当模糊的。 从哲学角度来看，东方哲学和西方哲学之间的区别，在于它们对直觉和理性这两种感知形式的接受程度有所不同，前者更强调直觉，而后者更强调理性。西方世 界普遍相信，并且主要依赖于理性的、科学的和演绎式的推理。而东方世界则更加看重凭直觉所获取的知识，他们认为，更高形式的意识（在这

17、里指的是知识）是通 过观察（也包括反思自己的内心世界）得来的，而不是仅仅通过实验式的归纳得来的。笔者生长于印度加尔各答一个文化较为多元的孟加拉家庭中，十分认同东方式 的信仰和知识观念，我认为自觉的意识最终需要通过自觉的自由意志来获得，知识的奥义也要通过直觉和归纳式的推理来领悟。后来，笔者在西方世界生活了将近 20年，在这段时间里，我开始看重科学和理性的知识形式。我认为，一个普通人要想在这个残酷竞争的世界中生存，就必须掌握由理性与科学手段所得到的知识， 对于科学、技术和IT领域来说更是如此。等到自己的工作稳定下来之后，可以去深入探索直觉感知力和归纳式推理，这种探索虽然未必会带来回报，但或许会帮助

18、我 们从人生的存在中求得解脱。 在这本书中，笔者试着用一种解说的办法，通过归纳式的理性推理来帮助读者掌握实用的软件架构方式。等到掌握了这种理性的知识之后，读者可以把注意力放 在归纳式的推理上，以探求更为玄妙的直觉知识。如果把解决最困难的架构问题比喻成寻求圣杯（Holy Grail），那么用直觉来感知软件的架构就相当于层次更高的 开悟了，这种境界，我想应该是大家梦寐以求的吧。 等到看完本书并掌握了它的要义之后，希望你能焕然一新，变成一位务实的软件架构师。软件架构是个有趣的学科，其中的理性知识，我想读完这本书之后，大 家应该就可以了解到。而凭直觉才能获得的那一部分知识，则需要以理性知识为基础，继续

19、去探索。在这一方面，连笔者也只是刚刚入门而已。 另外再说一句，每章开头的那些格言，其实都是笔者自己编的。 1 工件也称为制品、产物、成果物。译者注 2 例如首席执行官（CEO）、首席技术官（CTO）等，由于这些头衔都以字母C开头，因此被称为C级管理者。译者注 致谢 首先要感谢妻子Taneea和母亲Manjusree，她们给了我写书所需的时间和灵感。感谢我的叔叔Abhijit始终支持我，使我相信自己能够写完这本书。还要感谢我 的独子Aaditya，他总是关心我为什么又要去写一本书。 在专业写作这一方面，我真诚地感谢本书的执行负责人Ray Harishankar，他从头至尾陪着我走过这段愉快的写作

20、之旅。我还要感谢同事Ravi Bansal帮我审阅并 完善本书的章节结构，并给我提供相关的专业知识。感谢来自德国的同事Bertus Eggen，他提出了一个绝妙的数学算法，使我可以针对服务器之间的网络连接度来 设计容量模型。感谢Bertus允许我在书中使用他的想法。Robert Laird十分热心地审阅了本书，并提出了相当宝贵的意见，对此我表示衷心的感谢。还要感谢Craig Trim给我提供了自然语言处理方面的一些内部细节和技术。 Grady Booch先生能够为本书作序，令我深感荣幸，在此衷心感谢。 感谢上苍把Aaditya赐给我们。2010年出生的他，给我带来了无尽的快乐，接下来的几年里，

21、我要好好地看着他长大。他已经有了几分“大志”，而且想变成和 我一样的人，不过，我还是要引领他，让他更加上进。 第1章 案例研究 我这个人专门解决难题，有什么事尽管拿来问！ 生活脱离了环境，就如同船没有了帆。环境使得我们可以专注于手头的工作，它能给人一种方向感，也能给人提供一个理由，使我们觉得完成某件事情是值得 的。信息技术（IT）和计算机工程等领域中的架构也是如此，它同样需要有一个存在的理由。我们必须对架构进行实例化，必须按照需要将其实现出来，以解决实际 的问题。 笔者将在本章中描述一个虚构的案例，以演示问题的陈述。尽管笔者不会明确宣称它与某个真实案例有所对应，但读者在工作中或许真的就会遇到这

22、么一个类似 的案例。这种描述实际问题的案例研究，能为我们提供一个环境，使得IT或软件架构中的元素可以在这个环境中呈现出来。该环境可以说是软件架构得以存在的客观 理由。 1.1 业务问题 有一家名为BWM（Best West Manufacturers）的重型设备生产公司已经拥有稳定的客户群，主要开展机器和重型设备生产等传统业务。 行业展望分析和独立分析师的研究报告都指出：未来几年中，BWM公司通过与新客户签订设备购买合约来增加其市场份额的机会是相当有限的。 董事会为此举行了将近两周的闭门会议。在经过多番构思和头脑风暴之后，参加会议的人员对会议成果进行了总结，并将其作为业务指示，传达给了公司的高

23、层 领导。他们要求公司极力提升现有客户群对售后市场的关注程度，并想办法使客户在售后市场中进行大量消费。 公司的高层管理者分析了董事会所下达的指令，他们认为公司必须把注意力集中在怎样向客户提供更多服务上。这意味着BWM不仅要做好设备本身的销售工 作，而且还要提供更多的增值服务。这些服务可以帮助客户提升机器的使用效率，从而最大限度地提高生产量，也可以帮助客户减少意外的停机检修时间，还可以帮 助客户尽早预见有可能出现的故障。 1.2 小结 要想把软件开发的各个部分全都维系起来，IT系统的架构可以说是至关重要的一个元素。 在解决当前的问题时，我们经常容易采用过于庞大、过于宽泛的理论来描述它，即便是专业

24、的软件架构师和系统开发者，也有可能会陷入这种状况中。因此，软 件架构师在解决问题时，通常应该先缓一步，仔细想一想：我是不是把这个问题解释得太复杂了？我是不是把这个问题推广得过于宽泛了？我是不是对IT系统的架构 做了过多的处理？ 通过进行案例研究，我们可以为待解决的问题创造一种环境，并为其划定边界，这样做使得我们能够专注于目前所要解决的这个问题。 这种专注于解决当前问题的理念，使我迫不及待地想要沿着本书继续讲下去。（如果你也想成为一名务实的软件架构师，那就请继续阅读吧！） 第2章 软件架构是什么？为什么需要做软件架构 除非我信它，否则不可能全身心地投入其中。 如果你已经读到了这里，那么你应该是真

25、心想要成为一名“务实的软件架构师”。我们不能仅仅把这个名号挂在嘴边，而是要在实际的软件与系统开发工作中运 用这套理念做出优秀的产品。 软件架构师的做事风格多种多样，而且通常都很有意思。有的架构师喜欢做宏观的思考，喜欢随便拿一张纸画上几笔，或是在白板上画一些方框和线条，而且那 些方框看上去好像长得都不太一样。有的架构师不先把宏观的架构情况了解清楚，就急着去研究细节问题。还有一些架构师则在这两种风格之间徘徊不定。因此，我 们有必要澄清与软件架构相关的一些问题，以便形成一个大家都容易接受的理解方式，并且使大家对成功的软件架构师所担负的职责，有一个清晰的了解。 本章将会给出软件架构的一些背景知识，以及

26、一些能够促使我们去做好架构工作的成熟价值理念。到本章结束时，我想大家应该能对软件架构中的一些关键元素 具有清晰的认识。我们都是务实的软件架构师，我们要把实用的软件架构理念加以阐发，并在实践中将其推广开来。 咱们做一件写着The PSA（发音是“thepsa”）的T恤穿上，怎么样？ 2.1 背景知识 软件架构作为一门学科，已经有四十多年历史了，早期的软件架构，可以追溯到20世纪70年代。后来，由于系统开发工作变得更加复杂、更加关键，而且更加 强调实时性，因此软件架构也得到了更为广泛的运用，并且成为主流的系统工程和软件开发工作中的基本内容。 与其他那些持续发展的学科一样，软件架构在诞生之初也面临着

27、一些挑战，而且直到今天，也没有能够把所有的疑难全都解决掉。早期的软件架构师会用一些图 表和文字来描述系统的结构及行为，但是他们在描述时所采用的这些办法，其清晰程度、一致程度和精确程度都不够高，而且也缺乏条理。软件架构的内容和工件， 有各种各样的表示方法和记录方法，当年的架构师，想要寻找一种协调而易懂的伪语言（pseudo-language）或元语言（metalanguage），以便将这些表述方法 统合起来。在学术研究的促进下，系统工程和计算机科学界的工作者取得了巨大的进步，他们提出了一些行之有效的做法和指导原则，使得架构师可以对软件架构的 内容做出适当的表述，以便与利益相关者就架构的成果进行有

28、效的沟通。 2.2 软件架构是什么 系统工程领域中的很多研究团体和个人，都对软件架构给出了自己的解读，他们从不同的视角阐述了怎样才能把软件系统的架构较好地表示出来。这些解读方式 或视角，都有其合理的地方，它们本身并没有问题。笔者认为，Bass、Clements和Kazman（2012）给出的解释抓住了软件架构的本质： 程序或计算机系统的软件架构，指的就是系统的结构，该结构由软件组件、外部可见的组件属性，以及它们之间的关系而构成。 那么，这个定义意味着什么呢？ 这个定义想要强调的意思，是说软件架构由粗粒度的构件（也就是软件组件）组成，这些构件，可以视为架构的构建块（building block，

29、也称为组成单元或构 造块）。我们把这种架构的构建块（architecture building block）简称为ABB。每一个软件组件，或者说每一个ABB（以后笔者会交替地使用这两个词），都具备 一些外部可见的属性，它会把这些属性展示给架构中的其他ABB。至于组件的内部细节究竟应该如何来设计和实现，则与系统的其余部分没有关系。软件组件是作为 黑盒而存在的，也就是说，它的内部细节不会暴露给外界，它所暴露的只是一些属性，系统中的其他组件，可以协同利用这些属性，把系统想要展示给用户的能力实 现出来。软件架构不仅要在最佳的粒度上确定系统中的ABB，而且还要根据其展示出来的属性以及所要支持的能力，来描

30、述每一个ABB的特征。软件架构师必须很好 地确定出系统中的ABB及其属性与能力，这样才能把握住软件架构的要义。为此，我们要把确定ABB及其属性与能力所用的那套办法，用一种简洁、清晰，而又易于 理解和交流的形式，正式地描述出来。 软件工程中的架构工作，指的是把系统分解或划分为一系列部件，使我们能够对每个部件都进行模块式的、迭代式的、渐进式的和独立式的开发。正如早前所 说，这些部件之间可能会具备某些关系，当我们把这些部件交织起来或汇集起来时，应用程序的软件架构（也就是系统）就搭建出来了。 很对人对架构与设计之间的区别有着一些困惑。按照Bass、Clements和Kazman（2012）的说法，所有

31、的架构都是设计，但设计却不一定是架构。某些设计模 式确实可以令系统更加灵活、更加易于扩展，同时也可以使系统所要满足的边界条件得以明确，把这些模式说成架构模式，是没有问题的。但更具体地来说，架构所 要强调的意思是把ABB当成黑盒，而设计所注重的则是软件组件的配置、定制以及内部的工作机理等方面。就软件组件来说，架构所关注的问题，仅仅是该组件的外 部属性，而设计所关心的问题则更加宽泛，它不一定只会谈论该组件外部的那些属性，同时还有可能提到组件内部的实现细节。 值得注意的是，软件架构的原则是可以反复运用的，如图2-1所示。 图2-1 反复运用软件架构原则来描述组件依赖关系 我们可以把图2-1中代表Cl

32、assroom（教室）的软件组件C1，当成系统架构的一部分。除了C1之外，架构中还有其他一些组件，架构师可以把组件C1连同其属 性、功能方面与非功能方面的能力，以及该组件与其他软件组件之间的关系，一并分享给系统设计者。像这种由各ABB之间的相互关系及其外部可见属性所构成的集 合，就叫作架构蓝图（architecture blueprint）。设计者在分析了C1这个软件组件之后，感觉它还可以细分为三个更小的组件，也就是代表Table（桌子）对象的 C11，代表Chair（椅子）对象的C12，以及代表Blackboard（黑板）对象的C13，每一个小的组件，都具备一些可供复用的功能，可以用来实现C

33、1所要具备的属性。 设计者会对C11、C12、C13这三个组件及其接口进行细化，并把这三个组件及其接口与关系，当成C1这个软件组件的架构单元。然后，又可运用同一种思路，分别 针对C11、C12及C13继续进行细化设计，以解决其内部的实现问题。因此，我们可以把一个庞大而复杂的系统，分解为多个小的组成部分，然后对每一个部分继续进 行细化，这种做法，就是对软件架构原则的递归式运用。 正如早前所说的那样，之所以要给系统制定架构，是为了厘清系统的范围，使其能够用适当的ABB来满足行为和质量方面的目标。无论什么样的系统，其架构都 要能够较好地为利益相关者所理解，此处所说的利益相关者，既包括使用本架构来进行

34、下游设计和实现的人，也包括给本架构的定义、维护及增强工作提供资金的 人。本章稍后就会更加详细地讨论这些方面，不过笔者先要在这里强调一点，那就是沟通的重要性：架构是一种沟通媒介，通过它，我们可以和利益相关者就IT系统 进行讨论。 2.3 为什么需要做软件架构 笔者是这样一种人：除非我能确信自己真的需要去做某件事，并且了解它的重要性和价值，否则，我就很难全身心地投入其中。如果读者也是这样的人，而且你 也想了解软件架构的价值到底体现在哪里，那么就请继续往下看吧。 本节将会给出一些理据，来说明软件架构的重要意义。笔者之所以会极其热衷地从事架构工作，正是由于这些理据能够使我感到信服。 2.4 架构视图与

35、架构视点 以软件架构为论题的书籍、文章、研究项目及相关刊物，都会带有各自的观点。不同的流派对架构有不同的看法，他们会按照各自的看法来做架构，并会将各自 的做法加以推广。就本书的主题来说，笔者并不打算专门用一个章节把与软件架构有关的各种观点全都讲解一遍，而是只想展示下面的这种观点，因为笔者觉得它比 较务实，而且运用起来较为流畅。 视图和视点 Philippe Kruchten（1995.11）率先开始使用视图（view）与视点（viewpoint）这两个概念，来表达业界对软件架构的各种关注。Kruchten是IEEE1471标准的一位 制定者，该标准明确规定了视图的定义，也引入了视点的概念。Kr

36、uchten在论文（参见2.6节）中，是这样来描述这两个概念的： 视点视点是“一份规范书，用来描述构建视图和使用视图时所应依循的约定。它是一种模式或一份模板，用来确立视图的目标和受众，以及创建视图与分析 视图所用的技巧，使得我们可以据此创建出不同的视图。” 视图视图是“从某个角度对整个系统所做的一种表现，该角度是由一系列彼此相联系的关注点所确立的。” IBM（n.d.）定义了一套列架构视点，这就是IBM IT System Viewpoint Library（IBM IT系统视点库）。笔者认为这套架构视点相当完备地涵盖了系统架构的 各个方面。如图2-3所示，该视点库中包含4个基本视点和6个正交

37、（cross-cutting）视点1。 图2-3 IBM IT System Viewpoint Library中的视点（参见2.6节） IBM IT System Viewpoint Library中的四个基本视点分别是： 需求（Requirement）与该视点有关的模型元素，用来捕捉系统中的各种需求，包括业务需求、技术需求、功能需求以及非功能型需求。对于该视点来说，最 为常见的捕捉手段是用例与用例模型。 解决方案（Solution）与该视点有关的模型元素，用来确定一套可以满足相关需求及约束的解决方案。此视点可以细分为两种： 功能视点（Functional）此视点所关注的模型元素，从本质上来

38、说，都是结构方面的元素，我们不仅要把元素本身实现出来，而且还要把元素之间的（静 态和动态）关系建立好，以便用这些元素来构建系统。一般来说，此视点的细节，是通过功能架构来捕捉的，本书第7章将会专门讲解功能架构。 操作视点（Operational）此视点关注的是怎样用结构元素来构建目标系统，以及怎样把功能视图部署到（由网络、硬件、计算资源、服务器等所构成 的）IT环境中。我们通常使用操作模型来捕获此视点的细节，本书第8章将会专门讲解操作模型。 确认（Validation）通过此视点所建立的模型元素，主要用来评估系统的能力，以确保该系统能够体现出预定的功能，并且能够提供质量合格的服务。我们通 常会把

39、功能和非功能方面的测试用例当作验证标准，以判断该系统是否具备预定的能力。 从图2-3中可以看出，这4个基本视点是相互关联的。功能视点与操作视点，可以合起来实现需求视点，并为其提供支持，而这两个视点，又是通过确认视点得 以验收的。为了把这张图画得明确一些，笔者并没有专门标出“解决方案”视点，而是直接把构成该视点的功能视点和操作视点画在了图中。 视点库中还有6个正交视点。在图2-3中，4个基本视点周围的那6个同心正方形，就是用来表示这6个视点的。笔者之所以用这样的方式来画图，是想表达这6个 正交视点对一个或多个基本视点所造成的影响。 这6个正交视点分别是： 应用（Application）该视点专注

40、于满足系统所宣称的业务需求。对于该视点来说，应用架构师扮演着主要角色。 技术（Technical）该视点关注的是硬件、软件、中间件（其定义请参阅第5章）以及打包的应用程序，这些内容合起来可以实现应用程序的功能，并使得应 用程序能够运作。对于该视点来说，基础设施架构师和集成架构师扮演着主要角色。 系统管理（Systems Management）该视点关注部署之后的管理、维护，以及系统的运作。对于该视点来说，应用维护和管理团队扮演着主要角色。 可用性（Availability）该视点关注怎样才能把系统构建起来，并令其保持可用（比如，怎样才能使系统的正常运行时间达到总运行时间的99.5%），以便满足

41、 预先达成的服务级别协议。对于该视点来说，基础设施架构师扮演着主要角色，而应用架构师与中间件架构师，则会为前者的工作提供支持。 性能（Performance）该视点关注的问题是，怎样令系统的性能可以满足预先达成的服务级别协议（比如，从用户发出请求到系统给出应答，这之间的平均延 迟时间要控制在400毫秒以内）。对于该视点来说，应用架构师扮演着主要角色，而中间件架构师和基础设施架构师，则会为前者的工作提供支持。 安全（Security）该视点关注的是安全方面的系统需求，例如单点登入（single sign-on）、数据传输协议的安全程度，以及防止入侵等。某些安全需求（例如 单点登入）主要是由应用架

42、构师来处理的，而确认数据协议（例如HTTPS协议、安全套接字协议）的安全程度以及防止网络入侵等需求，则主要由基础设施架构师来 处理。 每一个基本视点和正交视点背后，都隐藏着很多细节。这些视点均各自对应于一套元素，这些元素合起来能够描述出自身的特征及职责。如果理解了这些元素， 那我们就能够深入地观察到每个视点的实现方式。尽管隐藏在每个基本视点和正交视点背后的细节有很多，然而笔者此处所要强调的内容，是大家应该意识到它们的 存在，并且意识到我们必须从其中的每一个视点或绝大部分视点来对系统的架构进行观察。这种意识很重要。 笔者曾经对很多视点框架做了研究，我感觉其中的绝大多数框架，在基本形式的层面都有着

43、一些共性。之所以会有这种共性，其原因在于：每个框架都想要确立 一套相互补充的视角，并且想通过这些视角来观察系统的架构，以便全面地覆盖架构中的各个方面。 我们需要在各种视点框架之间做出选择，或者说，我们至少要从那些特别成熟、特别稳固而且特别持久的视点框架中进行选择。在选择时，大家应该根据自己的 需求以及使用视点框架时的舒适程度来进行判断。 1 这里的cross-cutting，意思是说这6个视点都分别适用于那4个基本视点。译者注 2.5 小结 人类必须首先确信自己所从事的工作是有价值的，然后才能全身心地投入其中，我们必须首先确信自己所做的工作会有成效，然后才有热情去做好这份工作。 笔者在本章中向

44、大家阐述了自己的想法与信念，笔者认为软件架构是有价值的。因为软件架构是否明确，与软件系统能否成功之间是有着一定关系的。于是，笔 者就给出了软件架构的定义（软件架构是什么？），并且强调了它的价值（为什么需要做软件架构？） 本章还介绍了架构视图与架构视点这两个概念，并且简要地描述了一套笔者经常会参考的视点库。 第3章将要强调软件架构中的各个方面，而本书的其余内容，也会讲到这些方面。这场好戏，才刚刚开始。 2.6 参考资料 Bass，L.，Clements，P.，&Kazman，R.（2012）.Software architecture in practice，3rd ed.（Upper Sadd

45、le River，NJ：Addison-Wesley Professional）. IBM.（n.d.）Introduction to IBM IT system viewpoint.Retrieved from http:/ spaas/. Kruchten，P.（1995，November）.Architectural blueprintsThe“4+1”view model of software architecture.IEEE Software，12（6），42 50.Retrieved from http:/www.cs.ubc.ca/gregor/teaching/papers

46、/4+1view-architecture.pdf. 第3章 恰到好处地把握架构中的重要方面 你把边界定好，看我怎么在里面大显身手。 第2章强调了一些理由，那些使我们确信：凡是要开发具有一定规模的系统，就必须要重视该系统的软件架构工作。看完该章之后，读者可能会去详细地了解各 种架构视图和架构视点，或是去阅读不同的软件架构学派就软件架构中的其他一些方面所写的文章。现在，你可能会想：“架构中最需要关注的是哪些方面呢？我应 该从哪里入手呢？面对下一次架构工作，我是否能有充足的准备呢？”能够想到这些问题，那是相当自然的事情。 这是一本注重实效的书，笔者尤其想要告诉大家，怎样才能找出软件架构中的重要领域

47、，以及如何在每个领域中恰到好处地把握住当前任务的本质。请大家遵循 PSA（实用软件架构）精神，发展和完善该理念，并且一起来运用它。 本章将要强调架构中的一些方面，笔者认为我们应该花费适当的时间和精力，并通过充分的努力，来恰到好处地把握住这些方面。在开发具有一定规模的IT系统 时，如果我们能够做到这一点，那么就可以使自己的工作成果变得有价值。 3.1 软件架构中需要关注的一些方面 任何一种软件架构，都含有多个方面，而且其中某些方面可能还会变得令人畏惧，（从架构的角度来看，）这通常都是因为过分关注细节而导致的。要想避免这 种情况，就必须选出一些合适的观察面，使得这些方面不仅能够涵盖解决方案中的诸多

48、侧面，而且能够令我们可以与利益相关者进行有效的沟通。此外，对观察面所 进行的选择，还取决于当前这个系统的固有复杂程度。当然，架构师的个人喜好，也是一个因素。 前面说过，本书的主题是怎样恰到好处地把握住架构工作，因此，笔者只会专门讲解那些自己认为对系统的成功会起到必要和充分作用的架构工作，即便面对特 别复杂的系统，我们也依然应该把重点放在这些工作上。 本书要讲解下列几个方面： 系统环境（System Context）描述IT系统（通常表示为黑盒）与外界实体（外界系统及终端用户）之间的交互情况，并确定系统与外部实体之间的信息流与 控制流。它用来阐明、确认并捕获本系统的运作环境。这些外围系统及其接口

49、，以及信息流与控制流的性质，都是我们在为本架构中的技术工件拟定下游规范时所应 考虑的问题。 架构概述（Architecture Overview）通过简洁而清晰的示意图，演示软件架构中的主要概念元素，以及这些元素之间的关系。架构概述图可以在不同的层级 上绘制，也就是说，我们可以绘制企业级的视图、IT系统级的视图以及分层的架构视图。这些视图有助于展示出能够为IT系统提供支持的架构工件。这些工件都是宏 观的符号，有待以功能模型和操作模型的形式做进一步的细化。此外，总览图还描绘了企业在构建IT系统（尤其是当前这个IT系统）时所遵循的战略方向。 架构决策（Architecture Decision）提供一个坚固的工件，以捕获架构方面的相关决策。这些决策通常是围绕这几个问题而展开的：确定系统的结构，为满足 集成方面的需求而确定中间件，把系统的功能与架构中的每个组件（或架构中的每个构