持續(xù)演進的Cloud Native：云原生架構下微服務最佳實踐

第1章 綜述 1
1.1 Cloud Native的起源 1
1.2 Cloud Native的組成 4
1.3 Cloud Native背后的訴求 5
1.4 如何衡量Cloud Native的能力 5
1.5 Cloud Native的原則 6
第2章 微服務架構 11
2.1 微服務架構的起源 11
2.2 為什么采用微服務架構 12
2.2.1 單體架構與微服務架構 12
2.2.2 什么時候開始微服務架構 14
2.2.3 如何決定微服務架構的拆分粒度 14
2.3 微服務設計原則 15
2.4 微服務架構實施的先決條件 17
2.4.1 研發(fā)環(huán)境和流程上的轉變 17
2.4.2 拆分前先做好解耦 18
2.5 微服務劃分模式 20
2.5.1 基于業(yè)務復雜度選擇服務劃分方法 20
2.5.2 基于數(shù)據(jù)驅動劃分服務 21
2.5.3 基于領域驅動劃分服務 22
2.5.4 從已有單體架構中逐步劃分服務 23
2.5.5 微服務拆分策略 24
2.5.6 如何衡量服務劃分的合理性 25
2.6 微服務劃分反模式 26
2.7 微服務API設計 28
2.7.1 優(yōu)秀API的設計原則 28
2.7.2 服務間通信——RPC 28
2.7.3 序列化——Protobuf 30
2.7.4 服務間通信——RESTful 33
2.7.5 通過Swagger實現(xiàn)RESTful 36
2.7.6 通過Spring Boot、Springfox、Swagger實現(xiàn)RESTful 41
2.7.7 HTTP協(xié)議的進化——HTTP/2 46
2.7.8 HTTP/2和Protobuf的組合——gRPC 48
2.8 微服務框架 53
2.9 基于Dubbo框架實現(xiàn)微服務 54
2.10 基于Spring Cloud框架實現(xiàn)微服務 58
2.11 服務發(fā)現(xiàn)場景下的ZooKeeper與Etcd 67
2.12 微服務部署策略 68
2.12.1 服務獨享數(shù)據(jù)庫 69
2.12.2 服務獨享虛擬機/容器 70
2.13 為什么總覺得微服務架構很別扭 70
第3章 敏捷基礎設施及公共基礎服務 73
3.1 傳統(tǒng)基礎設施面臨的挑戰(zhàn) 73
3.2 什么是敏捷基礎設施 74
3.3 基于容器的敏捷基礎設施 75
3.3.1 容器VS虛擬機 76
3.3.2 安裝Docker 77
3.3.3 部署私有Docker Registry 79
3.3.4 基于Spring Boot、Maven、Docker構建微服務 79
3.3.5 基于docker-compose管理容器 84
3.4 基于公共基礎服務的平臺化 85
3.5 監(jiān)控告警服務 86
3.5.1 監(jiān)控數(shù)據(jù)采集 87
3.5.2 監(jiān)控數(shù)據(jù)接收模式 87
3.5.3 通過時間序列數(shù)據(jù)庫存儲監(jiān)控數(shù)據(jù) 88
3.5.4 開源監(jiān)控系統(tǒng)實現(xiàn)Prometheus 88
3.5.5 通過Prometheus和Grafana監(jiān)控服務 90
3.6 分布式消息中間件服務 96
3.6.1 分布式消息中間件的作用 97
3.6.2 業(yè)界常用的分布式消息中間件 98
3.6.3 Kafka的設計原理 99
3.6.4 為什么Kafka性能高 100
3.6.5 Kafka的數(shù)據(jù)存儲結構 102
3.6.6 如何保證Kafka不丟消息 104
3.6.7 Kafka跨數(shù)據(jù)中心場景集群部署模式 106
3.7 分布式緩存服務 108
3.7.1 分布式緩存的應用場景 109
3.7.2 業(yè)界常用的分布式緩存Memcached 110
3.7.3 業(yè)界常用的分布式緩存——Redis 111
3.7.4 Redis常用的分布式緩存集群模式 112
3.7.5 基于Codis實現(xiàn)Redis分布式緩存集群 116
3.8 分布式任務調(diào)度服務 118
3.8.1 通過Tbschedule實現(xiàn)分布式任務調(diào)度 119
3.8.2 通過Elastic-Job實現(xiàn)分布式任務調(diào)度 123
3.9 如何生成分布式ID 126
3.9.1 UUID 126
3.9.2 SnowFlake 127
3.9.3 Ticket Server 128
3.9.4 小結 129
第4章 可用性設計 130
4.1 綜述 130
4.1.1 可用性和可靠性的關系 130
4.1.2 可用性的衡量標準 131
4.1.3 什么降低了可用性 131
4.2 逐步切換 132
4.2.1 影子測試 132
4.2.2 藍綠部署 133
4.2.3 灰度發(fā)布/金絲雀發(fā)布 134
4.3 容錯設計 135
4.3.1 消除單點 136
4.3.2 特性開關 136
4.3.3 服務分級 137
4.3.4 降級設計 138
4.3.5 超時重試 139
4.3.6 隔離策略 152
4.3.7 熔斷器 153
4.4 流控設計 157
4.4.1 限流算法 157
4.4.2 流控策略 159
4.4.3 基于Guava限流 160
4.4.4 基于Nginx限流 162
4.5 容量預估 163
4.6 故障演練 164
4.7 數(shù)據(jù)遷移 165
4.7.1 邏輯分離，物理不分離 166
4.7.2 物理分離 166
第5章 可擴展性設計 168
5.1 加機器能解決問題嗎 168
5.2 橫向擴展 169
5.3 AKF擴展立方體 170
5.4 如何擴展長連接 172
5.5 如何擴展數(shù)據(jù)庫 175
5.5.1 X軸擴展——主從復制集群 175
5.5.2 Y軸擴展——分庫、垂直分表 176
5.5.3 Z軸擴展——分片（sharding） 177
5.5.4 為什么要帶拆分鍵 182
5.5.5 分片后的關聯(lián)查詢問題 183
5.5.6 分片擴容（re-sharding） 184
5.5.7 精選案例 187
5.6 如何擴展數(shù)據(jù)中心 190
5.6.1 兩地三中心和同城多活 190
5.6.2 同城多活 191
5.6.3 異地多活 192
第6章 性能設計 194
6.1 性能指標 195
6.2 如何樹立目標 195
6.3 如何尋找平衡點 196
6.4 如何定位瓶頸點 197
6.5 服務通信優(yōu)化 198
6.5.1 同步轉異步 198
6.5.2 阻塞轉非阻塞 199
6.5.3 序列化 200
6.6 通過消息中間件提升寫性能 201
6.7 通過緩存提升讀性能 202
6.7.1 基于ConcurrentHashMap實現(xiàn)本地緩存 203
6.7.2 基于Guava Cache實現(xiàn)本地緩存 204
6.7.3 緩存的常用模式 205
6.7.4 應用緩存的常見問題 207
6.8 數(shù)據(jù)庫優(yōu)化 208
6.8.1 通過執(zhí)行計劃分析瓶頸點 208
6.8.2 為搜索字段創(chuàng)建索引 209
6.8.3 通過慢查詢?nèi)罩痉治銎款i點 210
6.8.4 通過提升硬件能力優(yōu)化數(shù)據(jù)庫 211
6.9 簡化設計 212
6.9.1 轉移復雜度 212
6.9.2 從業(yè)務角度優(yōu)化 212
第7章 一致性設計 214
7.1 問題起源 214
7.2 基礎理論 215
7.2.1 什么是分布式事務 216
7.2.2 CAP定理 218
7.2.3 BASE理論 219
7.2.4 Quorum機制（NWR模型） 219
7.2.5 租約機制（Lease） 220
7.2.6 狀態(tài)機（Replicated State Machine） 221
7.3 分布式系統(tǒng)的一致性分類 222
7.3.1 以數(shù)據(jù)為中心的一致性模型 223
7.3.2 以用戶為中心的一致性模型 226
7.3.3 業(yè)界常用的一致性模型 229
7.4 如何實現(xiàn)強一致性 230
7.4.1 兩階段提交 230
7.4.2 三階段提交（3PC） 231
7.5 如何實現(xiàn)最終一致性 232
7.5.1 重試機制 232
7.5.2 本地記錄日志 233
7.5.3 可靠事件模式 233
7.5.4 Saga事務模型 235
7.5.5 TCC事務模型 237
7.6 分布式鎖 238
7.6.1 基于數(shù)據(jù)庫實現(xiàn)悲觀鎖和樂觀鎖 239
7.6.2 基于ZooKeeper的分布式鎖 241
7.6.3 基于Redis實現(xiàn)分布式鎖 242
7.7 如何保證冪等性 244
7.7.1 冪等令牌（Idempotency Key） 244
7.7.2 在數(shù)據(jù)庫中實現(xiàn)冪等性 246
第8章 未來值得關注的方向 247
8.1 Serverless 247
8.1.1 什么是Serverless 247
8.1.2 Serverless的現(xiàn)狀 248
8.1.3 Serverless的應用場景 249
8.2 Service Mesh 250
8.2.1 什么是Service Mesh 250
8.2.2 為什么需要Service Mesh 252
8.2.3 Service Mesh的現(xiàn)狀 253
8.2.4 Istio架構分析 255
第9章 研發(fā)流程 258
9.1 十二因子 258
9.2 為什么選擇DevOps 261
9.3 自動化測試 263
9.3.1 單元測試 263
9.3.2 TDD 264
9.3.3 提交即意味著可測試 265
9.4 Code Review 265
9.4.1 Code Review的意義 265
9.4.2 Code Review的原則 266
9.4.3 Code Review的過程 267
9.5 流水線 267
9.5.1 持續(xù)交付 267
9.5.2 持續(xù)部署流水線 268
9.5.3 基于開源打造流水線 268
9.5.4 Amazon的流水線 271
9.5.5 開發(fā)人員自服務 271
9.6 為什么需要AIOps 272
9.7 基于數(shù)據(jù)和反饋持續(xù)改進 273
9.8 擁抱變化 274
9.9 代碼即設計 274
第10章 團隊文化 276
10.1 為什么團隊文化如此重要 276
10.2 組織結構 278
10.2.1 團隊規(guī)模導致的問題 278
10.2.2 康威定律 278
10.2.3 扁平化的組織 279
10.2.4 獨裁的管理方式還是民主的管理方式 280
10.2.5 民主的團隊如何做決策 282
10.3 環(huán)境氛圍 282
10.3.1 公開透明的工作環(huán)境 282
10.3.2 學習型組織 283
10.3.3 減少正式的匯報 284
10.3.4 高效的會議 284
10.3.5 量化指標致死 286
10.4 管理風格 287
10.4.1 下屬請假你會拒絕嗎 287
10.4.2 為什么你招不到你想要的人 288
10.4.3 得到了所有人的認可，說明你并不是一個好的管理者 291
10.4.4 盡量避免用自己的權力去做決策 291
10.4.5 一屋不掃也可助你“蕩平天下” 292
10.4.6 如何留下你想要的人293
10.5 經(jīng)典案例 294
10.5.1 Instagram的團隊文化 294
10.5.2 Netflix的團隊文化 294