可伸缩架构

出版者:电子工业出版社

作者:【美】Lee Atchison

出品人:博文视点

页数:192

译者:张若飞

出版时间:2017-7

价格:65

装帧:平装

isbn号码:9787121316845

具体描述

随着互联网的发展越来越成熟，流量和数据量飞速增长，许多公司的关键应用程序都面临着伸缩性的问题，系统变得越来越复杂和脆弱，从而导致风险上升、可用性降低。《可伸缩架构：面向增长应用的高可用》是一本实践指南，让IT、DevOps和系统稳定性管理员能够了解到，如何避免应用程序在发展过程中变得缓慢、数据不一致或者彻底不可用等问题。规模增长并不只意味着处理更多的用户，还包括管理更多的风险和保证系统的可用性。作者Lee Atchison 在可用性、风险管理、服务和微服务、扩展应用程序和云服务方面提出了一些技巧，使得我们在构建各类应用程序时，既能够保证产品的质量，又能够处理海量的流量、数据以及需求。

如果你管理着软件开发人员、系统可靠性工程师、DevOps工程师，或者你经营着一个拥有大规模应用程序和系统的机构，《可伸缩架构：面向增长应用的高可用》中所提供的建议和指导都能够帮助你，让你的系统运行得更加平稳和可靠。

作者简介

Lee Atchison 是New Relic 公司的首席云架构师和布道师。他已经在New Relic 工作了4年，负责设计并领导建立了New Relic 的基础设施产品，帮助New Relic 搭建了健壮的服务化系统架构，支撑起公司从一个很小的SaaS 创业公司成长为一个高流量的公众企业。他非常擅长构建高可用的系统。

Lee 拥有28 年的行业工作背景，之前在Amazon.com 担任了7 年高级经理，了解到如何搭建基于云的、可伸缩的系统架构。在Amazon，他领导并建立了公司第一个软件下载商店，搭建了AWS Elastic Beanstalk 服务，并带领团队将Amazon 的零售平台从一个单体架构成功迁移到了基于服务的架构。

目录信息

序 xv
前言 xvii
第Ⅰ部分可用性
第 1章　什么是可用性 2
可用性与可靠性 3
什么导致了低可用性 4
第 2章　提高应用程序可用性的五个要点 6
要点 1：时刻考虑应对故障 7
要点 2：时刻考虑如何伸缩 8
要点 3：缓和风险 9
要点 4：监控可用性 10
要点 5：以预测和确定的方式来应对可用性问题 11
做好准备 12
第 3章　测量可用性 13
N个 9 14
-- 什么样的可用性是合理的 14
不要上当 14
通过数字来体现可用性 15
第4 章　提高下降的可用性 16
测试并跟踪当前的可用性 17
将手动流程自动化 17
-- 自动化部署 18
-- 配置管理 18
-- 更改实验和高频次更改 19
-- 自动化的变更完备性测试 20
改进你的系统 20
不断变化和发展中的应用程序 20
时刻关注可用性 21
第Ⅱ部分 风险管理
第 5章　什么是风险管理. 24
管理风险 25
识别风险 25
消除最严重的风险 26
风险缓和 26
定期检查 27
对风险管理的总结 27
第 6章　可能性与严重性. 28
10佳列表：低可能性，低严重性 29
订单数据库：低可能性，高严重性 29
自定义字体：高可能性，低严重性 30
T恤图片：高可能性，高严重性 31
第 7章　风险模型 32
风险模型的作用域 34
创建风险模型 34
-- 通过头脑风暴建立风险列表 35
-- 填写可能性和严重性字段 36
-- 风险项详情 37
-- 缓和计划 37
-- 触发计划 37
使用风险模型来制订计划 37
维护风险模型 38
第 8章　风险缓和 40
恢复计划 41
容灾计划 42
改进我们的风险状况 43
第 9章　比赛日 44
预发布环境和生产环境. 44
在生产环境中举行比赛日的担心 46
比赛日测试 47
第 10章　构建低风险系统 48
冗余 48
幂等接口示例 49
增加了复杂性的冗余改进 49
独立性 50
安全 51
简单性 51
自修复 52
运维流程 53
第Ⅲ部分　服务和微服务
第 11章　为什么使用服务. 56
单体应用程序 56
基于服务的应用程序 57
所有权收益 58
规模收益 60
第12 章　使用微服务 62
如何定义服务 63
-- 深入了解服务 63
-- 指导原则 1：特定的业务需求 63
-- 指导原则 2：清晰和独立的团队所有权 64
-- 指导原则 3：天然隔离的数据 65
-- 指导原则 4：共享的能力 /数据 67
-- 多种原因 67
过犹不及 68
适当的平衡 69
第 13章　处理服务故障 70
级联式的服务故障 70
如何响应服务故障 71
-- 可预测的响应 72
-- 可理解的响应 73
-- 合理的响应 73
如何确定故障 74
适当的行为 76
-- 优雅降级 76
-- 优雅补偿 77
-- 尽早失败 77
-- 用户导致的问题 78
第4部分 如何让应用程序具有伸缩性
第 14章　两次失误的高度 82
什么是“两次失误的高度” 83
实践中的“两次失误的高度” 83
-- 丢失一个节点 83
-- 升级过程中出现的问题 85
-- 数据中心恢复 86
-- 隐蔽的共享故障类型 88
-- 故障循环 89
管理你的应用程序 90
航天飞机 90
第 15章　服务所有权 92
由独立团队负责的服务架构 92
STOSA应用程序和组织的好处 94
成为一个服务所有者意味着什么 94
第 16章　服务分级. 97
应用复杂性 97
什么是服务分级 98
为服务分配服务级别标签 99
-- 1级服务 99
-- 2级服务 99
-- 3级服务 100
-- 4级服务 100
示例：在线商店 100
接下来呢 103
第 17章　使用服务分级. 104
期望 104
响应性 104
依赖 106
-- 关键依赖 106
-- 非关键依赖. 107
小结 107
第 18章　服务等级协议. 108
什么是服务等级协议 108
外部 SLA与内部 SLA的对比 110
为什么内部 SLA很重要 110
SLA可以作为一种信任的手段 111
SLA可以用于问题诊断 111
SLA 的性能检测方法 112
-- 限定 SLA 113
-- 排名 SLA 113
-- 延迟分组 115
究竟应当定义多少内部 SLA，以及定义哪些内部 SLA 116
关于 SLA的其他评价 116
第Ⅴ部分　云服务
第 19章　持续改进. 117
定期检查你的应用程序 117
微服务 118
服务所有权 118
无状态服务 118
数据在哪里 118
数据分区 119
持续改进的重要性 121
第 20章　变化和云服务.124
云服务有哪些变化 124
-- 对基于微服务架构的认可 124
-- 更小、更专业的服务 125
-- 更专注于应用程序 125
-- 微型初创公司 125
-- 安全和合规已经成熟 125
变化还在继续 125
第 21章　云上的分布.127
AWS的架构 127
-- AWS区域 127
-- AWS可用区 128
-- 数据中心 128
总体架构概述 129
可用区不是数据中心 131
如何通过地理多样性真正做到高可用 133
第 22章　托管的基础设施. 134
基于云的服务架构 134
-- 原生资源 135
-- 托管资源（基于服务器） 136
-- 托管资源（不基于服务器） 137
使用托管资源的影响 138
使用非托管资源的影响 138
监控和 CloudWatch 138
第 23章　云资源分配. 140
固定额度的资源分配 140
-- 调整分配 141
-- 预留容量 142
基于使用量的资源分配 143
-- 基于使用量分配资源的好处 144
资源分配技术的利与弊 145
第 24章　可伸缩的计算选项. 146
云服务器 147
-- 优点 147
-- 缺点 147
-- 适用场景 147
计算分片 147
-- 优点 147
-- 缺点 148
-- 适用场景 148
动态容器 148
-- 优点 148
-- 缺点 149
-- 适用场景 149
微计算 149
-- 优点 149
-- 缺点 150
-- 适用场景 149
如何选择 150
第 25章　AWS.Lambda. 151
使用 Lambda 151
-- 事件处理 151
-- 手机应用后台 152
-- 物联网数据采集 153
Lambda的优缺点 154
第Ⅵ部分　总结
第 26章　融会贯通156
可用性 156
风险管理 157
服务 157
扩展 157
云服务 158
面向可伸缩的架构 158
索引 159
· · · · · · (收起)

读后感

Every day, companies struggle to scale critical applications. As traffic volume and data demands increase, these applications become more complicated and brittle, exposing risks and compromising availability. This practical guide shows IT, devops, and syste...

Every day, companies struggle to scale critical applications. As traffic volume and data demands increase, these applications become more complicated and brittle, exposing risks and compromising availability. This practical guide shows IT, devops, and syste...

Every day, companies struggle to scale critical applications. As traffic volume and data demands increase, these applications become more complicated and brittle, exposing risks and compromising availability. This practical guide shows IT, devops, and syste...

Every day, companies struggle to scale critical applications. As traffic volume and data demands increase, these applications become more complicated and brittle, exposing risks and compromising availability. This practical guide shows IT, devops, and syste...

Every day, companies struggle to scale critical applications. As traffic volume and data demands increase, these applications become more complicated and brittle, exposing risks and compromising availability. This practical guide shows IT, devops, and syste...

用户评价

这本书的结构安排简直是教科书级别的典范。它没有采用那种平铺直叙的线性叙事，而是巧妙地设置了几个关键的“转折点”。第一个转折是关于“状态管理”的深入探讨，作者用一系列生动的比喻，比如“流动的河床”与“固定的基石”，清晰地区分了有状态服务与无状态服务的适用场景，并详细推演了在微服务环境下，如何优雅地处理分布式事务的一致性问题。更让我眼前一亮的是，作者对“数据流动”的描述，那种对数据管道的精妙设计，简直如同欣赏一场复杂的交响乐。他并没有推荐某一种特定的技术栈，而是着重于“原理”的提炼，比如幂等性、最终一致性、以及如何构建有效的补偿机制。这种高屋建瓴的讲解方式，让读者能够穿透具体框架的限制，真正掌握底层逻辑。我甚至在思考，我过去在项目中遇到的很多性能瓶颈和死锁问题，或许都可以从这些基础原理的理解偏差中找到根源。这本书迫使你停下来，审视自己过去的代码，重新定义你对“健壮性”的理解。

从排版和术语处理的角度来看，这本书也体现了极高的专业水准。通常技术书籍的图表往往是模糊不清的或者难以理解的，但这本书中的流程图和组件关系图都经过了精心的优化，线条清晰，标识明确。作者在引入新的概念时，总是先给出其背后的业务驱动力，避免了纯粹的技术术语堆砌，这极大地降低了跨领域沟通的难度。例如，在讨论“可观测性”时，他没有直接跳到Traces、Metrics、Logs的定义，而是先从“当系统出现问题时，我们如何知道问题出在哪里”这个最基本的人类需求出发，自然而然地导出了日志、指标和链路追踪的必要性。这种“需求驱动设计”的叙事风格贯穿始终，让读者在吸收知识的同时，也潜移默化地学习了如何有效地向非技术人员解释复杂的系统设计思路。读完此书，我不仅在技术层面获得了提升，更重要的是，在如何构建一个能够持续应对未来挑战的系统思维框架上，收获了宝贵的财富。

这本书最让我感到震撼的地方，在于它对“演进式架构”的深刻洞察。很多同类书籍倾向于描绘一个“理想化的终态”，仿佛架构一旦建成便一劳永逸。但作者非常务实地指出，任何架构都是在特定历史时空下的最优解，且必然会被未来的需求所颠覆。因此，核心不在于找到“完美”的架构，而在于构建一个“易于变更”的架构。他详细阐述了如何通过领域驱动设计（DDD）来解耦边界，确保在一个子系统发生剧变时，不会引发整个系统的连锁反应。特别是他对“架构师的决策树”的描绘，将一系列技术选择（如同步/异步通信、数据库选型、数据冗余策略）置于一个动态决策矩阵中进行权衡，这对于那些经常需要在“快”与“好”之间挣扎的团队来说，简直是及时雨。这本书不是让你学会固守某种教条，而是教你如何在不确定性中，持续做出最理性的、可逆的、低成本的改变。

这本书的封面设计得非常简洁有力，黑底白字的标题在书脊上格外醒目，给人一种专业而深邃的第一印象。我本来对“架构”这个词汇抱有一定的敬畏感，总觉得它是技术圈子里高深莫测的领域，充满了晦涩难懂的术语和复杂的流程图。然而，翻开第一页，作者那种娓娓道来的叙述方式立刻消除了我的顾虑。他似乎拥有将最复杂的概念用最日常的语言解释清楚的天赋。书中没有那种堆砌概念的倾向，而是从构建一个“稳定、可靠”系统的核心目标出发，层层递进地剖析了不同设计范式背后的权衡与取舍。尤其令我印象深刻的是，作者花了相当大的篇幅去探讨“人”在架构决策中的作用——如何与团队沟通变更、如何平衡业务的短期需求与长期的技术债务。这种对实践经验的重视，让这本书远超一本单纯的技术手册，更像是一部融合了工程哲学与项目管理的经验之谈。读完前几章，我感觉自己对软件系统的生命周期有了一个全新的、更具全局观的认识，仿佛站在了一座精心规划的城市模型前，不再是只见树木不见森林的初级工程师了。

我必须承认，阅读这本书的过程并非一帆风顺，它确实对读者的心智提出了挑战，但这种挑战带来的充实感是无与伦比的。作者在描述“弹性”这一主题时，引入了物理学中的“应力与形变”概念，将系统在面对流量洪峰时的表现比作材料的断裂点。他并未满足于介绍熔断器和限流器这类常见的工具，而是深入探讨了如何设计一个能够自我修复、具备“韧性”的系统。书中有一段关于“灰度发布”的案例分析，简直是神来之笔。它将原本看似琐碎的部署流程，提升到了一个关于风险控制和信息反馈的战略层面。我以前总是觉得部署就是运维的事，但读完后才明白，一个好的架构师必须将发布的风险内置于设计之初。这本书的阅读体验更像是与一位经验极其丰富的导师进行深度对话，他既能谈笑间指出你思维中的漏洞，又能为你提供一套经过无数次实战检验的思考框架。读完后，我感到我的技术视野被极大地拓宽了，不再局限于写出能运行的代码，而是开始思考如何写出能“抵抗失败”的代码。

虽然书比较薄，但是对于构建高可用应用的因素都囊括了，翻译的也很好

把各种可扩展性架构基础设施提了一遍，有一半是管理手段，比如风险管理、SLA、微服务团队建设，技术方面与微服务的基础架构高度重合。

EC2和微服务果然是一对好基友

概念都太简单，真的只是原则而已。

半天功夫翻阅完毕，这本书最有价值的点在于一开始提出的风险评估模型。