具体描述
云计算和SOA是不同的概念，但是它们却互相联系。SOA是架构模式，而云计算是架构的实例，或者说是一种架构的选择。SOA更具整体性和战略性，它解决的是包括业务驱动力在内的整个企业架构的问题，而云计算则更加侧重战术，它是一种解决问题的方式。它们联系紧密，若要解决企业级的问题，很难取其一而舍其二。
本书堪称云计算与SOA融合之经典著作。书中介绍了企业架构中存在的问题，云计算的价值、优缺点和适用场景；解释了向云计算转型的技术细节、支撑技术和最佳实践方法；帮助你客观评估自己企业中云计算和SOA的可行目标，对其实用价值进行了量化估算并构建了商业案例；概览了如何评估已有的IT基础设施，如何找到通向“云”的最高效、最安全的路径；展示了如何为云平台选择最合适的候选数据、服务和流程；如何对云平台进行更高效的治理等。
作者简介
David S. Linthicum Blue Mountain实验室的CTO和创始人，国际知名的云计算和SOA专家。曾任多个成功的软件公司的CTO和CEO，也在财富100强企业中担任过高层管理职位。他著有十多本技术图书。多年来一直在InfoWorld、Intelligent Enterprise和eBizq.net等博客网站上发表文章，剖析SOA与云计算等方面的问题。Government Computer News、Cloud Computing Journal、SOA Journal和 Align Journal等刊物上均开设有他的专栏，同时他还是Virtualization Journal的编辑。更频频现身于云计算、SOA、Web 2.0和企业架构等方面的前沿技术大会上发表专题演讲。他在企业应用集成、B2B应用集成和SOA等方面的许多理念，得到了广泛应用。最近十年，他致力于研究云计算相关的技术与战略，以及如何使云计算为当今企业所用。
目录信息
1.1 事情因何而失控 2
1.2 SOA来拯救 3
1.3 SOA究竟是什么？关我何事 4
1.4 SOA遇见云计算 6
1.5 定义云计算 7
1.6 云计算的组件 9
1.7 云计算与SOA的梦幻组合 11
1.8 SOA可从云计算中学到什么 13
1.8.1 服务设计 13
1.8.2 服务的可扩充性 13
1.9 云计算可从SOA中学到什么 14
1.9.1 服务治理 14
1.9.2 由架构驱动 14
1.10 跨入云计算世界 14
1.11 立足于积极的颠覆性变化 15
第2章 理解云计算 17
2.1 深入理解云计算 18
2.2 云计算有何新意 20
2.3 云的潜在价值 23
2.4 云计算的优缺点 23
2.4.1 优点 23
2.4.2 缺点 25
2.5 何时适合使用云计算 27
2.6 做点与众不同的事 29
第3章 面向企业的云 31
3.1 存储即服务 33
3.2 数据库即服务 34
3.3 信息即服务 36
3.4 流程即服务 41
3.5 应用即服务 43
3.6 平台即服务 45
3.7 集成即服务 46
3.8 安全即服务 47
3.9 管理/治理即服务 48
3.10 测试即服务 48
3.11 基础设施即服务 49
3.12 下一步 49
第4章 云计算的商业案例 51
4.1 定义整体价值 52
4.1.1 运维成本的降低 52
4.1.2 节约资本 56
4.1.3 随需扩容 57
4.1.4 随需收缩 58
4.1.5 风险转移 58
4.1.6 被提供商抛弃的风险 60
4.1.7 敏捷和重用 60
4.1.8 “酷”技术的价值 62
4.1.9 设计商业案例 63
4.2 一切都是商业 67
第5章 云计算与数据 69
5.1 旧还是新 70
5.2 数据为要 71
5.3 选择问题域 73
5.4 定义信息模型 74
5.4.1 理解本体 75
5.4.2 理解数据 77
5.4.3 标识数据 79
5.4.4 数据目录 85
5.5 创建信息模型 87
5.5.1 逻辑模型 87
5.5.2 物理模型 88
5.6 数据在融合云计算的SOA架构中的重要性 89
第6章 云计算与服务 91
6.1 服务包含可移动部分 95
6.2 服务是什么 99
6.3 理解云的耦合性 100
6.4 你的架构是松耦合的吗 102
6.5 定义元服务 103
6.6 创建服务目录 104
6.7 从服务级认识问题域的必要性 107
第7章 云计算与流程 109
7.1 何为BPM 110
7.2 将流程移入云 112
7.3 定义流程 114
7.4 SOA、敏捷及流程 117
7.5 BPM对于云的价值 119
7.6 深入探讨BPM 121
7.7 BPM和云计算 122
第8章 可控的云计算 123
8.1 人员与流程 125
8.2 云中的治理 126
8.3 建立治理模型 130
8.3.1 定义策略 130
8.3.2 设计策略 131
8.3.3 实现策略 132
8.4 治理技术 134
8.5 服务治理的价值 136
第9章 SOA与云计算 137
9.1 为何我们需要尝试新的测试 138
9.2 从企业到云平台的测试和反向测试 139
9.2.1 如何测试整个架构 139
9.2.2 服务层测试 141
9.2.3 安全层测试 144
9.2.4 流程层测试 144
9.2.5 治理层测试 144
9.2.6 集成层测试 144
9.2.7 信息层测试 145
9.3 制定测试计划 146
9.4 黑盒云测试 147
9.5 测试相当重要 149
第10章 在云平台中定义候选数据、服务和流程 151
10.1 应用程序在哪里 152
10.2 云计算何时适用 156
10.2.1 数据、服务、流程和应用非常独立（或松耦合）的场合 157
10.2.2 集成点定义良好的场景 158
10.2.3 较低级别的安全就已足够的场景 158
10.2.4 核心的内部企业架构非常健壮的场合 159
10.2.5 期望的用户接口是浏览器的情况 159
10.2.6 资金紧缺时 162
10.3 应用程序和服务较新时 163
10.4 迈向云计算 164
第11章 迈向云计算 165
11.1 选择平台 166
11.2 向云计算迁移之过程 171
11.2.1 列出候选平台 172
11.2.2 分析及测试候选平台 176
11.2.3 选择目标平台 177
11.2.4 部署至目标平台 178
11.3 何为私有云 180
11.4 新“云化”平台 181
第12章 拥抱未来 183
· · · · · · (收起)
读后感
前几天参加了HTML5研究小组的翻译送书的活动，有幸获得了一本《云计算和SOA》。第一次看到SOA这个名词还是在《程序员》杂志，同时还伴随着另外一个名词就是SaaS。又过了几年开始听到有了云计算的概念，但是并不了解此为何物。2009年参加了CSDN的软件开发2.0大会，听到了中...
评分前几天参加了HTML5研究小组的翻译送书的活动，有幸获得了一本《云计算和SOA》。第一次看到SOA这个名词还是在《程序员》杂志，同时还伴随着另外一个名词就是SaaS。又过了几年开始听到有了云计算的概念，但是并不了解此为何物。2009年参加了CSDN的软件开发2.0大会，听到了中...
评分前几天参加了HTML5研究小组的翻译送书的活动，有幸获得了一本《云计算和SOA》。第一次看到SOA这个名词还是在《程序员》杂志，同时还伴随着另外一个名词就是SaaS。又过了几年开始听到有了云计算的概念，但是并不了解此为何物。2009年参加了CSDN的软件开发2.0大会，听到了中...
评分前几天参加了HTML5研究小组的翻译送书的活动，有幸获得了一本《云计算和SOA》。第一次看到SOA这个名词还是在《程序员》杂志，同时还伴随着另外一个名词就是SaaS。又过了几年开始听到有了云计算的概念，但是并不了解此为何物。2009年参加了CSDN的软件开发2.0大会，听到了中...
评分前几天参加了HTML5研究小组的翻译送书的活动，有幸获得了一本《云计算和SOA》。第一次看到SOA这个名词还是在《程序员》杂志，同时还伴随着另外一个名词就是SaaS。又过了几年开始听到有了云计算的概念，但是并不了解此为何物。2009年参加了CSDN的软件开发2.0大会，听到了中...
用户评价
让我感到最困惑的一点是，全书的语言风格和论述角度显得非常“学术化”和“宏大叙事”，缺乏与实际工程环境的连接点。很多章节都在讨论“理想化的状态”下，系统应该如何运行，架构应该如何优雅。但现实世界是充满约束的——预算限制、遗留系统的捆绑、团队技能的短板，这些都是架构师必须面对的现实。这本书几乎完全避开了这些“脏活累活”。比如，在讨论数据一致性时，它详细阐述了Paxos和Raft算法的原理，但完全没有提及在实际的OLTP数据库中，如何处理因网络分区导致的最终一致性问题，也没有讨论如何设计一个能平滑过渡的“数据迁移”方案。对于一个期望通过阅读来提升解决实际问题的能力的读者来说，这种脱离工程实践的纯理论探讨，虽然有助于提升理论素养，但对于提升日常工作中的交付能力，帮助微乎其微。它更像是一篇优秀的硕士毕业论文的精简版，而非一本面向专业工程师的工具书。
评分如果说这本书有什么亮点的话，那可能是在历史回顾这部分做得还算扎实。作者对早期分布式计算的挑战，以及面向对象思想如何影响了后来的架构设计趋势，进行了相当细致的梳理。读起来像是进入了一个时间胶囊，能感受到技术思潮变迁的脉络。但是，一旦内容进入到近五年内发生的技术革新，那种详实度和深度就急剧下滑了。例如，在讨论弹性扩展时，书中对虚拟化和容器化技术的描述，明显停留在前几年的阶段，对于像eBPF在内核级性能优化方面的突破性进展，或者WebAssembly在边缘计算中的潜力，只字未提。这使得这本书的“时效性”成了最大的短板。我需要的是能指导我应对明天挑战的知识，而不是对昨天辉煌历史的缅怀。在这样一个日新月异的领域，技术书籍的生命周期往往很短，这本书的内容显然没有跟上最新的技术浪潮，拿来作为快速学习的工具是不适用的，更适合作为一种对早期架构理念的参考资料。
评分这本书的装帧设计倒是挺吸引人的，封面那种深邃的蓝色调，配上一些抽象的、像是数据流动的线条，初看之下就给人一种高科技、信息爆炸的感觉。我拿到手的时候，首先注意到的是纸张的质感，不是那种廉价的、一摸就出汗的纸张，而是略带哑光、拿在手里沉甸甸的，让人觉得这是一本“有料”的书。我原本是希望通过这本书来系统梳理一下现代企业IT架构演进的脉络，特别是那种面向服务的思想如何落地到实际的云环境中。然而，当我翻开目录，试图寻找那些关于微服务治理、API网关设计或者Serverless函数计算深度解析的章节时，却发现内容似乎集中在一个我不太熟悉的、偏向于传统企业级架构的视角。这种落差感是比较明显的，我期待的是对前沿技术实践的深入剖析，比如Kubernetes在复杂多云环境下的弹性伸缩策略，或者在金融领域如何利用零信任模型构建安全边界。这本书似乎更侧重于概念的铺陈和理论框架的构建，对于我们这些一线架构师急需解决的“如何做”的问题，提供的实操指导略显单薄，更像是教科书式的介绍，而非一本实战手册。如果定位是入门科普，或许合格，但对于追求效率和敏捷的现代开发团队来说，可能需要寻找其他更具操作性的资料来补充。
评分这本书的结构组织，从我的角度来看，存在一些明显的断裂感。它似乎想覆盖的领域太广，从基础的网络协议演变谈到高层的治理框架，试图搭建一座横跨多个技术栈的桥梁。然而，这种广度是以牺牲深度为代价的。我印象特别深刻的是关于“服务契约”的那一章，它花了大量篇幅讨论了文档规范的重要性，这一点我表示赞同，但当涉及到如何利用自动化工具（比如Schema验证工具或Mocking框架）来强制执行这些契约时，书中却草草带过，没有给出任何具体的工具链推荐或代码示例。这就像是教人游泳却只讲了水的重要性，却没教如何换气一样。对于我们项目组而言，我们在解决的就是如何确保CI/CD流程中，服务提供者和消费者之间依赖关系不会因为一方的无意修改而中断的问题。期待在这本号称是关于“系统构建”的书籍中，能找到关于集成测试和契约驱动开发（Contract-Driven Development）的有力论述，但很遗憾，这些关键的实践环节在书中几乎是缺失的，或者说被轻描淡写地一笔带过，让人感到十分失望。
评分说实话，我花了相当大的力气才读完前三分之一的内容，过程可谓是步履维艰。作者在阐述某些核心概念时，习惯性地会引用大量的缩写和行业术语，但往往在首次出现时，对这些术语的解释就显得非常简略，仿佛默认读者已经对这些背景知识了如指掌。我不得不频繁地停下来，打开搜索引擎查找这些名词的完整定义和发展历史，这极大地打断了我的阅读连贯性。比如，书中反复提到的某个特定厂商的集成模型，描述得过于冗长且缺乏对比性分析，让人很难判断其在通用架构中的优劣势。我更希望看到的是一种批判性的审视，比如在不同业务场景下，选择A方案与B方案的权衡利弊，而不是单纯地对某一种特定实现路径进行描绘。这本书给我的感觉，就像是听一位非常资深的专家在介绍他过去的项目经验，信息量很大，但缺乏针对性，对于试图快速掌握新技能的我来说，效率实在不高。它的叙事逻辑有时候跳跃得非常快，从一个宏大的愿景瞬间跳入到非常细微的技术参数讨论，中间的过渡环节处理得不够平滑，让人抓不住重点。
评分读了能有收获的一本书~~~
评分写毕业论文时看过。
评分比较清晰的谈了云计算和SOA的优势与缺点，不忽悠的一本书。
评分写毕业论文时看过。
评分读了能有收获的一本书~~~
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有