《發布！設計與部署穩定的分散式系統（第2版）》是2020年1月人民郵電出版社出版的圖書，作者是[美]麥可·尼加德（Michael T·Nygard）。
基本介紹
- 中文名：發布！設計與部署穩定的分散式系統（第2版）
- 作者：[美]麥可·尼加德（Michael T·Nygard）
- ISBN：9787115529862
- 頁數：271頁
- 定價：89元
- 出版社：人民郵電出版社
- 出版時間：2020年1月
- 裝幀：平裝
- 開本：16開
內容簡介,圖書目錄,
內容簡介
作者根據自己的親身經歷和某些大型企業的案例，講述了如何創建高穩定性的軟體系統，分析了設計和實現中導致系統出現問題的原因。全書分為四個部分，每部分內容都由一個研究案例引出。第一部分介紹了如何保證系統的生存，即維護系統正常運行。第二部分介紹了為生產環境而設計，從基礎層、實例層、互連層和控制層等方面構建系統安全性。第三部分講述了交付系統，列出系統在部署過程中有可能出現的問題。第四部分引入適用性和混沌工程的概念，討論了如何解決系統性問題。
圖書目錄
第 1章 生產環境的生存法則 1
1.1 瞄準正確的目標 1
1.2 應對不斷擴大的挑戰範圍 2
1.3 多花5萬美元來節省100萬美元 3
1.4 讓“原力”與決策同在 4
1.5 設計務實的架構 4
1.6 小結 5
第 一部分 創造穩定性 7
第 2章 案例研究：讓航空公司停飛的代碼異常 8
2.1 進行變更 9
2.2 遭遇停機 10
2.3 嚴重後果 12
2.4 事後分析 12
2.5 尋找線索 13
2.6 證據確鑿 16
2.7 預防管用嗎 18
第3章 讓系統穩定運行 19
3.1 定義穩定性 20
3.2 延長系統壽命 20
3.3 系統失效方式 21
3.4 阻止裂紋蔓延 22
3.5 系統失效鏈 23
3.6 小結 24
第4章 穩定性的反模式 25
4.1 集成點 26
4.1.1 套接字協定 29
4.1.2 凌晨5點的緊急電話 31
4.1.3 HTTP協定 35
4.1.4 供應商的API程式庫 36
4.1.5 應對集成點的問題 37
4.1.6 要點回顧 37
4.2 同層連累反應 38
4.3 層疊失效 41
4.4 用戶 42
4.4.1 網路流量 42
4.4.2 難伺候的用戶 46
4.4.3 不受歡迎的用戶 47
4.4.4 惡意用戶 50
4.4.5 要點回顧 51
4.5 執行緒阻塞 51
4.5.1 發現阻塞 53
4.5.2 程式庫 55
4.5.3 要點回顧 56
4.6 自黑式攻擊 57
4.6.1 避免自黑式攻擊 57
4.6.2 要點回顧 58
4.7 放大效應 58
4.7.1 點對點通信 59
4.7.2 共享資源 60
4.7.3 要點回顧 61
4.8 失衡的系統容量 62
4.8.1 通過測試發現系統容量失衡 63
4.8.2 要點回顧 63
4.9 一窩蜂 64
4.10 做出誤判的機器 66
4.10.1 被放大的停機事故 66
4.10.2 控制和防護措施 69
4.10.3 要點回顧 69
4.11 緩慢的回響 70
4.12 無限長的結果集 71
4.12.1 黑色星期一 71
4.12.2 要點回顧 73
4.13 小結 74
第5章 穩定性的模式 75
5.1 逾時 75
5.2 斷路器 78
5.3 艙壁 80
5.4 穩態 83
5.4.1 數據清除 84
5.4.2 日誌檔案 85
5.4.3 記憶體中的快取 86
5.4.4 要點回顧 86
5.5 快速失敗 87
5.6 任其崩潰並替換 89
5.6.1 有限的粒度 89
5.6.2 快速替換 90
5.6.3 監管 90
5.6.4 重新歸隊 91
5.6.5 要點回顧 91
5.7 握手 91
5.8 考驗機 93
5.9 中間件解耦 96
5.10 卸下負載 98
5.11 背壓機制 99
5.12 調速器 101
5.13 小結 102
第二部分 為生產環境而設計 103
第6章 案例研究：屋漏偏逢連夜雨 104
6.1 寶寶的第 一個感恩節 105
6.2 把脈 106
6.3 感恩節 106
6.4 黑色星期五 107
6.5 生命體徵 108
6.6 進行診斷 109
6.7 求助專家 110
6.8 如何應對 111
6.9 應對奏效嗎 111
6.10 尾聲 112
第7章 基礎層 114
7.1 數據中心和雲端的聯網 115
7.1.1 網卡和名字 116
7.1.2 多網路編程 118
7.2 物理主機、虛擬機和容器 119
7.2.1 物理主機 119
7.2.2 數據中心的虛擬機 119
7.2.3 數據中心的容器 120
7.2.4 雲上的虛擬機 123
7.2.5 雲上的容器 125
7.3 小結 125
第8章 實例層 126
8.1 代碼 128
8.1.1 構建代碼 128
8.1.2 不可變、易處理的基礎設施 129
8.2 配置 130
8.2.1 配置檔案 131
8.2.2 易處理基礎設施的配置 131
8.3 明晰性 132
8.3.1 明晰性設計 133
8.3.2 提升明晰性的實現技術 134
8.3.3 記錄日誌 134
8.3.4 實例的健康度量指標 137
8.3.5 健康狀況檢查 138
8.4 小結 138
第9章 互連層 139
9.1 不同規模的解決方案 139
9.2 使用DNS 140
9.2.1 基於DNS的服務發現 140
9.2.2 基於DNS的負載均衡 141
9.2.3 基於DNS的GSLB 142
9.2.4 DNS的可用性 144
9.2.5 要點回顧 144
9.3 負載均衡 144
9.3.1 軟體負載均衡 145
9.3.2 硬體負載均衡 146
9.3.3 健康狀況檢查 147
9.3.4 會話黏性 147
9.3.5 按請求類型分隔流量 148
9.3.6 要點回顧 148
9.4 控制請求數量 148
9.4.1 系統為何會失效 149
9.4.2 防止災難 150
9.4.3 要點回顧 151
9.5 網路路由 151
9.6 發現服務 153
9.7 遷移虛擬IP位址 154
9.8 小結 155
第 10章 控制層 156
10.1 適合的控制層工具 156
10.2 機械效益 157
10.2.1 屬於系統失效，而非人為錯誤 158
10.2.2 運行得太快也有問題 158
10.3 平台和生態系統 159
10.4 開發環境就是生產環境 160
10.5 整個系統的明晰性 161
10.5.1 真實用戶監控 162
10.5.2 經濟價值高於技術價值 162
10.5.3 碎片化的風險 164
10.5.4 日誌和統計信息 164
10.5.5 要監控什麼 165
10.6 配置服務 166
10.7 環境整備和部署服務 167
10.8 命令與控制 169
10.8.1 要控制什麼 169
10.8.2 傳送命令 170
10.8.3 可編寫腳本的界面 170
10.8.4 要點回顧 171
10.9 平台廠商 171
10.10 工具清單 172
10.11 小結 172
第 11章 安全性 173
11.1 OWASP十大安全漏洞 173
11.1.1 注入 174
11.1.2 失效的身份驗證和會話管理 175
11.1.3 跨站腳本攻擊 178
11.1.4 失效的訪問控制 179
11.1.5 安全配置出現失誤 181
11.1.6 敏感數據泄露 182
11.1.7 防範攻擊不足 183
11.1.8 CSRF 183
11.1.9 使用含有已知漏洞的組件 184
11.1.10 API保護不足 185
11.2 最小特權原則 186
11.3 密碼的配置 187
11.4 安全即持續的過程 187
11.5 小結 188
第三部分 將系統交付 189
第 12章 案例研究：等待戈多 190
第 13章 為部署而設計 193
13.1 機器與服務 193
13.2 計畫停機時間的謬誤 193
13.3 自動化部署 194
13.4 持續部署 197
13.5 部署中的各個階段 198
13.5.1 關係資料庫模式 200
13.5.2 無模式資料庫 202
13.5.3 Web資源 205
13.5.4 推出新代碼 206
13.5.5 清理 208
13.6 像行家一樣部署 209
13.7 小結 210
第 14章 處理版本問題 211
14.1 幫助他人處理版本問題 211
14.1.1 不會破壞API的變更 211
14.1.2 破壞API的變更 215
14.2 處理其他系統的版本問題 217
14.3 小結 219
第四部分 解決系統性問題 221
第 15章 案例研究：不能承受的巨大顧客流量 222
15.1 倒計時後推出新系統 222
15.2 以QA測試為目標 223
15.3 負載測試 225
15.4 被眾多因素所害 227
15.5 測試仍然有差距 229
15.6 善後 229
第 16章 適應性 232
16.1 努力與回報的關係 232
16.2 過程和組織 233
16.2.1 平台團隊 235
16.2.2 愉快地發布 236
16.2.3 演化最重要的部分是滅絕 237
16.2.4 在團隊級別實現自治 239
16.2.5 謹防高效率 240
16.2.6 過程和組織小結 242
16.3 系統架構 242
16.3.1 演進式架構 242
16.3.2 鬆散的集群 245
16.3.3 顯式上下文 246
16.3.4 創造更多選項 247
16.3.5 系統架構小結 252
16.4 信息架構 252
16.4.1 訊息、事件和命令 253
16.4.2 讓服務自己控制其資源的標識符 254
16.4.3 URL的兩重性 256
16.4.4 擁抱多義性 259
16.4.5 避免概念泄露 260
16.4.6 信息架構小結 261
16.5 小結 261
第 17章 混沌工程 262
17.1 不可能構建第二個Facebook去做測試 262
17.2 混沌工程的先驅 263
17.3 猴子軍團 264
17.4 使用自己的混沌猴 265
17.4.1 先決條件 266
17.4.2 設計實驗 266
17.4.3 3種混沌注入 267
17.4.4 有針對性地注入混沌 268
17.4.5 自動和重複 269
17.5 從人的方面模擬災難 270
17.6 小結 271
