发布！软件的设计与部署

内容简介：

本书分为四个部分，每部分内容都由一个研究案例引出。第一部分介绍了如何保证系统的生存，即维护系统正常运行。第二部分介绍了如何衡量系统的容量，以及如何随时间来优化系统的容量。在第三部分讲述了架构师在为数据中心构建软件时应该思考的一般设计问题。第四部分讨论了系统的运行寿命，将其作为整个信息生态环境的一部分。书中代码采用的Java语言，熟悉编程的人都能轻易阅读。作者从Java和Unix的视角看问题，因而本书的焦点比较中立，着眼于跨所有平台的技术和概念。在每种模式和反模式的末尾，都有一段简短精要的总结。

本书适合面向企业级软件的架构师、设计师和开发人员阅读参考。

作者简介：

Michael T.Nygard

从业二十余年的资深程序员、架构师，被誉为在线业务的“流动解决问题专家”。先后为美国政府、军队、银行、金融、农业和零售等多个行业交付过运营系统，这种实际运营的经历改变了他对软件架构和开发的看法，也让他对在相当不友好的环境下构建高性能、高可靠性的软件有了独特的见解。他写过多篇文章和社论，是软件架构经典著作《架构之美》作者之一。

目录：

第1章　引言1

1.1　瞄准正确的目标1

1.2　使用决断力2

1.3　生活的质量3

1.4　挑战的范围3

1.5　随手一松就是一百万3

1.6　务实的架构4

第一部分　稳定性

第2章　案例研究：航空系统宕机的异常8

2.1　事故9

2.2　结果12

2.3　事后调查12

2.4　确凿的证据15

2.5　一点预防17

第3章　稳定性概述19

3.1　定义稳定性20

3.2　故障模式22

3.3　裂痕扩散22

3.4　故障链23

3.5　模式与反模式24

第4章　稳定性反模式26

4.1　集成点27

4.2　连锁反应37

4.3　连锁故障40

4.4　用户42

4.5　阻塞的线程50

4.6　自我否定攻击55

4.7　尺度效应57

4.8　不平衡的容量60

4.9　慢响应63

4.10　SLA倒置64

4.11　无边界结果集67

第5章　稳定性模式70

5.1　使用超时70

5.2　断路器73

5.3　隔板75

5.4　稳定状态78

5.5　快速失效83

5.6　握手85

5.7　测试装置87

5.8　去耦合中间件90

第6章　稳定性总结93

第二部分　容量

第7章　案例研究：被客户压迫96

7.1　发布倒计时96

7.2　瞄准QA97

7.3　负载测试99

7.4　被大量会话所杀101

7.5　测试的鸿沟102

7.6　后果103

第8章　容量概述105

8.1　定义容量　105

8.2　约束106

8.3　关联107

8.4　可扩展性107

8.5　容量的神话108

8.6　总结114

第9章　容量反模式115

9.1　资源池竞争115

9.2　泛滥的JSP碎片118

9.3　AJAX过度之伤119

9.4　驻留过久的会话121

9.5　HTML中浪费的空间122

9.6　刷新按钮125

9.7　手工的SQL语句126

9.8　数据库富营养化128

9.9　集成点延迟130

9.10　Cookie怪兽131

9.11　总结133

第10章　容量模式134

10.1　连接池134

10.2　谨慎使用缓存136

10.3　预计算容量137

10.4　调整垃圾回收器140

10.5　总结142

第三部分　一般设计问题

第11章　网络连接144

11.1　多宿主服务器144

11.2　路由146

11.3　虚拟IP地址146

第12章　安全　149

12.1　最少特权原则149

12.2　配置的密码150

第13章　可用性151

13.1　收集可用性需求151

13.2　记录可用性需求152

13.3　负载均衡153

13.4　集群157

第14章　管理159

14.1　“测试和产品匹配吗？”159

14.2　配置文件161

14.3　启动和关闭163

14.4　管理接口164

第15　章　设计总结.　165

第四部分　运营

第16章　案例研究：惊人的宇宙168

16.1　旺季168

16.2　婴儿的第一个圣诞169

16.3　切脉169

16.4　感恩节170

16.5　黑色星期五170

16.6　重要的信号172

16.7　诊断测试172

16.8　专家打来电话　173

16.9　比较解救方案　174

16.10　条件是否会响应处理175

16.11　收尾176

第17章　透明度177

17.1　视角178

17.2　透明度设计184

17.3　使用各种技术　184

17.4　日志185

17.5　监控系统190

17.6　法律上及事实上的标准194

17.7　操作数据库201

17.8　支持流程205

17.9　总结208

第18章　适应209

18.1　与时俱进209

18.2　适应性的软件设计210

18.3　适应性的企业架构215

18.4　发布应无害220

18.5　总结224

参考书目226

文章试读：早期决策对系统的最终形态影响最大。最初的决策最难以更改。这些关于系统边界和子系统划分的早期决策，渗入到了团队结构、经费分配、程序管理结构甚至工时表中。团队分配是架构的第一稿（参见7.2节知识框）。极具讽刺意味的是，这些早期决策也是在信息获取最少的情况下做出的。这就是说，你的团队在这个时候对软件的最终结构最无知，但你必须要做出某些不可更改的决策。 即使是“敏捷”项目 ，也最好有远见地做出决策。为了...

(查看全部试读)