【教程免费下载】实用软件架构：从系统环境到软件部署

前言  
软件架构这个学科已经有半个世纪的历史了。此概念于20世纪60年代引入，它的灵感来源于建筑物的架构，其中涉及在开始盖楼之前拟定的一些蓝图，这些蓝图描述了建筑师对建筑物的结构所制定的设计方案与规格说明。建筑物的蓝图给出了建筑物在功能方面的设计方案，也就是楼层的空间布局示意图，以及每个建筑工件（例如门、窗、房间、浴室、楼梯等）的尺寸。在使建筑物得以运作的那些方面，蓝图也提供了详细的设计方案，例如承载建筑结构的地基、电线、水管和输气管道的设计，以及下水道系统等，要想使建筑物的功能全面运转并发挥效用，这些方面都是不可缺少的。
信息技术（information technology，IT）中的软件架构，其真正灵感来源于建筑架构学中的土木工程（civil engineering）这一学科。据此，我们可以把软件架构大致分成功能架构（functional architecture）和操作架构（operational architecture）两大类。软件架构在 20世纪70年始得到大规模实践，到了20世纪90年代，它已经成为IT界的主流，此时各种架构模式也相继涌现。这些模式会随着工作中反复出现的一些用法而演化，所谓反复出现（recurrence），是指这些用法会一直重复地出现在日常应用中。我们之所以能从软件架构中提炼出架构模式，是因为有一个先决条件已经得到了满足。这个条件就是软件架构已经得到了充分的实践，从而成为业界的主流做法，并且已经作为一门正式的研究与实践学科，得到了业界的认可。
IT系统的复杂度越来越高，因此各种IT项目都会频繁而且广泛地运用软件架构技术。软件架构的方式也随着运用面的扩大而变得丰富起来，并且还涌现出了很多流派，它们采用不同的观点来看待软件的架构，并根据其在开发软件系统时所取得的实际经验来总结并推广各自的观点。软件架构的流派和观点变得越来越多，这使很多IT工作者都不知道应该采信哪个流派的观点。大家不妨回想一下，看看自己有没有对下面这些问题表示过困惑？
我读过很多架构方面的书籍，也看过很多期刊和杂志，但是我究竟应该怎样把这些互不相同的架构流派汇整起来呢？
这些流派中有哪些方面是我比较喜欢的？
这些方面是否可以互补？
如果我是一名架构师，面对着一个时间和预算都受限制的复杂软件系统，那么应该从哪里开始实现它呢？
我是否能成为一名成功的软件架构师？
笔者也曾陷入这样的困惑中。软件架构师所要面对的一项艰难挑战，就是寻找一种最佳的方式，来确定系统或应用程序的架构，并对其进行设计。对软件架构的要义进行把握，既是一种科学，又是一种艺术。我们要用适当的描述语言来定义系统的软件架构，并对其加以分析和理解，从这个层面来看它是科学。同时，我们还要用清晰、明确并且简洁的方式把这个架构描绘出来，以便与不同的利益相关者就系统的解决方案架构进行有效的沟通，从这个层面来看它又是艺术。软件架构师怎样才能抓住关键的架构工件（architecture artifact），从而清晰地描述出整个解决方案呢？这正是难点所在。过度的设计和过多的文档，会拖慢项目的进度，并给项目的交付带来风险，而对软件架构所做的不恰当处理，则会使开发者无法领悟这套架构，这是个很关键的问题。如果开发者不能很好地理解软件的架构，那么他们就无法恰当地遵循技术方面的规范和限制，也无法恰当地使用这套架构来设计并开发系统中的各个部件。在软件开发的整个生命周期中，这个问题只会越来越严重。
2008年，笔者在IBM developerWorks网站上写了一系列专门谈论软件架构的文章。在连续发布4部分之后，由于某些个人原因，没有再往下写。接下来的几年，笔者看到了一些网友提出的问题，也收到了一些称赞，然而除此之外，还有另一类信息促使我进行更多的思考。比如，下面这两个问题：
“先生您好。我正在参考您的系列文章来撰写硕士论文。请问下一部分的文章什么时候发布？”
“Mitra先生，我们采用您所说的框架做了IT项目，但是项目暂停了，因为您的下一篇文章还没出来。求助。”
某一天早晨，我忽然感觉读者确实需要一本架构方面的书籍，它必须写得简单、明确、易于理解、便于描述，而且最为重要的是，它必须足够实用，能够执行。这本实用的书籍要能够给IT工作者和软件工程专业的学生带来较大的帮助，使他们明白怎样对软件系统进行架构。过了一段时间之后，我终于决定开始写书了。本书代表着软件架构领域中的集体智慧、经验、学问和知识，这些内容是笔者根据自己从业18年来的经历收集而成的。本书面对的读者有很多，其中包括：
软件架构师。书中会给出一些实用而且可以反复运用的指导原则，以帮助软件架构师来研发软件的架构。
项目经理。本书将会帮助读者理解并领会系统架构中的关键元素，它们是良好的架构所必备的元素，本书还会解释怎样才能在进行项目规划时把架构活动控制得恰到好处。
高校学生。本书将会帮助大家理解怎样把软件架构中的理论转述成实际的问题，并对其加以实现。无论技术如何发展，本书都可以当作长期的参考资料。
教师。通过本书，教师可以帮助学生把软件架构中的各种理论与实际工作联系起来，使学生变成能够应对实际项目的软件架构师。
首席管理者（C-level executive）或高层管理人员。本书将会帮助他们意识到研发良好的系统架构所必备的要素，对于IT界的任何一种创新活动来说，这种意识都会给公司带来间接的好处，使他们可以更好地领悟IT架构在整个公司中的基础地位。
笔者想把这本书写成一本实用的教程，使读者可以按照里面所说的方法，通过多个阶段的演进来迭代式地构建出软件的架构。书中会指出各种架构工件的运用方式，使大家可以把这些清晰、简明、精准而且易懂的工件，恰到好处地运用在实际的应用场景中。在整本书中，笔者会以较为随意的方式来使用“软件”（software）“系统”（system）和“解决方案”（solution）这三个词，由于它们在本书中指的都是架构（architecture），因此这三者之间是可以互换的。笔者之所以要采用这种不拘于字面意思的交替指称方式，是为了使大家明白：在IT界，这三个词之间的界限其实是相当模糊的。
从哲学角度来看，东方哲学和西方哲学之间的区别，在于它们对直觉和理性这两种感知形式的接受程度有所不同，前者更强调直觉，而后者更强调理性。西方世界普遍相信，并且主要依赖于理性的、科学的和演绎式的推理。而东方世界则更加看重凭直觉所获取的知识，他们认为，更高形式的意识（在这里指的是知识）是通过观察（也包括反思自己的内心世界）得来的，而不是仅仅通过实验式的归纳得来的。笔者生长于印度加尔各答一个文化较为多元的孟加拉家庭中，十分认同东方式的信仰和知识观念，我认为自觉的意识最终需要通过自觉的自由意志来获得，知识的奥义也要通过直觉和归纳式的推理来领悟。后来，笔者在西方世界生活了将近20年，在这段时间里，我开始看重科学和理性的知识形式。我认为，一个普通人要想在这个残酷竞争的世界中生存，就必须掌握由理性与科学手段所得到的知识，对于科学、技术和IT领域来说更是如此。等到自己的工作稳定下来之后，可以去深入探索直觉感知力和归纳式推理，这种探索虽然未必会带来回报，但或许会帮助我们从人生的存在中求得解脱。
在这本书中，笔者试着用一种解说的办法，通过归纳式的理性推理来帮助读者掌握实用的软件架构方式。等到掌握了这种理性的知识之后，读者可以把注意力放在归纳式的推理上，以探求更为玄妙的直觉知识。如果把解决最困难的架构问题比喻成寻求圣杯（Holy Grail），那么用直觉来感知软件的架构就相当于层次更高的开悟了，这种境界，我想应该是大家梦寐以求的吧。
等到看完本书并掌握了它的要义之后，希望你能焕然一新，变成一位务实的软件架构师。软件架构是个有趣的学科，其中的理性知识，我想读完这本书之后，大家应该就可以了解到。而凭直觉才能获得的那一部分知识，则需要以理性知识为基础，继续去探索。在这一方面，连笔者也只是刚刚入门而已。
另外再说一句，每章开头的那些格言，其实都是笔者自己编的。




出版在【华章出版社】 作者：[印]蒂拉克·米特拉（Tilak Mitra）