可伸縮架構：麵嚮增長應用的高可用 下載 mobi epub pdf 電子書 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] Lee，Atchison（李 艾奇遜） 著，張若飛 譯

齣版社： 電子工業齣版社

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章，雲上的

評分☆☆☆☆☆

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

評分☆☆☆☆☆

搞活動買書很劃算不，正版，不傷眼

評分☆☆☆☆☆

該不錯嘞該不錯嘞該不錯嘞該不錯嘞

評分☆☆☆☆☆

發貨挺快的…東西也很不錯…

評分☆☆☆☆☆

被壓成瞭s型瞭……

評分☆☆☆☆☆

好好好

評分☆☆☆☆☆

價格閤理，內容不錯?

評分☆☆☆☆☆

京東的商品，還是比較值得相信的.

評分☆☆☆☆☆

價格閤理，內容不錯?