(特价书)多核应用架构关键技术—软件管道与SOA

2.3 管道定律：基本法则 12
2.4 推论1：流量限制 12
2.5 推论2：输出流的约束 13
2.6 软件管道规则 14
2.7 规则1 14
2.8 规则2 15
2.9 规则3 17
2.10 小结 20
第3章 管道示例 21
3.1 银行ATM系统（单层分布） 21
3.1.1 管道 21
3.1.2 管道分配器 22
3.2 银行ATM系统（多层分布） 23
3.2.1 下层管道层 24
3.2.2 上层管道层 27
3.3 小结 28
第4章 管道模式 30
4.1 服务调用模式 31
4.1.1 推模式 31
4.1.2 拉模式 31
4.2 消息交换模式 32
4.2.1 一路交换模式 32
4.2.2 请求—应答模式 33
4.3 管道路由模式 34
4.3.1 轮循路由模式 34
4.3.2 基于内容的路由模式 35
4.3.3 定制路由模式 36
4.3.4 加入模式 36
4.4 分配器模式 37
4.4.1 单一分配器模式 37
4.4.2 多层分配器模式 38
4.4.3 客户端分配器模式 39
4.4.4 数据库分片分配器模式 40
4.5 分配器连接器模式 40
4.5.1 本地方法调用模式 41
4.5.2 Socket调用模式 41
4.5.3 Web服务调用模式 41
4.5.4 其他模式 42
4.6 小结 42
第5章 管道：公司的影响 43
5.1 战略评估 43
5.2 预算影响 44
5.3 公司职位与责任 46
5.3.1 管道架构师 46
5.3.2 业务部门领导骨干 47
5.3.3 IT部门管理人员 48
5.3.4 应用开发人员 49
5.3.5 应用项目管理者 50
5.3.6 质量保证管理者 50
5.3.7 IT运营部 51
5.4 小结 51
第二部分 管道方法学
第6章 软件管道优化周期：概述 54
6.1 另一种软件方法学 54
6.2 SPOC概述 54
第7章 SPOC的5个步骤 56
7.1 软件管道优化周期文档 56
7.2 小结 57
第8章 管道示例：管道银行公司
第8章 介绍 58
8.1 SPOC报告模板 60
8.2 小结 61
第9章 SPOC第一步：管道目标 62
9.1 步骤1.1：确定业务目标/需求 63
9.2 步骤1.2：确定输入处理率 66
9.3 步骤1.3：检测未来潜在的输入
9.3 处理速率 67
9.4 步骤1.4：当前处理能力
9.3 的测定 69
9.5 步骤1.5：计算性能差距 70
9.6 步骤1.6：定义管道目标 71
9.7 小结 72
第10章 SPOC步骤2：管道分析 73
10.1 步骤2.1：映射目前处理流程 74
10.2 步骤2.2：确定现有的组件 76
10.3 步骤2.3：测定现有组件的
10.3 处理速率 77
10.4 步骤2.4：计算整个流程的
10.3 处理速率 79
10.5 步骤2.5：确定约束点 80
10.6 小结 81
第11章 SPOC步骤3：管道设计 82
11.1 步骤3.1：定义服务流程
11.1 设计 83
11.2 步骤3.2：确定新的组件 86
11.3 步骤3.3：确定管道化时机 87
11.4 步骤3.4：确定管道方案 89
11.5 步骤3.5：确定分配器
10.3 处理速率 93
11.6 步骤3.6：物理部署环境
10.3 的设计 94
11.7 步骤3.7：确定/优化管道
11.7 设计 95
11.8 小结 104
第12章 SPOC步骤4：管道实现 105
12.1 步骤4.1：构建软件管道框架 106
12.2 步骤4.2：修改现有的组件 107
12.3 步骤4.3：开始新的组件 109
12.4 步骤4.4：编排服务流程 110
12.5 步骤4.5：仪表化服务流程 112
12.6 步骤4.6：开发/修改管道
10.3 套件 112
12.7 步骤4.7：测试并优化
10.3 管道实现 119
12.8 小结 120
第13章 SPOC步骤5：管道部署 121
13.1 步骤5.1：规划管道部署 122
13.2 步骤5.2：部署到产品
10.3 环境中 122
13.3 步骤5.3：检测产品环境 123
13.4 步骤5.4：评估结果，规划下
10.3 一次SPOC迭代过程 124
13.5 小结 124
第三部分 管道示例
第14章 Hello软件管道 126
14.1 定义消息 126
14.2 构建服务 127
14.3 配置分配器 129
14.4 创建客户端 130
14.5 运行服务 133
14.6 小结 133
第15章 扩展Hello软件管道 134
15.1 扩展服务 134
15.2 开发可扩展的测试客户端 135
15.3 运行服务 138
15.4 小结 142
第16章 增加的管道路由器配置 143
16.1 基于内容的路由器 143
16.2 定制管道路由器 152
16.3 小结 163
第17章 从Hello软件管道
第22章 获得应答 164
17.1 请求——响应消息传递 164
17.2 在Hello软件管道中使用
10.3 请求——响应 167
17.3 小结 177
第18章 增添的分配器连接器模式 178
18.1 定义并配置连接器 178
18.2 Socket连接器 180
18.3 Web服务连接器 181
18.4 小结 183
第19章 使用多层分配器 184
19.1 配置多层分配器 184
19.2 创建客户端 188
19.3 运行服务 190
19.4 小结 191
第20章 数据库分片分配器 192
20.1 数据库分片示例 193
20.2 创建数据库分片 194
20.3 构建服务 194
20.4 配置分配器 197
20.5 配置分片驱动 198
20.6 创建客户端 199
20.7 执行服务 201
20.8 小结 202
第21章 管道框架概要 203
21.1 接口概要 203
21.2 管道工具 205
21.3 小结 211
第22章 管道银行公司（PBCOR）
第22章 示例 212
22.1 账户交易事务 213
22.2 管道配置信息 215
22.3 Spring框架 218
22.4 数据库访问 219
22.5 连接服务 225
22.6 运行测试 229
22.7 小结 230
第四部分 软件管道的未来
第23章 软件管道的未来 232
23.1 最后的建议 232
23.2 未来的一些想法 233
附录 管道参考架构Javadoc 235

.　　我们已经在softwarepipe-lines.org建立了一个软件管道技术的网站。该网站是为在使用或改进软件管道架构感兴趣的本书读者或其他人员建立的。您可以从网站下载下面各项：
　　·软件管道优化周期方法论的工具和示例报告模板
　　·管道参考框架的源代码
　　·本书中所有示例的完整源代码
　　·所有对管道技术与应用的讨论与文章。
　　我们希望您发现我们为您找到的软件管道技术是如此令人兴奋，你借此机会利用其能力，使用它来帮助克服自己系统在性能和扩展性方面的挑战。
　　致谢
　　有许多人为软件管道的发展作出过贡献，他们中的一些人也参与了这本书英文第1版的编写工作。我深深地感谢贡献创意、忘我投入、完成大量工作并对这个项目给予鼓励和支持的所有人。我不能说出每个人的名字，但正是他们所作的奉献才使得这项工作成为可能：
　　Ravi Palepu，是我们最好的朋友和商业伙伴，在讨论管道的构想过程中，陪我很长的时间，并帮助制定最初的概念，概括出现在的工作。
　　Rogue Wave Software 公司的Patrick Leonard与David Haney与我创建了管道的核心概念，形成了当前工作的基础。
　　我还要感谢Rogue Wave软件公司在我任公司总裁期间及之后对我的支持。
　　Barbara Howell是本书的插图作者还是令人难以置信的专业编辑，书中的插图都是她创作的；没有她我不会完成这个工作。她的执着、注重细节与天分让我能够通过书中的图表与图形就能将关键的概念介绍清楚，这真是太棒了。
　　Colin Holm提供了大部分的代码示例，以及在第三部分对管道参考框架的介绍。对于本书最后的内容，Colin的洞察力与工作是非常重要的。他有能力创建出从真实的商业应用程序员（他可以帮助将软件管道从概念转变到现实）的视角出发的示例。
　　最后，我要感谢我的家人，特别是我的妻子Kim为完成本书所作的巨大奉献。我还要感谢睿智的、善解人意的孩子们的理解与合作。事实上，我的大儿子，Devyn（一个真正的数学奇才），帮助我理清管道定律的公式；我的小儿子，Tyler，他是本书各种想法与如何展示的决策人。
　　作者简介
　　Cory Isaacson是Prelude Innovations公司（一个特别关注先进软件技术产品孵化和推荐的公司）的CEO。他积极参与领导信息技术工作20多年。Cory担任WebSphere Advisor杂志的技术编辑与专栏作家，在数百场的公众活动和研讨会上发表演说，并撰写关于架构和实用性技术的大量文章。Cory为数百个顶级架构师和专业开发人员（他们负责商业服务、娱乐、电信与软件行业的强大商业应用的开发与实现）提供指导。
　　最近Cory担任Rogue Wave Software公司的总裁，3年来担任公司管理，建立新产品战略，并在2007年中期被一家私人控股公司成功收购。Cory关注的重点是有效地解决诸如SOA、可视化和支持实际业务应用的商品化资源的新技术开发和部署的挑战性问题。Cory具有高性能的事务处理应用的专业知识，帮助先进IT企业对数据与业务数量上的急剧增长做出响应，同时还解除了经营成本的压力。最近，Cory一直是在多核架构上为了改善应用程序性能而使用并行处理和可伸缩的数据库技术的积极倡导者。
　　Cory在美国加州圣巴巴拉大学获得学士学位。
　　简介
　　纵观整个IT发展历史，专业开发人员一直在寻找提高关键业务应用性能的方法。计算机行业一直试图寻找答案，而且我们已经看到了很多解决方案、架构和方法。显然，这个问题不是小问题。在今天以信息为基础的经济结构中，往往由公司的软件性能来决定事业的成功与失败。有很多这样的案例：银行系统、交易系统、呼叫中心的运营部门、报告服务，以及许多其他行业也都依赖于高性能需求的应用。在这些行业中，公司开展业务的速度直接关系到该公司的生存能力。缓慢、不胜任或无响应的应用程序对公司运营与最终赢利与否造成破坏；最终，这些应用程序实际上可以让依赖于它的公司垮掉或受到损害有加剧。情况还不止如此，当我们做生意时越来越依赖于信息交流，性能会拖住需求（想进一步发展）的后腿。
　　还有另外一个问题。只让单个组件获得更快的性能是不够的。如果你的公司安装了一个新的应用，如果业务进行了扩展，或如果处理的数据量向上攀升，你可能会突然需要性能逐次提高5倍、10倍、20倍，甚至更多。
　　其他因素也非常关键：你要如何让软件快速满足新的需求和应对竞争威胁？软件的推广及迅速采用面向服务的架构（SOA）是需要更加灵活的软件系统的确凿的证据。
　　SOA是一种先进的技术。与早期的IT架构发展趋势相比，SOA能更好地兑现自己的承诺。但它也向自己提出了挑战。出于下述原因，如果您使用SOA进行开发，性能和伸缩性显得更加重要：
　　·一般来说，SOA比以前单机或紧耦合系统的设计需要更高的计算能力。
　　·需要注意的是，松散耦合服务实现的是以消息为中心的应用开发。开发者不仅要编写传统的处理逻辑，还必须处理信息传输、验证、解释、产生——所有这一切都是CPU与处理密集型的应用。
　　·随着越来越多的公司使用SOA方法，我们可以预计消息传递量的增加和其对现有IT系统带来的巨大负担。潜在的不利影响将逐渐升级。
　　预测表明，在未来一两年内，使用SOA的公司将遇到性能问题。从历史上看，这并不是什么新鲜事，每当商业界采用新的软件架构，它便会经历痛苦的成长过程。过去二十年里，每个新的软件开发模式转变带来的震荡时期会历时1～3年的调整阶段（任何早期的J2EE用户都可以证明这一点）。在此期间，业务逐步采用了新的设计方法，当这样做时，它们仍面临与性能和伸缩性相关的问题。在许多情况下，软件开发者不能克服陡峭的学习曲线，部署的应用程序不能按预期运行，于是许多项目很快以失效告终。
　　直到最近，硬件成为这类不成熟架构的唯一可取之处。每当计算机业界取得了重大进展，主要在CPU性能方面，于是通过更快的芯片或使用一些其他机械式解决方案，可以消除性能瓶颈。现在这样的好情况已经不再存在。我们遇到微处理器技术的停滞期，主要由物理因素造成的，如电力消耗、发热与散热和量子力学效应。业界再也不能简单地增加单CPU的时钟速度。因此，从现在与能预见的未来，CPU厂商正依赖于新的多核设计，增加处理能力。如果你想从多内核芯片获益，软件必须实现并行处理，它还不是今天主流应用普遍具有的能力。
　　让我们从企业的软件体系架构总结一下现今他们的真正需求：
　　·对于性能和伸缩性，要有一个切实可行的并行处理办法
　　·灵活性，让商业适应市场和其他的环境变化
　　特别是在使用传统的手段时，创建具有这些特性的应用是不容易的。此外，在现实世界中，做这样的模式转换工作需要具有商业知识和一定技术专长的专业开发人员。简言之，专业开发人员需要一系列为实现这些目标（针对业务应用在一个新的层面上进行并行处理）而设计的工具集。
　　因此，灵活、适当、实用的并行处理方法需要的是什么已成为一个问题。软件管道技术正是为了实现这个目的而开发出来的方法，它为专业的开发人员提供一套可用的开发工具和为应对今天的商业应用环境激烈的竞争提供可伸缩处理能力。
　　大家如何对待并行处理
　　作为本书中我们研究的一部分，我们希望找出软件社区对并行处理的一些想法，所以我们对相关的Web文档进行了统计分析。我们的分析工具比较了在Web 上文件中使用的单词及其频率，来显示出某一特定主题的总趋势。结果很有意思，他们确认并行处理是现代计算挑战的重要解决方案。
　　为了分析，我们基于对“软件”这一主题词的查询，并查阅参考资料来找出该主题下的相关术语。我们是从下面的术语开始的：
　　·多核
　　·多线程
　　·并行处理
　　·并行编程
　　我们在本节中用若干个图表显示结果。图0.1显示了人们使用术语的频率。正如你所看到的，并行编程是最流行的术语，其次是多核，然后是并行处理。它给我们一个好想法来了解软件社区对该话题的讨论。
　　图0.1 软件查询结果
　　要获得更详细的查询，我们按照以下特点将每个术语交叉结合起来分析：
　　·复杂
　　·困难
　　·重要
　　·知识
　　·有用
　　在图0.2中，你可以看到并行处理的每个特点间的关系。并行处理因为具有两个关系最紧密的特点，被认为是“有用的”和“重要的”。
　　图0.3显示了并行编程和它的一些特点。并行编程肯定是“重要的”，但文档中有很高的比例提到，它是“困难的”。有趣的是，“知识”这个特点具有较高的排名，这并不奇怪，因为对于缺乏该技术经验的普通人来说并行编程很困难。
　　图0.4和图0.5显示多核心与多线程的特点。这两个图反映了与并行编程类似的信息。
　　
　　图0.2 并行处理的特点 图0.3 并行编程的特点
　　
　　图0.4 多核的特点 图0.5 多线程的特点
　　图0.6给出包括所有术语和特点，它显示了每个组合的相对强度。你可以看到，并行处理被认为是“有用的”，而并行编程是“重要的”和“困难的”。
　　
　　图0.6 所有术语的特点
　　从上面谈到的这些，你能得到什么结论？看来人们认为并行处理是重要但并不容易实现。我们希望可以帮助您做起来更容易一些。软件管道的目标，以及我们编写本书的目标，就是：为应对这一挑战提供切实可行并有用的一套技术，我们决心让你发现它对你自己的应用开发和企业管理很有帮助。