可伸缩架构：面向增长应用的高可用 pdf epub mobi txt 电子书 下载 2025

简体网页||繁体网页

☆☆☆☆☆

[美] Lee，Atchison（李 艾奇逊） 著，张若飞 译

图书标签:

• 可伸缩性
• 高可用性
• 云原生
• 微服务
• 架构设计
• 分布式系统
• 容量规划
• 性能优化
• DevOps
• 软件架构

出版社： 电子工业出版社

ISBN：9787121316845

版次：1

商品编码：12103389

品牌：Broadview

包装：平装

开本：16开

出版时间：2017-06-01

用纸：胶版纸

页数：192

字数：263000

正文语种：中文

编辑推荐

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

　　每一天，许多公司都面临着如何去提升关键应用程序规模的问题。随着流量和数据需求的增加，这些应用程序变得越来越复杂和脆弱，从而导致风险上升、可用性降低。《可伸缩架构：面向增长应用的高可用》是一本实践指南，让IT、DevOps和系统稳定性管理员都能了解到，如何避免应用程序在发展过程中变得缓慢、数据不一致或者彻底不可用。

　　规模增长并不只意味着处理更多的用户，还包括管理更多的风险和保证系统的可用性。作者LeeAtchison在《可伸缩架构：面向增长应用的高可用》中提出了一些基本技巧，使得我们在构建各类应用程序的过程中，既能够保证产品的质量，又能够处理海量的流量、数据以及需求。

　　《可伸缩架构：面向增长应用的高可用》通过5个部分，分别介绍了以下内容。

　　√可用性：你将学习到如何创建高可用的应用程序，以及不断跟踪和提高可用性的技巧。

　　√风险管理：你将学习到如何确认、降低和管理应用程序中的风险，测试你的恢复、灾备方案，以及如何构建风险更低的系统。

　　√服务和微服务：你将理解服务对大规模运行复杂应用系统所带来的价值。

　　√扩展应用程序：你将学习到如何将服务分配给不同的团队，标识每个服务的关键程度，以及设计故障场景和恢复计划。

　　√云服务：理解基于云服务的架构、资源分配以及服务分布。

内容简介

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

作者简介

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

　　Lee 拥有28 年的行业工作背景，了解到如何搭建基于云的、可伸缩的系统架构。他领导并建立了公司*一个软件下载商店，搭建了AWS Elastic Beanstalk 服务

　　本书译者的中英文水平都极高，且工作在系统管理的一线，具有丰富的理论知识和实践经验，相信会为读者带来一本质量上乘的图书。

精彩书评

　　不要拿你的生意做赌注。规模化的发展是一个不可避免的趋势。本书会告诉你如何切实可行地做到这一点。

　　——ColinBodell

　　时代公司CTO；*网站应用平台副总裁（2006—2013）

　　本书会告诉你，如何在应用程序（以及公司）不断扩张以满足用户日益增长需求的同时，保证一切正常运转。

　　——LewCirne

　　NewRelic公司CEO

　　时刻考虑可能出现的故障情况，是构建大规模应用程序的一个关键因素。本书将帮助你学习如何做到这一点，以及如何在用户增长和公司发展过程中，依然保持应用程序正常运行的一些技巧。

　　——PatrickFranklin

　　Google工程副总裁

目录

目录

序． ．．．．．．．．．．．．．．．．．．．．．．．．．． 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
测试并跟踪当前的可用性 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 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
维护风险模型 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 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
如何定义服务 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 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

第Ⅳ部分　如何让应用程序具有伸缩性
第 14章　两次失误的高度．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 82
什么是“两次失误的高度” ．．．．．．．．．．．．．．．．．．．．．．．．．．．． 83
实践中的“两次失误的高度” ．．．．．．．．．．．．．．．．．．．．．．．． 83
丢失一个节点 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 83
升级过程中出现的问题 ．．．．．．．．．．．．．．．．．．．．．．．．．． 85
数据中心恢复 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 86
隐蔽的共享故障类型 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 88
管理你的应用程序 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 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 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 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

第 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

第 25章　AWS．Lambda．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 151
使用 Lambda ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 151
事件处理 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 151
手机应用后台 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 152
物联网数据采集 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 153
Lambda的优缺点．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 154

第Ⅵ部分　总结
第 26章　融会贯通．．．156
可用性 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 156
风险管理 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 157
服务 157
扩展 157
云服务 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 158
面向可伸缩的架构 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 158

索引． ．．．．．．．．．．．．．．．．．．．．． 159

精彩书摘

　　《可伸缩架构：面向增长应用的高可用》：
　　你在创建服务时可能会想问，究竟应该为服务定义多少个内部SLA？
　　首先，应当保证尽可能少的SLA数量。当SLA的数量增加时，SLA的意义和相互影响会变得非常复杂。
　　你应当确保SLA覆盖了服务的所有关键部分，为所有的主要功能都定义合适的SLA，尤其是对业务至关重要的地方。
　　你应当与服务的消费方一起来协商SLA，因为不能满足消费方需求的SLA就是—个无用的SLA。但是，尽量对所有的消费方都使用一样的SLA。服务应当尽可能用一套SLA来满足所有消费方的需求，因为为每个消费方都建立一组SLA，不仅会极大增加复杂性，也不会带来任何实际的价值。
　　你应当只定义那些实际中可以实现监控和报警的SLA。如果你无法有效地验证SLA，定义它也没有任何意义。此外，应当关心服务是否有违反SLA，因为这应该是问题发生的最先表现，因此你需要确保当服务不满足SLA时可以第一时间接收到相关报警。
　　你可以对超出SLA的值进行监控和报警，并将在它们之上的值作为内部的SLA。这些数据在查找和管理服务问题的时候非常有用，同时又不会实际承诺给消费方。
　　你应当建立一个包含所有SLA和监控的仪表盘界面，这样一眼就可以发现正在发生的问题。并且你应当将这个界面共享给所有的依赖方，这样他们也可以看到你的服务情况。
　　除此之外，你需要确保可以访问到所有依赖服务的仪表盘界面，这样你可以监控它们是否正在发生问题，以确定问题是否会影响到你的服务。
　　关于SLA的其他评价
　　监控和使用SLA会很快得到广泛应用，并且你可以很容易快速了解到SLA的各项监控细节。
　　理想情况下，我们的目标不只是建立对所有SLA的监控，而是发掘一个可以用来对比的数值。任何数字都好过没有数字。内部SLA的目的不是为了增加数字，而是为当前服务和其他依赖服务提供指导，帮助团队之间设置合理的期望。
　　……

前言/序言

　　序

　　我们生活在一个有趣的时代，可以称它是一个软件的寒武纪大爆炸。在这个过程中，构建新系统的成本呈数量级式下降，同时系统之间的关联程度也呈同等数量级的增长。借助于Amazon的AWS、微软的Azure和Google的GCP等资源，我们可以将系统在物理上扩展到一个几年前还只能想象的规模。

　　这些资源及其似乎无限的能力，正在以各种前所未见的方式，将新的思想、产品和市场极其快速地传播出去。但是，只有当我们构建的系统可以保持扩展的同时，所有这些探索才能成为可能。与以前相比，虽然构建小型系统变得容易很多，但是构建一个可以快速、可靠扩展的系统，并不像增加更多的硬件和存储空间那么容易，实际证明，这要难得多。

　　每个软件系统都会经历一个可预见的生命周期，从一个人能够完全理解的、小型的、设计精妙的解决方案，迅速增长为一个积累了大量技术债务的庞大系统，随后又逐渐分裂成由一些不完善的服务随机组成的组合，并最终演化成在广度（更多用户）和深度（更多功能）方面均可稳定扩展的、设计良好的分布式系统。对于这样的系统来说，我们很容易从外部了解要做哪些事情（让它变得更加可靠！），但又很难了解它内部的细节。幸运的是，本书是一本关于这方面不可或缺的指南，从可用性到服务层，从比赛日到风险模型，Lee一步步介绍了影响大规模系统的各个关键因素和实践方式。

　　Lee加入我们的时候，是NewRelic第一次从仅拥有一个产品正在向多个产品转型的时期，当时我们正沉浸在用户极速增长和公司成功的喜悦中。Lee的到来，为我们带来了他在Amazon的丰富经验，不管是零售业务还是AWS业务都曾经历过巨大的增长。Lee曾是这些团队的领头人，曾经积极参与过与可扩展性有关的所有事情，也遇到过很多失败。对我们来说，幸运的是，他已经经历过这些挫折与困苦，其中的教训可以让我们避免再犯同样的错误。

　　在Lee加入NewRelic之前，多年以来，我们一直经历着系统服务不可用的尴尬处境。我们原有的庞大系统也逐渐无法支持业务的发展，不管是可用性、可靠性还是性能都不是很好。但是，通过充分运用Lee在本书中所写的各项技巧，我们逐渐克服了这些困难，并构建了如今稳定可靠的企业级服务。其中我们使用的一个工具，建立了可用性工程的四个级别：青铜、白银、黄金和白金。要达到青铜级，团队必须拥有风险模型以及预定义的SLA标准。要达到白银级，团队必须能够监控风险模型中标识出来的问题，并使用比赛日的方式来解决。黄金级意味着风险已经被缓解掉了。白金级如同CMM5级一样，不仅系统可以自愈，而且我们关注持续性的改进。我们首先集中精力对第一级的服务进行改进，然后上升到第二级的服务，逐步推进，最终使得所有团队都至少达到了白银级，并且大多数团队通过了黄金级，甚至有几个团队达到了白金级。

　　后来我加入了InVisionApp这个更年轻的公司。我又一次经历着从早期成功向高速增长的过程，一直推动大家去使用Lee之前带给我的技术和工具。在这个新系统、新产品、新公司的爆炸年代，我强烈建议大家跟我做一样的事：向Lee学习如何构建可伸缩的系统。

　　——BjornFreeman-Benson博士，InVisionApp首席技术官

　　前言

　　当应用程序开始增长时，通常会出现两件事情：它们明显变得更加复杂（也更加脆弱），并且需要处理显著增加的流量（需要更先进、更复杂的管理机制）。这会让应用程序逐渐陷入一个死亡漩涡，用户会不断经历着限流、宕机以及其他服务质量和可用性方面的问题。

　　但是你的用户不会关心这些。他们只希望使用应用来做他们希望做的事情。如果你的应用程序宕机、响应缓慢或者信息不一致，用户会马上抛弃你，转而投靠能够帮助他们处理生意的竞争对手。

　　本书可教会你一些如何构建并管理大规模应用程序的基本技巧，帮助你避免陷入如上所述的死亡漩涡。一旦你掌握了这些技巧，你的系统就能够可靠处理海量的流量，从容面对流量中大量的不确定性，同时不会对用户期望造成任何影响。

　　本书的读者对象

　　本书的目标读者包括构建和管理大规模应用程序和系统的软件工程师、架构师、技术经理以及总监。如果你管理着软件开发人员、系统可靠性工程师、DevOps工程师，或者你经营着一个拥有大规模应用程序和系统的机构，本书中所提供的建议和指导都能够帮助你，让你的系统运行得更加平稳和可靠。

　　如果你的应用程序已经从很小的规模变得很大（并且正在经历着增长所带来的各种问题），你可能正在为系统的低可靠性和低可用性烦恼。如果你正在头疼如何管理技术债务以及相关的系统故障，本书恰好提供了这些方面的指导，能够帮助你通过降低技术债务，让应用程序更轻松地扩展到更大规模。

　　编写本书的原因

　　在Amazon零售和AWS业务多年从事构建高可伸缩应用程序之后，我加入了NewRelic这个正在迅速成长的公司。当时，NewRelic已经感受到了因为缺少管理高可伸缩应用程序的系统、流程所带来的痛苦，但是尚未完整形成能够扩大其应用程序规模的流程和规范。

　　在NewRelic，我亲眼目睹了一个公司在扩张规模过程中所经历的痛苦与挣扎，同时也意识到，还有很多其他公司每天都在经历着这些痛苦。

　　编写本书的初衷，是为了帮助那些正在面对其应用程序高速增长的人们，使其了解到一些有用的流程和最佳实践，避免他们再掉入规模扩张过程的各种陷阱之中。

　　无论你的应用程序每年增长十倍还是百分之十，也无论增长的是用户数量、交易数量、数据存储量还是代码复杂性，本书都可以在构建和维护应用程序方面为你提供帮助，让它们在保持高可用性的前提下实现增长。

　　现在我们所说的规模

　　基于云的服务正在以极快的速度增长和扩张。这主要归功于对云服务的大量需求，“软件即服务（SaaS）”逐渐成为应用程序开发的标准。由于SaaS应用程序天生多租户的特点，它们对于规模上的问题尤其敏感。

　　随着世界的改变，以及我们对SaaS服务、云服务、海量应用程序越来越多的关注，规模性问题也变得越来越重要。似乎我们看不到，云应用程序在体积和复杂性方面会出现增长到头的情况。

　　关键的机制在于，我们当前用来管理大规模系统的前沿科技，很可能会成为明天的基础工具，而明天我们可能遇到的规模问题，也会让当前的解决方案相形见绌。我们需要越来越复杂的系统和架构，来处理将来可能无限增长的规模。

　　本书的目的，就是为了提供可以禁得起时间考验的知识。

　　本书导读

　　管理规模并不只是管理流量，还包括管理风险和可用性。通常来说，所有这些东西都是描述相同问题的不同方式，并且它们息息相关。因此，为了能够合理地讨论规模问题，我们还必须考虑到可用性、风险管理以及像微服务和云服务这样的现代架构模型。因此，本书按照如下章节来划分内容。

　　第Ⅰ部分：可用性

　　当某个应用程序开始扩张规模时，可用性和可用性管理通常是最先受到影响的部分。

　　第1章，什么是可用性为了更好地让读者理解，我们会讲解一下高可用性的意义，以及它与可靠性之间的区别。

　　第2章，提高应用程序可用性的五个要点

　　在本章中，我针对如何提高应用程序的可用性提出了五个核心方向。

　　第3章，测量可用性

　　本章会介绍一种测量可用性的标准算法，并进一步讲解高可用性的作用和价值。

　　第4章，提高下降的可用性如果你的应用程序正遇到可用性的问题（或者你想知道这是否正在发生），我们提供了一些管理手段，来帮助你提高应用程序的可用性。

　　第Ⅱ部分：风险管理

　　理解系统中的风险，对于提高应用程序的可用性，以及它后续向更大规模发展的能力是至关重要的。

　　第5章，什么是风险管理

　　本章会通过介绍风险管理的基本知识，引出如何管理高可伸缩应用程序的话题。

　　第6章，可能性与严重性本章会讨论风险发生时的严重性与可能性之间的区别。它们都非常重要，但是方式不同。

　　第7章，风险模型

　　在本章中，我会以一个精心设计的系统为例，来帮助你理解和管理系统中的风险。

　　第8章，风险缓和

　　本章会讨论如何处理系统中已知的风险，并减少它们对应用程序的影响。

　　第9章，比赛日本章会介绍如何对风险管理计划、风险缓和计划以及容灾计划进行持续的测试和评估。本章回顾了在生产环境实现比赛日所需的技术，以及它所带来的好处。

　　第10章，构建低风险系统

　　在本章中，我会给出如何降低应用程序中的风险，以及如何构建低风险系统的建议。

　　第Ⅲ部分：服务和微服务

　　服务和微服务都是一种架构方案，用于构建需要更大规模运行的、更加大型且复杂的应用程序。

　　第11章，为什么使用服务

　　本章会介绍为什么服务对于构建高度可扩展的应用程序如此重要。

　　第12章，使用微服务

　　在本章中，我会介绍如何创建基于微服务的架构，主要关注于如何对服务大小进行合理分割，确定服务的边界，以便提高可扩展性和可用性。

　　第13章，处理服务故障

　　在本部分的最后一章中，我们会来讨论如何构建能够处理故障的服务。

　　第Ⅳ部分：如何让应用程序具有伸缩性

　　“伸缩”其实不仅仅与流量有关，它关系你的组织，以及你的组织如何来响应更大的应用程序需求。

　　第14章，两次失误的高度

　　本章会介绍如何在出现故障的情况下，依然能够通过伸缩系统来保持高可用性。

　　第15章，服务所有权

　　本章会讲解，关注服务的所有权，能如何帮助你扩展组织和应用程序。

　　第16章，服务分级

　　本章会介绍如何区分各个服务的关键程度，从而帮助管理对服务的期望。

　　第17章，使用服务分级

　　当制订服务分级制度之后，我们会介绍如何通过它来管理服务故障的影响、响应性需求以及期望管理。

　　第18章，服务等级协议

　　在本章中，我们会讨论如何使用SLA来管理服务所有者之间的相互依赖。

　　第19章，持续改进

　　本章会就如何改进应用程序整体的可扩展性，提供相应的技术和指导。

　　第Ⅴ部分：云服务

　　对于构建和管理需要极强可伸缩能力的大型、关键性系统来说，基于云的服务正在变得日益重要。

　　第20章，变化和云服务本章介绍了云服务对构建高度可伸缩的Web应用程序所带来的改变。

　　第21章，云上的

拥抱动态，构建永恒：面向爆炸性增长的可伸缩性之道 在数字浪潮席卷一切的今天，一个成功的应用不再仅仅是功能的堆砌，它更是承载用户期望、驱动业务增长的生命体。然而，当用户量以惊人的速度激增，当业务场景变得日益复杂，当对稳定性的要求提升到前所未有的高度，你是否曾感到一丝无力？你精心打造的应用，是否在流量洪峰下濒临崩溃，让你焦头烂额？你是否曾因为一次突如其来的故障，而错失了宝贵的增长机遇，甚至损害了品牌声誉？ 如果答案是肯定的，那么，你对“可伸缩性”的追求，将不再是一种选择，而是一种必然。它关乎着你的应用能否在风云变幻的市场中立于不败之地，关乎着你的业务能否抓住稍纵即逝的增长机遇，更关乎着你为用户提供的持续、稳定、可靠的体验。 本书，将带你踏上一段深入探索“可伸缩性”本质的旅程。我们不只是浅尝辄止地介绍几个技术名词，而是要从根本上理解为何可伸缩性如此重要，它将如何影响你的设计决策，又将如何贯穿于应用的整个生命周期。我们将深入剖析那些在海量用户面前依然游刃有余的系统，它们究竟蕴含着怎样的设计智慧和工程实践。 核心洞察：从“静态”到“动态”的思维跃迁 本书的核心，在于引导你完成一次从“静态固定”到“动态适应”的思维转变。过去，我们可能习惯于预估一个大致的用户规模，然后根据这个数字来规划服务器数量和资源配置。然而，在瞬息万变的互联网时代，这种“一次性”的规划早已显得捉襟见肘。爆炸性增长并非遥不可及，它可能在一夜之间降临，也可能以一种你未曾预料的方式悄然而至。 因此，我们需要一种能够“动态响应”的设计哲学。这意味着，你的应用需要具备自我调整、自我扩展的能力，能够根据当前的负载情况，自动地增减资源，保持最佳的运行状态。这种动态性，是应对不确定性，拥抱增长的基石。 构建坚实的地基：可伸缩性的核心原则 在深入探讨具体的技术实现之前，理解并掌握可伸缩性的核心原则至关重要。本书将为你详细阐述以下几个关键原则： 解耦（Decoupling）： 将复杂的系统拆解成独立的、可独立部署和扩展的组件。这不仅能降低整体系统的耦合度，提高灵活性，更能让各个组件根据自身的需求进行独立的伸缩。想象一下，如果你有一个庞大的单体应用，当某个部分负载过高时，你不得不整体扩展整个应用，这样既浪费资源，又效率低下。而通过解耦，你可以只扩展那个高负载的组件，实现资源的精细化利用。 无状态（Statelessness）： 尽量让你的服务组件保持无状态，即将用户会话信息或其他状态信息存储在外部的、独立的存储系统中。这样，任何一个服务实例都可以处理任何一个用户请求，当某个实例出现故障时，其他实例可以无缝接管，而不会丢失用户数据。无状态是实现水平伸缩的关键，它极大地简化了负载均衡和故障转移的复杂度。 异步处理（Asynchronous Processing）： 将耗时、阻塞性的操作放到后台异步执行，而不是让用户等待。这能够显著提高系统的吞吐量和响应速度，让用户感受到应用的流畅与高效。例如，用户提交订单后，无需等待所有库存检查和支付验证完成，而是可以立即收到订单确认，后台则可以异步地进行后续处理。 数据分片与复制（Data Sharding and Replication）： 当数据量过大，单个数据库无法满足读写需求时，需要采用数据分片的技术将数据分散到多个数据库实例中。同时，通过数据复制，可以在多个实例上保持数据的冗余，提高数据的可用性和读取性能。这就像将一个巨大的图书馆拆分成多个小型图书馆，并为每个图书馆准备多份副本，以应对大量的读者借阅需求。 缓存（Caching）： 利用缓存来存储频繁访问的数据，从而减少对后端数据库或服务的直接访问，提高响应速度。缓存策略的选择与实现，是提升系统性能的关键一环。从内存缓存到分布式缓存，本书将为你解析不同场景下的缓存应用。 伸缩之道：从垂直到水平的进化 本书将详细探讨两种主要的伸缩方式： 垂直伸缩（Vertical Scaling）： 通过增加单个服务器的硬件资源（如CPU、内存、硬盘）来提升性能。这种方式简单直接，但存在硬件成本高昂、存在单点故障以及扩展上限的限制。 水平伸缩（Horizontal Scaling）： 通过增加更多的服务器实例来分担负载。这是现代高可用、高伸缩性系统的基石。本书将重点关注水平伸缩的各种实现方式和最佳实践。 技术架构的实践：从基础设施到应用层 可伸缩性并非仅仅是一个抽象的概念，它需要融入到技术架构的每一个层面。本书将从以下几个维度深入剖析： 负载均衡（Load Balancing）： 如何将请求智能地分配到不同的服务器实例上，确保资源的均匀利用和系统的稳定性。我们将探讨不同类型的负载均衡器（硬件、软件、DNS），以及它们在不同场景下的应用。 服务发现（Service Discovery）： 在微服务架构中，服务实例的数量和位置是动态变化的。服务发现机制能够让服务之间找到彼此，确保通信的顺畅。 容器化与编排（Containerization and Orchestration）： Docker、Kubernetes等技术的兴起，为实现快速部署、弹性伸缩和自动化管理提供了强大的支撑。本书将深入探讨这些技术如何赋能可伸缩性。 数据库的可伸缩性： 从关系型数据库的分片、复制，到NoSQL数据库的分布式特性，我们将剖析不同数据库在应对海量数据时的伸缩策略。 消息队列（Message Queues）： 利用消息队列作为异步通信的桥梁，能够削峰填谷，解耦生产者和消费者，极大地提升系统的稳定性和可伸缩性。 CDN（Content Delivery Network）： 对于静态资源的交付，CDN能够将内容缓存到离用户最近的节点，显著降低源服务器的压力，提升用户访问速度。 设计模式与最佳实践：赋能可持续增长 除了技术细节，本书还将为你提炼出在设计和构建可伸缩应用过程中的关键设计模式和最佳实践： 幂等性（Idempotency）： 如何设计操作，使其能够被重复执行而不会产生副作用，这对于处理分布式系统中的重试机制至关重要。 限流（Rate Limiting）： 如何有效控制请求的速率，防止恶意攻击或突发流量击垮系统。 熔断与降级（Circuit Breakers and Degradation）： 当某个服务出现故障时，如何通过熔断机制阻止请求进一步扩散，并提供降级服务，保证核心功能的可用性。 灰度发布（Canary Releases）与蓝绿部署（Blue-Green Deployments）： 如何安全地部署新版本，逐步将流量切换到新版本，最大限度地降低发布风险。 自动化监控与告警（Automated Monitoring and Alerting）： 建立完善的监控体系，能够实时感知系统的运行状态，并在出现异常时及时发出告警，为快速响应提供依据。 超越技术：文化与流程的支撑 可伸缩性的成功，不仅仅是技术的问题，更是组织文化和工程流程的支撑。本书还将探讨： DevOps文化： 开发与运维的紧密协作，自动化部署、测试和监控，是实现快速迭代和弹性伸缩的重要保障。 持续集成与持续部署（CI/CD）： 自动化构建、测试和部署流程，能够加速应用的交付和迭代，为伸缩性提供敏捷的支持。 性能测试与容量规划（Performance Testing and Capacity Planning）： 定期进行性能测试，了解系统的瓶颈，并基于数据进行合理的容量规划，为应对增长做好准备。 面向未来：持续演进的伸缩性 数字世界永不停止变化，技术的边界也在不断拓展。本书将为你展望未来，探讨Serverless、边缘计算等新兴技术将如何进一步重塑我们对可伸缩性的理解和实践。 阅读本书，你将获得一套系统性的知识体系，掌握构建高可用、可伸缩应用的思维方式和实践方法。你将能够： 自信地应对海量用户增长， 抓住稍纵即逝的商业机遇。 构建稳定可靠的应用， 赢得用户的信任和口碑。 优化资源利用， 降低运营成本，提升效率。 拥抱技术变革， 保持在行业竞争中的领先地位。 无论是初创公司的技术负责人，还是大型互联网企业的架构师，亦或是渴望提升应用健壮性的开发者，本书都将是你不可或缺的指南。让我们一起，从现在开始，构建面向增长的、永恒的应用。

评分☆☆☆☆☆

这本书的封面设计非常吸引我，那种抽象的、线条交织的图案，隐约透露着一种动态和无限延伸的感觉，让我对接下来的内容充满了好奇。我一直对如何构建能够应对未来不确定性、持续发展的应用程序非常感兴趣，尤其是在当今快速变化的互联网环境中，系统的稳定性和弹性变得前所未有的重要。我常常在想，那些能够支撑海量用户、处理爆炸式增长数据的平台，背后究竟有着怎样的设计哲学？它们是如何做到在用户量激增时依然能提供流畅体验，在突发状况下也能保持服务的连续性？我希望这本书能提供一些具体的、可落地的思路和方法，而不仅仅是停留在理论层面。我期待能从中学习到一些前沿的技术实践，了解当前业界在可伸缩架构方面的主流解决方案，以及它们各自的优缺点。尤其是在“面向增长”这个关键词上，我希望作者能够深入剖析如何设计出能够随着业务需求灵活扩展、成本效益最大化的架构，而不是为了伸缩而伸缩，导致资源的浪费。同时，我对“高可用”的实现机制也充满兴趣，想了解那些保障系统7x24小时不间断运行的容错、备份、负载均衡等技术是如何相互协作的。这本书的命名恰好击中了我在架构设计中经常遇到的痛点，所以我迫不及待地想一探究竟。

评分☆☆☆☆☆

我对这本书的期待，更多地源于它所揭示的“增长”与“稳定”之间的辩证关系。在如今这个互联网蓬勃发展的时代，几乎所有的应用都在追求用户量的增长和业务的扩展，而随之而来的挑战是如何保证系统在高负荷下的可用性和稳定性。我经常在想，那些成功的互联网巨头，它们的系统究竟是如何做到在指数级增长的用户和数据面前依然能够保持高效运转的？《可伸缩架构：面向增长应用的高可用》这个书名，恰恰点出了解决这个问题的关键所在。我希望这本书能够提供一套清晰的、可实践的指南，帮助我理解如何设计能够“生长”的架构。这可能涉及到如何进行细粒度的服务拆分，如何实现数据的分布式存储和管理，如何利用消息队列和缓存来优化性能和解耦，以及如何设计出能够自动伸缩的计算资源。同时，对于“高可用”这个概念，我期待书中能够深入探讨各种容错机制、备份策略、负载均衡技术，以及如何通过全方位的监控和告警体系来保障服务的连续性。总而言之，我希望这本书能够成为我理解和构建健壮、可伸缩的现代应用架构的宝贵参考。

评分☆☆☆☆☆

初拿到这本书，我最直观的感受是它传达出的专业性和深度。从书名来看，它似乎直指当前软件开发领域最核心的几个挑战：如何让系统能够灵活适应不断增长的用户需求，同时又要确保其稳定可靠，不至于在关键时刻掉链子。我脑海里立刻浮现出那些曾经让我头疼的系统性能瓶颈，以及在维护升级过程中面临的各种风险。我设想这本书会为我提供一套系统性的解决方案，帮助我理解在设计和构建复杂分布式系统时，需要考虑的关键要素。我希望作者能够从宏观层面阐述可伸缩架构的设计原则，比如模块化、无状态化、异步通信等，然后逐步深入到具体的实现细节，例如数据库的分片、缓存策略、消息队列的应用，以及如何利用容器化技术和云原生服务来实现弹性和自动化伸缩。对于“高可用”方面，我期待看到关于故障转移、灾难恢复、负载均衡策略等方面的详细介绍，以及如何通过冗余设计和自动化监控来提升系统的健壮性。我尤其想知道，在不同的业务场景下，应该如何选择和组合这些技术，才能达到最佳的伸缩性和可用性效果。这本书的出现，对我来说，可能意味着一次系统性的知识梳理和能力提升。

评分☆☆☆☆☆

我一直对那些能够“活下去”并且“活得很好”的应用系统充满了敬意，它们就像是数字世界的生命体，能够在复杂多变的环境中不断适应和进化。这本书的标题《可伸缩架构：面向增长应用的高可用》立刻吸引了我，它精准地捕捉到了现代软件系统设计的两大核心诉求：既要能够容纳不断增长的业务体量，又要保证服务在任何时候都能稳定可用。我经常思考，是什么样的底层设计能够支撑起那些我们习以为常的、无处不在的在线服务？它们是如何在瞬间涌入的流量面前泰然自若，又如何在突发的硬件故障或网络中断时迅速恢复？我期待这本书能为我揭示这些“幕后英雄”的设计奥秘。我猜想，书中会详细探讨如何通过解耦、水平扩展、数据分区等技术手段，构建一个能够弹性伸缩的系统骨架，让应用能够从容应对从初期的小规模部署到未来海量用户的平滑过渡。同时，关于“高可用”的部分，我也充满了期待，希望能够学习到如何通过多副本部署、负载均衡、自动故障检测与恢复等策略，构建一个“不死”的系统，最大限度地减少服务中断带来的影响。这本书的出现，对于我这样在技术一线摸爬滚打的开发者来说，无疑是雪中送炭。

评分☆☆☆☆☆

我之所以对这本书如此感兴趣，是因为它触及了我作为一名开发者在实际工作中经常遇到的核心问题。在快速变化的业务需求和不断增长的用户基数面前，如何设计出既能满足当下发展，又能应对未来挑战的系统，一直是我的思考重点。《可伸缩架构：面向增长应用的高可用》这个书名，恰好精准地概括了这个问题。《可伸缩》意味着系统能够随着业务量的增加而灵活扩展，而《面向增长》则强调了这种扩展是为了支撑业务的持续发展。《高可用》则进一步强调了系统在任何时候都应该保持稳定运行，不因为故障而影响用户体验。我期望这本书能提供一套系统性的方法论，帮助我理解在架构设计中，需要重点关注哪些方面，才能实现这些目标。我希望书中能深入阐述各种可伸缩的技术模式，例如微服务架构、无服务器计算、数据分片和分布式数据库等，以及它们在实际应用中的落地经验。同时，对于“高可用”的实现，我期待能学习到关于故障隔离、冗余设计、容错机制、负载均衡策略以及自动化运维等方面的详细介绍。这本书的出现，对我而言，可能意味着解决我长期以来在系统设计方面所面临的一些困惑。

评分☆☆☆☆☆

非常不错的一本书，推荐购买

评分☆☆☆☆☆

看目录不错，但是没什么实质的内容，很一般

评分☆☆☆☆☆

架构师必备

评分☆☆☆☆☆

书很薄，内容还可以，重点讲的思路，有些借鉴，价格应该再便宜一点。

评分☆☆☆☆☆

刚买回来没多久，还没来得及看，书还是不错的

评分☆☆☆☆☆

一直在京东买，省时省力省心

评分☆☆☆☆☆

好好好

评分☆☆☆☆☆

还不错，准备看

评分☆☆☆☆☆

质量好，折扣后很合算