实用软件架构：从系统环境到软件部署 pdf epub mobi txt 电子书 下载 2025

简体网页||繁体网页

☆☆☆☆☆

[印] 蒂拉克·米特拉 著，爱飞翔 译

出版社： 机械工业出版社

ISBN：9787111550266

版次：1

商品编码：12101220

品牌：机工出版

包装：平装

丛书名： 架构师书库

开本：16开

出版时间：2016-12-01

用纸：胶版纸

页数：257

内容简介

　　《实用软件架构：从系统环境到软件部署》是一本实用的教程，使读者可以按照书中所说的方法，通过多个阶段的演进，来迭代式地构建出软件的架构。书中指出了各种架构工件的运用方式，使人可以把这些清晰、简明、精准而且易懂的工件，恰到好处地运用在实际的应用场景之中。本书简单、明确、易于理解、便于描述，而且足够实用，能够加以执行。可给IT工作者和软件工程专业的学生带来较大的帮助，使他们明白怎样对软件系统进行架构。

目录

题献
译者序
序
前言
致谢
第1章　案例研究 1
1.1　业务问题 1
1.1.1　技术挑战 2
1.1.2　用例 2
1.1.3　在机器运转过程中进行实时处理与监控 3
1.1.4　为新机器提供无缝的激活服务 3
1.1.5　生成工作定单 3
1.1.6　尽量减少在为全球客户提供服务时所产生的延迟 4
1.2　小结 4
第2章　软件架构是什么？为什么需要做软件架构 6
2.1　背景知识 6
2.2　软件架构是什么 7
2.3　为什么需要做软件架构 9
2.3.1　把架构视为交流工具 9
2.3.2　对项目规划施加影响力 10
2.3.3　关注非功能方面的能力 11
2.3.4　与设计团队和实现团队做出约定 12
2.3.5　为影响力分析提供支持 12
2.4　架构视图与架构视点 13
2.5　小结 16
2.6　参考资料 16
第3章　恰到好处地把握架构中的重要方面 17
3.1　软件架构中需要关注的一些方面 17
3.2　小结 19
第4章　系统环境 20
4.1　业务环境与系统环境之间的辨析 20
4.2　捕获系统环境 22
4.2.1　系统环境图 23
4.2.2　信息流 25
4.3　案例研究：Elixir的系统环境 27
4.3.1　Elixir的系统环境图 27
4.3.2　Elixir的信息流 32
4.4　小结 33
4.5　参考资料 33
第5章　架构概述 34
5.1　什么是架构概述 34
5.2　为什么要做架构概述 36
5.3　企业视图 37
5.3.1　用户与传输渠道 39
5.3.2　核心业务流程 39
5.3.3　数据与信息 40
5.3.4　技术推动力 41
5.4　分层视图 42
5.4.1　第1层：操作层 45
5.4.2　第2层：服务组件层 45
5.4.3　第3层：服务层 45
5.4.4　第4层：业务流程层 46
5.4.5　第5层：消费者层 46
5.4.6　第6层：集成层 46
5.4.7　第7层：QoS层 46
5.4.8　第8层：信息架构层 47
5.4.9　第9层：治理层 47
5.4.10　进一步研究分层视图的用法 47
5.5　IT系统视图 48
5.6　案例研究：Elixir的架构概述 53
5.6.1　Elixir的企业视图 53
5.6.2　Elixir的业务流程 54
5.6.3　Elixir的数据及信息 54
5.6.4　Elixir的技术推动力 55
5.6.5　Elixir的分层视图 56
5.6.6　Elixir的IT系统视图 57
5.7　小结 58
5.8　参考资料 59
第6章　架构决策 60
6.1　为什么需要做架构决策 60
6.2　怎样开始进行架构决策 61
6.3　创建架构决策 62
6.4　案例研究：Elixir的架构决策 67
6.5　小结 69
第7章　功能模型 71
7.1　为什么需要功能模型 71
7.2　可追溯性 73
7.3　制定功能模型 74
7.3.1　逻辑层面的设计 75
7.3.2　规格层面的设计 79
7.3.3　物理层面的设计 89
7.4　案例研究：Elixir的功能模型 91
7.4.1　逻辑层面 92
7.4.2　规格层面 94
7.4.3　物理层面 97
7.5　小结 98
7.6　参考资料 99
第8章　操作模型 100
8.1　为什么需要操作模型 101
8.2　可追溯性与服务级别协议 102
8.3　制定操作模型 104
8.3.1　概念操作模型 105
8.3.2　规格操作模型 116
8.3.3　物理操作模型 122
8.4　案例研究：Elixir的操作模型 132
8.4.1　COM 132
8.4.2　SOM 137
8.4.3　POM 138
8.5　小结 140
8.6　参考资料 141
第9章　集成：方式与模式 142
9.1　为什么需要进行集成 142
9.2　集成方式 143
9.2.1　用户界面的集成 144
9.2.2　数据层面的集成 144
9.2.3　消息层面的集成 147
9.2.4　API层面的集成 149
9.2.5　服务层面的集成 150
9.3　集成模式 152
9.3.1　同步的请求栂煊δＪ? 152
9.3.2　批次模式 153
9.3.3　同步的批次请求栍Υ鹉Ｊ? 153
9.3.4　异步的批次请求栍Υ鹉Ｊ? 153
9.3.5　存储并转发模式 154
9.3.6　发布柖┰哪Ｊ? 154
9.3.7　聚合模式 154
9.3.8　管道与过滤器模式 155
9.3.9　消息路由器模式 155
9.3.10　消息转换器模式 156
9.4　案例研究：Elixir的集成视图 156
9.4.1　标签1～5所表示的数据流 157
9.4.2　标签6～8所表示的数据流 158
9.4.3　标签9～10所表示的数据流 158
9.4.4　标签11～12所表示的数据流 158
9.5　小结 159
9.6　参考资料 160
第10章　基础设施问题 161
10.1　为什么要把基础设施做好 162
10.2　需要考虑的基础设施问题 162
10.2.1　网络 163
10.2.2　托管 165
10.2.3　高可用性与容错性 169
10.2.4　灾难恢复 178
10.2.5　能力规划 178
10.3　案例研究：Elixir系统的基础设施问题 181
10.4　小结 183
10.5　我们现在讲到什么地方了 184
10.6　参考资料 186
第11章　分析架构入门 187
11.1　为什么要做分析 188
11.2　进行数据分析所采用的维度 189
11.2.1　操作分析 189
11.2.2　描述性的分析 190
11.2.3　预测性的分析 190
11.2.4　指示性的分析 191
11.2.5　认知计算 192
11.3　分析架构的基础 194
11.3.1　分层视图中的各层及五大支柱 195
11.3.2　水平层 196
11.3.3　垂直层 199
11.3.

前言/序言

　　前言　　软件架构这个学科已经有半个世纪的历史了。此概念于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），那么用直觉来感知软件的架构就相当于层次更高的开悟了，这种境界，我想应该是大家梦寐以求的吧。 　　等到看完本书并掌握了它的要义之后，希望你能焕然一新，变成一位务实的软件架构师。软件架构是个有趣的学科，其中的理性知识，我想读完这本书之后，大家应该就可以了解到。而凭直觉才能获得的那一部分知识，则需要以理性知识为基础，继续去探索。在这一方面，连笔者也只是刚刚入门而已。 　　另外再说一句，每章开头的那些格言，其实都是笔者自己编的。 　　致谢首先要感谢妻子Taneea和母亲Manjusree，她们给了我写书所需的时间和灵感。感谢我的叔叔Abhijit始终支持我，使我相信自己能够写完这本书。还要感谢我的独子Aaditya，他总是关心我为什么又要去写一本书。 　　在专业写作这一方面，我真诚地感谢本书的执行负责人Ray Harishankar，他从头至尾陪着我走过这段愉快的写作之旅。我还要感谢同事Ravi Bansal帮我审阅并完善本书的章节结构，并给我提供相关的专业知识。感谢来自德国的同事Bertus Eggen，他提出了一个绝妙的数学算法，使我可以针对服务器之间的网络连接度来设计容量模型。感谢Bertus允许我在书中使用他的想法。Robert Laird十分热心地审阅了本书，并提出了相当宝贵的意见，对此我表示衷心的感谢。还要感谢Craig Trim给我提供了自然语言处理方面的一些内部细节和技术。 　　Grady Booch先生能够为本书作序，令我深感荣幸，在此衷心感谢。 　　感谢上苍把Aaditya赐给我们。2010年出生的他，给我带来了无尽的快乐，接下来的几年里，我要好好地看着他长大。他已经有了几分“大志”，而且想变成和我一样的人，不过，我还是要引领他，让他更加上进。
　　序软件架构这个词，有些人听了觉得开心，有些人听了要皱眉头，而更多的人对它漠不关心，尤其是那些整天忙着敲代码，没时间思考设计问题的人。 　　我们知道，软件密集型的系统都是有架构的。有一些架构是刻意而为的，有一些架构是偶然浮现出来的，还有很多架构隐藏在成千上万个小的设计决策中，而这些设计决策，正源于我们敲出来的那些代码。 　　Tilak先生在本书中精彩地讲解了一些切实可行而且非常实用的方式与方法，以帮助我们架构出复杂的系统。作者是一位拥有实际经验的架构师，他通过一系列案例研究，解释了“架构是什么”以及“架构不是什么”这两个问题，同时还讲解了在软件密集型的系统中，如何使架构成为开发、交付及部署过程的一部分。如果大家了解我，那一定知道我对软件架构这个主题有一些强烈的个人观点，然而在我读过的关于这个主题的那么多本书和那么多篇文章中，我确实觉得Tilak所说的这套方法是建立在坚实的基础之上的，而且他的方法特别容易理解，也特别容易施行。 　　软件架构并不是一项纯粹的技术，其中还要考虑人的因素。本书正是抓住了这个重要的因素—Tilak把自己在架构工作中汲取的经验教训合理地穿插在本书中，我很欣赏这一点。 　　架构是个重要的过程，这个过程不仅不能妨碍系统的构建，而且还必须在恰当的时机以合适的资源和特别实用的方式构建出正确的系统。 　　Grady BoochIBM院士及软件工程首席科学家

评分☆☆☆☆☆

还没看完，看后再评价

评分☆☆☆☆☆

还不错，，，

评分☆☆☆☆☆

是正品，慢慢看，感觉还不错的

评分☆☆☆☆☆

看起来是实战类型的书，希望不是啰嗦个没完的。

评分☆☆☆☆☆

咕咕咕咕咯咯咯咯咯咕咕咕咕古古怪怪嘎嘎嘎嘎gggggggggggggg

评分☆☆☆☆☆

不错，没有什么问题！！

评分☆☆☆☆☆

包装虽然没破损，但是外表确实不怎么样，这是第二次遇到包装的问题，还好没破损

评分☆☆☆☆☆

符合我的预期

评分☆☆☆☆☆

不错，没有什么问题！！