可伸縮架構:面向增長應用的高可用(Architecting for scale: high availability for your growing applications)

購買商店

可伸縮架構:面向增長應用的高可用(Architecting for scale: high availability for your growing applications)

$332.00

馬上購買

內容描述

隨著因特網的發展越來越成熟，流量和數據量飛速增長，許多公司的關鍵應用程序都面臨著伸縮性的問題，系統變得越來越復雜和脆弱，從而導致風險上升、可用性降低。本書是一本實踐指南，讓IT、DevOps和系統穩定性管理員能夠瞭解到，如何避免應用程序在發展過程中變得緩慢、數據不一致或者徹底不可用等問題。規模增長並不只意味著處理更多的用戶，還包括管理更多的風險和保證系統的可用性。作者Lee Atchison 在可用性、風險管理、服務和微服務、擴展應用程序和雲服務方面提出了一些技巧，使得我們在構建各類應用程序時，既能夠保證產品的質量，又能夠處理海量的流量、數據以及需求。如果你管理著軟件開發人員、系統可靠性工程師、DevOps工程師，或者你經營著一個擁有大規模應用程序和系統的機構，本書中所提供的建議和指導都能夠幫助你，讓你的系統運行得更加平穩和可靠。

目錄大綱

序.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

作者介紹

Lee Atchison是New Relic公司的首席雲架構師和佈道師。他已經在New Relic工作了4年，負責設計並領導建立了New Relic的基礎設施產品，幫助New Relic搭建了健壯的服務化系統架構，支撐起公司從一個很小的SaaS創業公司成長為一個高流量的公眾企業。
他非常擅長構建高可用的系統。Lee擁有28年的行業工作背景，之前在Amazon.com擔任了7年高級經理，了解到如何搭建基於雲的、可伸縮的系統架構。
在Amazon，他領導並建立了公司第一個軟件下載商店，搭建了AWS Elastic Beanstalk服務，並帶領團隊將Amazon的零售平台從一個單體架構成功遷移到了基於服務的架構。