可伸縮架構：麵嚮增長應用的高可用 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小時不間斷運行的容錯、備份、負載均衡等技術是如何相互協作的。這本書的命名恰好擊中瞭我在架構設計中經常遇到的痛點，所以我迫不及待地想一探究竟。

評分☆☆☆☆☆

我一直對那些能夠“活下去”並且“活得很好”的應用係統充滿瞭敬意，它們就像是數字世界的生命體，能夠在復雜多變的環境中不斷適應和進化。這本書的標題《可伸縮架構：麵嚮增長應用的高可用》立刻吸引瞭我，它精準地捕捉到瞭現代軟件係統設計的兩大核心訴求：既要能夠容納不斷增長的業務體量，又要保證服務在任何時候都能穩定可用。我經常思考，是什麼樣的底層設計能夠支撐起那些我們習以為常的、無處不在的在綫服務？它們是如何在瞬間湧入的流量麵前泰然自若，又如何在突發的硬件故障或網絡中斷時迅速恢復？我期待這本書能為我揭示這些“幕後英雄”的設計奧秘。我猜想，書中會詳細探討如何通過解耦、水平擴展、數據分區等技術手段，構建一個能夠彈性伸縮的係統骨架，讓應用能夠從容應對從初期的小規模部署到未來海量用戶的平滑過渡。同時，關於“高可用”的部分，我也充滿瞭期待，希望能夠學習到如何通過多副本部署、負載均衡、自動故障檢測與恢復等策略，構建一個“不死”的係統，最大限度地減少服務中斷帶來的影響。這本書的齣現，對於我這樣在技術一綫摸爬滾打的開發者來說，無疑是雪中送炭。

評分☆☆☆☆☆

很不錯，贊(/≧▽≦/)

評分☆☆☆☆☆

可伸縮架構：麵嚮增長應用的高可用

評分☆☆☆☆☆

質量好，摺扣後很閤算

評分☆☆☆☆☆

速度超快！5分好評

評分☆☆☆☆☆

收收收收收心????

評分☆☆☆☆☆

架構師看看，理念思維方式的書籍。碼農嚮設計發展參考。

評分☆☆☆☆☆

速度超快！5分好評

評分☆☆☆☆☆

下次還要購買 不錯的書籍

評分☆☆☆☆☆

下次還要購買 不錯的書籍