滿額折
雲原生：運用容器、函數計算和數據構建下一代應用（簡體書）
- 系列名：O'Reilly精品圖書系列
- ISBN13：9787111653240
- 出版社：機械工業出版社
- 作者：(美)鮑里斯‧肖勒; 特倫特‧斯旺森
- 譯者：季奔牛
- 裝訂／頁數：平裝／197頁
- 規格：24cm*17cm (高/寬)
- 版次：一版
- 出版日：2020/05/11
相關商品
商品簡介
作者簡介
名人/編輯推薦
目次
商品簡介
本書旨在能夠提供一些基礎知識，來幫助開發者和架構師更從容地開啟雲原生應用之旅。本書首先介紹一些分布式系統的基本原理及其與雲原生應用的關係，然後再進一步介紹容器和函數等相關技術，接著，本書會介紹服務間的通信模式、服務的彈性和數據模式，並討論在什麼情況下應該使用這些技術，*後會總結一些經驗性的東西，例如如何結合DevOps方法，怎麼兼顧可移植性，以及一些*佳實踐。這些*佳實踐對於打造一個成功的雲原生應用是非常有幫助的。這本書不會手把手教你如何實現一個滿足特定業務需求的雲原生應用。但是在讀完這本書之後，你一定會知道如何去設計、構建和運維一個成功的雲原生應用。
作者簡介
鮑裡斯·肖勒（Boris Scholl），是Azure計算團隊的產品架構師，專注於下一代分布式系統平臺和應用程序模型的研究。自2011年以來，他一直從事Azure開發工具和平臺方面的工作，擔任不同的產品研發角色。在離開微軟18個月之後，Boris于2018年重新加入Azure計算團隊，領導一個研發團隊開發基於Kubernetes和服務網格的微服務平臺。
特倫特·斯旺森（Trent Swanson），是專注於雲和邊緣技術的軟件架構師。作為Full Scale 180的聯合創始人和顧問，他與微軟的一些大客戶合作，幫助他們將應用遷移上雲，或在雲中構建應用。他一直致力於利用Docker、無服務器技術和微服務架構來設計、構建和運行大型應用程序。
彼得·加索維奇（Peter Jausovec），是一位軟件工程師，在軟件開發和技術領域擁有十多年的經驗。在他的職業生涯中，他曾擔任過各種角色。近年來，他一直致力於開發分布式系統上的雲原生解決方案。
特倫特·斯旺森（Trent Swanson），是專注於雲和邊緣技術的軟件架構師。作為Full Scale 180的聯合創始人和顧問，他與微軟的一些大客戶合作，幫助他們將應用遷移上雲，或在雲中構建應用。他一直致力於利用Docker、無服務器技術和微服務架構來設計、構建和運行大型應用程序。
彼得·加索維奇（Peter Jausovec），是一位軟件工程師，在軟件開發和技術領域擁有十多年的經驗。在他的職業生涯中，他曾擔任過各種角色。近年來，他一直致力於開發分布式系統上的雲原生解決方案。
名人/編輯推薦
Azure計算團隊的產品架構師撰寫，現代雲原生應用開發入門實踐指南
目次
前言1
第1章 雲原生簡介5
1.1 分布式系統5
1.1.1 分布式系統的誤區5
1.1.2 CAP定理8
1.2 十二要素應用8
1.3 可用性和服務等級協議11
1.4 本章小結12
第2章 雲原生基礎13
2.1 容器13
2.1.1 容器隔離等級15
2.1.2 容器編排16
2.1.3 Kubernetes概述17
2.1.4 Kubernetes和容器20
2.2 無服務器架構21
2.3 函數計算22
2.4 從虛擬機到雲原生23
2.4.1 提升和轉變23
2.4.2 應用的現代化改造24
2.4.3 應用的優化26
2.5 微服務26
2.5.1 微服務架構的優勢27
2.5.2 微服務架構帶來的挑戰29
2.6 本章小結31
第3章 雲原生應用的設計33
3.1 雲原生應用的基礎33
3.1.1 精益運營33
3.1.2 安全性35
3.1.3 可靠性與可用性36
3.1.4 可擴展性與成本37
3.2 雲原生與傳統架構的對比37
3.3 函數計算與服務41
3.3.1 函數計算的使用場景42
3.3.2 使用函數計算的考慮因素42
3.3.3 函數與服務的組合運用43
3.4 API設計與版本控制45
3.4.1 API的前後兼容46
3.4.2 語義版本號47
3.5 服務間的通信48
3.5.1 通信協議48
3.5.2 消息協議50
3.5.3 序列化的考慮因素50
3.5.4 冪等性51
3.5.5 請求與響應52
3.5.6 發佈者與訂閱者53
3.5.7 發佈者/訂閱者模式與請求/響應模式間的選擇55
3.5.8 同步與異步56
3.6 網關56
3.6.1 路由57
3.6.2 聚合58
3.6.3 卸載59
3.6.4 網關的實現60
3.7 出口網關60
3.8 服務網格60
3.9 架構示例69
3.10 本章小結73
第4章 數據處理75
4.1 數據存儲系統76
4.1.1 對象、文件和磁盤77
4.1.2 數據庫78
4.1.3 流和隊列80
4.1.4 區塊鏈81
4.1.5 數據存儲的選擇81
4.2 多數據存儲下的數據84
4.2.1 捕獲數據更改85
4.2.2 將更改作為事件寫入更改日誌87
4.2.3 事務監管88
4.2.4 事務回滾90
4.2.5 提取、轉換和加載90
4.2.6 微服務和數據湖91
4.3 客戶端訪問數據94
4.3.1 受限的客戶令牌（代客密鑰）94
4.3.2 細粒度訪問控制的數據庫服務95
4.3.3 GraphQL數據服務96
4.4 可快速伸縮的數據97
4.4.1 數據分片98
4.4.2 數據緩存98
4.4.3 內容分發網絡99
4.5 數據分析101
4.5.1 數據流101
4.5.2 批處理101
4.5.3 對象存儲上的數據湖102
4.5.4 數據湖和數據倉庫102
4.5.5 分布式查詢引擎103
4.6 Kubernetes中的數據庫104
4.6.1 存儲卷104
4.6.2 StatefulSet106
4.6.3 DaemonSet107
4.7 本章小結107
第5章 DevOps109
5.1 什麼是DevOps109
5.1.1 協作109
5.1.2 自動化110
5.1.3 精益原則和流程110
5.1.4 度量111
5.1.5 分享111
5.2 測試112
5.2.1 測試替身113
5.2.2 自動化測試金字塔113
5.2.3 不同測試類型的適用時機118
5.2.4 測試節奏119
5.2.5 在生產環境中測試120
5.3 開發環境和工具122
5.3.1 開發工具123
5.3.2 開發環境126
5.3.3 本地開發環境126
5.3.4 本地開發環境結合遠端集群127
5.3.5 Skaffold開發工作流127
5.3.6 將遠端集群路由到本地開發環境129
5.3.7 雲端開發環境129
5.4 持續集成/持續交付130
5.4.1 源代碼管理131
5.4.2 構建階段132
5.4.3 測試階段132
5.4.4 部署階段134
5.4.5 發佈階段136
5.4.6 發佈後階段137
5.5 監控137
5.5.1 收集指標139
5.5.2 服務的可觀測性145
5.6 配置管理149
5.6.1 單一環境變量151
5.6.2 多環境變量151
5.6.3 將配置數據放入存儲卷中152
5.6.4 密鑰保存152
5.6.5 部署配置154
5.7 持續集成/持續交付流程示例156
5.8 本章小結159
第6章 最佳實踐161
6.1 邁向雲原生161
6.1.1 找個合理的理由打破巨石應用161
6.1.2 先解耦簡單的服務162
6.1.3 學會小規模的運維162
6.1.4 使用防損層模式162
6.1.5 使用刀砍模式162
6.1.6 準備一個數據遷移策略164
6.1.7 重寫所有模板代碼164
6.1.8 重新考慮框架、語言、數據結構和數據存儲164
6.1.9 淘汰老代碼164
6.2 確保彈性164
6.2.1 用重試來解決瞬時故障165
6.2.2 使用有限次的重試165
6.2.3 用斷路器來處理非瞬時故障166
6.2.4 優雅地降級166
6.2.5 使用隔離模式166
6.2.6 實現健康及就緒檢查166
6.2.7 為容器設定CPU和內存限制166
6.2.8 實現限速和限流167
6.3 確保安全性167
6.3.1 安全性需求同其他需求一樣重要167
6.3.2 在設計時就考慮安全性167
6.3.3 授予最小訪問權限167
6.3.4 使用獨立的賬號、訂閱和租客167
6.3.5 安全地存儲所有密鑰168
6.3.6 模糊化數據168
6.3.7 傳輸數據加密168
6.3.8 使用聯合身份管理168
6.3.9 使用基於角色的訪問控制168
6.3.10 Kubernetes pod的隔離169
6.4 處理數據169
6.4.1 使用託管數據庫和數據分析服務169
6.4.2 使用最符合數據需求的存儲169
6.4.3 將數據保存在多個地域或可用區中170
6.4.4 使用數據分區和複製以提高擴展性170
6.4.5 避免過度獲取及頻繁的I/O操作170
6.4.6 不要把業務邏輯放在數據庫中執行170
6.4.7 使用類生產環境數據來測試170
6.4.8 處理瞬時故障171
6.5 性能和伸縮性171
6.5.1 設計可擴展的無狀態服務171
6.5.2 使用平臺的自動伸縮功能171
6.5.3 使用緩存172
6.5.4 用分區來實現超出服務限制的擴容172
6.6 函數計算172
6.6.1 編寫單一用途的函數172
6.6.2 避免串聯函數172
6.6.3 函數應保持輕量和簡單173
6.6.4 實現無狀態函數173
6.6.5 分離函數入口和函數的業務邏輯173
6.6.6 避免長時間運行的函數173
6.6.7 用隊列解決跨函數通信問題173
6.7 運維173
6.7.1 部署和發佈是兩項獨立的活動174
6.7.2 部署的內容要儘量小174
6.7.3 組件層級的CI/CD定義174
6.7.4 應用部署的一致性174
6.7.5 採用零宕機發佈174
6.7.6 不要變更部署後的架構174
6.7.7 使用容器化構建175
6.7.8 用代碼來描述基礎設施175
6.7.9 使用命名空間來組織Kubernetes中的服務175
6.7.10 環境間的隔離175
6.7.11 分隔函數源代碼175
6.7.12 關聯代碼提交和部署175
6.8 日誌、監控及告警175
6.8.1 使用統一的日誌系統176
6.8.2 使用關聯ID176
6.8.3 在日誌記錄中包含上下文176
6.8.4 統一的結構化日誌格式176
6.8.5 適當地標記指標176
6.8.6 避免告警疲勞177
6.8.7 定義基於重點性能指標的告警177
6.8.8 在生產環境中持續測試177
6.8.9 從基礎的指標開始178
6.9 服務通信178
6.9.1 設計時考慮前後兼容性178
6.9.2 封裝好服務避免洩露內部細節179
6.9.3 優先考慮異步通信179
6.9.4 使用高效的序列化技術179
6.9.5 使用隊列和流來應對高負載和流量高峰180
6.9.6 用批處理來提高請求處理的效率180
6.9.7 拆分大的消息180
6.10 容器180
6.10.1 將鏡像存儲在可信的註冊服務器中180
6.10.2 充分利用Docker的構建緩存181
6.10.3 不要使用特權模式運行容器181
6.10.4 使用顯式的容器鏡像標簽181
6.10.5 保持小的容器鏡像181
6.10.6 單個容器只運行一個應用182
6.10.7 使用可信鏡像倉庫中經過驗證的鏡像182
6.10.8 對鏡像進行漏洞掃描182
6.10.9 不要將數據保存在容器中183
6.10.10 永遠不要在容器中存放密鑰和配置183
6.11 本章小結183
第7章 可移植性185
7.1 為什麼要使應用可移植185
7.2 可移植性的代價186
7.3 何時及如何實現可移植性187
第1章 雲原生簡介5
1.1 分布式系統5
1.1.1 分布式系統的誤區5
1.1.2 CAP定理8
1.2 十二要素應用8
1.3 可用性和服務等級協議11
1.4 本章小結12
第2章 雲原生基礎13
2.1 容器13
2.1.1 容器隔離等級15
2.1.2 容器編排16
2.1.3 Kubernetes概述17
2.1.4 Kubernetes和容器20
2.2 無服務器架構21
2.3 函數計算22
2.4 從虛擬機到雲原生23
2.4.1 提升和轉變23
2.4.2 應用的現代化改造24
2.4.3 應用的優化26
2.5 微服務26
2.5.1 微服務架構的優勢27
2.5.2 微服務架構帶來的挑戰29
2.6 本章小結31
第3章 雲原生應用的設計33
3.1 雲原生應用的基礎33
3.1.1 精益運營33
3.1.2 安全性35
3.1.3 可靠性與可用性36
3.1.4 可擴展性與成本37
3.2 雲原生與傳統架構的對比37
3.3 函數計算與服務41
3.3.1 函數計算的使用場景42
3.3.2 使用函數計算的考慮因素42
3.3.3 函數與服務的組合運用43
3.4 API設計與版本控制45
3.4.1 API的前後兼容46
3.4.2 語義版本號47
3.5 服務間的通信48
3.5.1 通信協議48
3.5.2 消息協議50
3.5.3 序列化的考慮因素50
3.5.4 冪等性51
3.5.5 請求與響應52
3.5.6 發佈者與訂閱者53
3.5.7 發佈者/訂閱者模式與請求/響應模式間的選擇55
3.5.8 同步與異步56
3.6 網關56
3.6.1 路由57
3.6.2 聚合58
3.6.3 卸載59
3.6.4 網關的實現60
3.7 出口網關60
3.8 服務網格60
3.9 架構示例69
3.10 本章小結73
第4章 數據處理75
4.1 數據存儲系統76
4.1.1 對象、文件和磁盤77
4.1.2 數據庫78
4.1.3 流和隊列80
4.1.4 區塊鏈81
4.1.5 數據存儲的選擇81
4.2 多數據存儲下的數據84
4.2.1 捕獲數據更改85
4.2.2 將更改作為事件寫入更改日誌87
4.2.3 事務監管88
4.2.4 事務回滾90
4.2.5 提取、轉換和加載90
4.2.6 微服務和數據湖91
4.3 客戶端訪問數據94
4.3.1 受限的客戶令牌（代客密鑰）94
4.3.2 細粒度訪問控制的數據庫服務95
4.3.3 GraphQL數據服務96
4.4 可快速伸縮的數據97
4.4.1 數據分片98
4.4.2 數據緩存98
4.4.3 內容分發網絡99
4.5 數據分析101
4.5.1 數據流101
4.5.2 批處理101
4.5.3 對象存儲上的數據湖102
4.5.4 數據湖和數據倉庫102
4.5.5 分布式查詢引擎103
4.6 Kubernetes中的數據庫104
4.6.1 存儲卷104
4.6.2 StatefulSet106
4.6.3 DaemonSet107
4.7 本章小結107
第5章 DevOps109
5.1 什麼是DevOps109
5.1.1 協作109
5.1.2 自動化110
5.1.3 精益原則和流程110
5.1.4 度量111
5.1.5 分享111
5.2 測試112
5.2.1 測試替身113
5.2.2 自動化測試金字塔113
5.2.3 不同測試類型的適用時機118
5.2.4 測試節奏119
5.2.5 在生產環境中測試120
5.3 開發環境和工具122
5.3.1 開發工具123
5.3.2 開發環境126
5.3.3 本地開發環境126
5.3.4 本地開發環境結合遠端集群127
5.3.5 Skaffold開發工作流127
5.3.6 將遠端集群路由到本地開發環境129
5.3.7 雲端開發環境129
5.4 持續集成/持續交付130
5.4.1 源代碼管理131
5.4.2 構建階段132
5.4.3 測試階段132
5.4.4 部署階段134
5.4.5 發佈階段136
5.4.6 發佈後階段137
5.5 監控137
5.5.1 收集指標139
5.5.2 服務的可觀測性145
5.6 配置管理149
5.6.1 單一環境變量151
5.6.2 多環境變量151
5.6.3 將配置數據放入存儲卷中152
5.6.4 密鑰保存152
5.6.5 部署配置154
5.7 持續集成/持續交付流程示例156
5.8 本章小結159
第6章 最佳實踐161
6.1 邁向雲原生161
6.1.1 找個合理的理由打破巨石應用161
6.1.2 先解耦簡單的服務162
6.1.3 學會小規模的運維162
6.1.4 使用防損層模式162
6.1.5 使用刀砍模式162
6.1.6 準備一個數據遷移策略164
6.1.7 重寫所有模板代碼164
6.1.8 重新考慮框架、語言、數據結構和數據存儲164
6.1.9 淘汰老代碼164
6.2 確保彈性164
6.2.1 用重試來解決瞬時故障165
6.2.2 使用有限次的重試165
6.2.3 用斷路器來處理非瞬時故障166
6.2.4 優雅地降級166
6.2.5 使用隔離模式166
6.2.6 實現健康及就緒檢查166
6.2.7 為容器設定CPU和內存限制166
6.2.8 實現限速和限流167
6.3 確保安全性167
6.3.1 安全性需求同其他需求一樣重要167
6.3.2 在設計時就考慮安全性167
6.3.3 授予最小訪問權限167
6.3.4 使用獨立的賬號、訂閱和租客167
6.3.5 安全地存儲所有密鑰168
6.3.6 模糊化數據168
6.3.7 傳輸數據加密168
6.3.8 使用聯合身份管理168
6.3.9 使用基於角色的訪問控制168
6.3.10 Kubernetes pod的隔離169
6.4 處理數據169
6.4.1 使用託管數據庫和數據分析服務169
6.4.2 使用最符合數據需求的存儲169
6.4.3 將數據保存在多個地域或可用區中170
6.4.4 使用數據分區和複製以提高擴展性170
6.4.5 避免過度獲取及頻繁的I/O操作170
6.4.6 不要把業務邏輯放在數據庫中執行170
6.4.7 使用類生產環境數據來測試170
6.4.8 處理瞬時故障171
6.5 性能和伸縮性171
6.5.1 設計可擴展的無狀態服務171
6.5.2 使用平臺的自動伸縮功能171
6.5.3 使用緩存172
6.5.4 用分區來實現超出服務限制的擴容172
6.6 函數計算172
6.6.1 編寫單一用途的函數172
6.6.2 避免串聯函數172
6.6.3 函數應保持輕量和簡單173
6.6.4 實現無狀態函數173
6.6.5 分離函數入口和函數的業務邏輯173
6.6.6 避免長時間運行的函數173
6.6.7 用隊列解決跨函數通信問題173
6.7 運維173
6.7.1 部署和發佈是兩項獨立的活動174
6.7.2 部署的內容要儘量小174
6.7.3 組件層級的CI/CD定義174
6.7.4 應用部署的一致性174
6.7.5 採用零宕機發佈174
6.7.6 不要變更部署後的架構174
6.7.7 使用容器化構建175
6.7.8 用代碼來描述基礎設施175
6.7.9 使用命名空間來組織Kubernetes中的服務175
6.7.10 環境間的隔離175
6.7.11 分隔函數源代碼175
6.7.12 關聯代碼提交和部署175
6.8 日誌、監控及告警175
6.8.1 使用統一的日誌系統176
6.8.2 使用關聯ID176
6.8.3 在日誌記錄中包含上下文176
6.8.4 統一的結構化日誌格式176
6.8.5 適當地標記指標176
6.8.6 避免告警疲勞177
6.8.7 定義基於重點性能指標的告警177
6.8.8 在生產環境中持續測試177
6.8.9 從基礎的指標開始178
6.9 服務通信178
6.9.1 設計時考慮前後兼容性178
6.9.2 封裝好服務避免洩露內部細節179
6.9.3 優先考慮異步通信179
6.9.4 使用高效的序列化技術179
6.9.5 使用隊列和流來應對高負載和流量高峰180
6.9.6 用批處理來提高請求處理的效率180
6.9.7 拆分大的消息180
6.10 容器180
6.10.1 將鏡像存儲在可信的註冊服務器中180
6.10.2 充分利用Docker的構建緩存181
6.10.3 不要使用特權模式運行容器181
6.10.4 使用顯式的容器鏡像標簽181
6.10.5 保持小的容器鏡像181
6.10.6 單個容器只運行一個應用182
6.10.7 使用可信鏡像倉庫中經過驗證的鏡像182
6.10.8 對鏡像進行漏洞掃描182
6.10.9 不要將數據保存在容器中183
6.10.10 永遠不要在容器中存放密鑰和配置183
6.11 本章小結183
第7章 可移植性185
7.1 為什麼要使應用可移植185
7.2 可移植性的代價186
7.3 何時及如何實現可移植性187
您曾經瀏覽過的商品
購物須知
大陸出版品因裝訂品質及貨運條件與台灣出版品落差甚大，除封面破損、內頁脫落等較嚴重的狀態，其餘商品將正常出貨。
特別提醒：部分書籍附贈之內容(如音頻mp3或影片dvd等)已無實體光碟提供，需以QR CODE 連結至當地網站註冊“並通過驗證程序”，方可下載使用。
無現貨庫存之簡體書，將向海外調貨：
海外有庫存之書籍，等候約45個工作天;
海外無庫存之書籍，平均作業時間約60個工作天，然不保證確定可調到貨，尚請見諒。
為了保護您的權益，「三民網路書店」提供會員七日商品鑑賞期(收到商品為起始日)。
若要辦理退貨，請在商品鑑賞期內寄回，且商品必須是全新狀態與完整包裝(商品、附件、發票、隨貨贈品等)否則恕不接受退貨。