了得網計算機/網絡_發布!設計與部署穩定的分布式繫統(第2版) (美)邁克爾·尼加德(Mi

●章生產環境的生存法則1
1.1瞄準正確的目標1
1.2應對不斷擴大的挑戰範圍2
1.3多花來103
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.3HTTP協議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使用DNS140
9.2.1基於DNS的服務發現140
9.2.2基於DNS的負載均衡141
9.2.3基於DNS的GSLB142
9.2.4DNS的可用性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
0章控制層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
1章安全性173
11.1OWASP十大安全漏洞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.8CSRF183
11.1.9使用含有已知漏洞的組件184
11.1.10API保護不足185
11.2最小特權原則186
11.3密碼的配置187
11.4安全即持續的過程187
11.5小結188
第三部分將繫統交付189
2章案例研究：等待戈多190
3章為部署而設計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.3Web資源205
13.5.4推出新代碼206
13.5.5清理208
13.6像行家一樣部署209
13.7小結210
4章處理版本問題211
14.1幫助他人處理版本問題211
14.1.1不會破壞API的變更211
14.1.2破壞API的變更215
14.2處理其他繫統的版本問題217
14.3小結219
第四部分解決繫統性問題221
5章案例研究：不能承受的巨大顧客流量222
15.1倒計時後推出新繫統222
15.2以QA測試為目標223
15.3負載測試225
15.4被眾多因素所害227
15.5測試仍然有差距229
15.6善後229
6章適應性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.3URL的兩重性256
16.4.4擁抱多義性259
16.4.5避免概念洩露260
16.4.6信息架構小結261
16.5小結261
7章混沌工程262
17.1不可能構建第二個Facebook去做測試262
17.2混沌工程的先驅263
17.3猴子軍團264
17.4使用自己的混沌猴265
17.4.1先決條件266
17.4.2設計實驗266
17.4.33種混沌注入267
17.4.4有針對性地注入混沌268
17.4.5自動和重復269
17.5從人的方面模擬災難270
17.6小結271

商品搜索

商品分类

【醫學】

【各大出版社】