企業架構與繞不開的微服務（雙色）

《企業架構與繞不開的微服務（雙色）》是2022年3月電子工業出版社出版圖書，作者是樊超。

基本介紹

• 中文名：企業架構與繞不開的微服務（雙色）
• 作者：樊超
• 出版社：電子工業出版社
• 出版時間：2022年3月
• 頁數：424 頁
• 定價：119 元
• 開本：16 開
• ISBN：9787121430169

內容簡介

本書分析了當今企業架構面臨的挑戰，介紹了如何使用微服務架構來應對這些挑戰。企業在套用微服務時面臨許多痛點，本書對痛點出現的原因和場景進行了深入的分析，提出了可用於消除或緩解痛點影響的模式。 本書內容注重理論和實踐的結合。在理論方面，介紹了企業架構標準、雲原生思想和相關技術、微服務的前世今生，以及領域驅動設計等；在實踐方面，介紹了用於拆分微服務的“五步法”、包含4個維度的“企業雲原生成熟度模型”，以及衡量企業變革成果的“效果收益評估方法”等。 本書的核心內容包括：企業架構的定義與企業架構師的職責；企業架構是否設計良好的評判依據；雲原生的相關思想和技術；微服務的起源、演化、特性、拆分方法和落地指南；雲原生為企業帶來的機遇與變革等。 本書可以幫助企業明確痛點、制定原則、規劃路徑、建設能力和評估成效，最終實現微服務架構在企業中的持續運營和持續演化，從而應對日益增多的業務挑戰。

圖書目錄

★★第1篇 企業中的架構和架構師

第1章 被輕視的企業架構 / 2

1.1 被濫用的架構 / 2

1.1.1 來源於建築卻不同於建築 / 2

1.1.2 難以統一的定義 / 3

1.1.3 架構與架構風格 / 4

1.2 常見的架構風格 / 5

1.2.1 三層架構 / 5

1.2.2 SOA架構 / 8

1.2.3 單體架構 / 12

1.2.4 微服務架構 / 13

1.3 與眾不同的企業架構 / 14

1.3.1 更大的範圍 / 14

1.3.2 更大的風險 / 15

1.3.3 更大的收益 / 15

1.3.4 支撐企業數位化轉型 / 16

1.4 舉步維艱的企業架構 / 18

1.4.1 企業內的重視程度不足 / 18

1.4.2 系統間的壁壘和代溝 / 20

1.4.3 簡單粗暴的集成方式 / 22

1.4.4 尷尬的IT部門 / 24

1.4.5 難以量化的生產力 / 26

1.4.6 快速變化的外部環境 / 27

1.5 企業架構反模式 / 28

1.5.1 採用“雙速IT” / 28

1.5.2 視IT部門為成本中心 / 31

1.5.3 以為“買買買”可以解決一切問題 / 33

1.5.4 主數據管理與微服務思想矛盾 / 34

1.5.5 以技術驅動架構設計 / 37

1.6 企業架構標準來拯救 / 38

1.6.1 TOGAF簡介 / 39

1.6.2 首先要有願景 / 42

1.6.3 一切都圍繞著需求 / 46

1.6.4 4種架構 / 48

1.6.5 架構開發方法 / 50

1.6.6 遷移要被規劃 / 51

1.6.7 實施要被治理 / 54

1.6.8 變更要被管理 / 56

1.6.9 TOGAF的能力框架 / 59

1.6.10 企業架構標準小結 / 63

1.7 本章小結 / 64

第2章 不一樣的EA架構師 / 65

2.1 誰是架構師 / 65

2.2 不一樣的EA架構師 / 68

2.2.1 與建築師不一樣 / 68

2.2.2 與技術架構師不一樣 / 70

2.2.3 與業務架構師不一樣 / 73

2.2.4 與敏捷架構師不一樣 / 75

2.2.5 這才是EA架構師 / 79

2.3 EA架構師工作反模式 / 81

2.3.1 獨立的架構組 / 82

2.3.2 中央集權和獨裁 / 86

2.3.3 以有“技術潔癖”為榮 / 89

2.3.4 妄想“技術改變世界” / 92

2.4 做好一個EA架構師 / 94

2.4.1 成為漩渦的中心 / 95

2.4.2 成為導師：為他人轉身 / 98

2.4.3 搭上“架構師電梯” / 102

2.5 本章小結 / 107

第3章 企業架構的目標 / 108

3.1 評估架構的4個維度 / 108

3.2 為企業“鬆綁” / 109

3.2.1 不可避免的綁定 / 109

3.2.2 8種綁定類型 / 110

3.2.3 綁定有害 / 113

3.2.4 鬆綁模式 / 120

3.2.5 綁定依然不可避免 / 127

3.3 讓功能儘快面世 / 127

3.3.1 好與快，一個都不能少 / 128

3.3.2 為飛行中的飛機更換零件 / 130

3.3.3 讓人月不再是神話 / 132

3.4 不再被半夜的電話驚醒 / 133

3.4.1 抵禦安全事件 / 134

3.4.2 讓性能不再是空話 / 137

3.4.3 讓系統變成“打不死的小強” / 139

3.4.4 自動化系統的韌性 / 142

3.5 生生不息地持續演化 / 143

3.6 本章小結 / 145

★★第2篇 雲原生來拯救

第4章 雲原生 / 147

4.1 雲原生的定義 / 147

4.1.1 雲原生套用 / 147

4.1.2 雲原生技術 / 148

4.1.3 雲原生架構 / 148

4.2 雲原生的代表技術 / 149

4.2.1 新一代虛擬化技術：容器 / 149

4.2.2 細粒度分散式架構：微服務 / 150

4.2.3 第三代微服務架構：服務格線 / 151

4.2.4 只能重建不能修改：不可變基礎設施 / 152

4.2.5 關注目的而非過程：聲明式API / 154

4.3 再談容器 / 156

4.3.1 容器 VS 虛擬機 / 156

4.3.2 容器與鏡像 / 157

4.3.3 容器編排技術 / 159

4.3.4 容器與微服務 / 161

4.4 再談服務格線 / 161

4.4.1 服務格線的實現 / 161

4.4.2 與API網關的關係 / 163

4.4.3 服務格線與微服務 / 165

4.4.4 適用場景 / 167

4.4.5 不適用場景 / 168

4.5 雲原生技術改變企業架構 / 169

4.5.1 雲原生技術帶來的改變 / 169

4.5.2 新的架構原則 / 172

4.5.3 新的架構模式 / 173

4.6 雲原生架構的評判標準 / 176

4.6.1 是否符合“12因素” / 176

4.6.2 是否使用了微服務架構 / 182

4.6.3 是否使用了DevOps / 184

4.7 不是“銀彈”，也不免費 / 186

4.7.1 終極架構謬誤 / 186

4.7.2 比想像中更高的成本 / 187

4.8 本章小結 / 190

★★第3篇 雲原生的核心：微服務

第5章 微服務的前世今生 / 192

5.1 前世與今生 / 192

5.2 從單體到微服務 / 193

5.2.1 微服務的反面：單體 / 193

5.2.2 微服務的前世：SOA / 195

5.2.3 微服務架構的定義 / 195

5.3 微服務架構原則 / 197

5.3.1 業務驅動原則 / 197

5.3.2 單一職責原則 / 199

5.3.3 信息隱藏原則 / 199

5.3.4 去中心化原則 / 200

5.3.5 獨立部署原則 / 200

5.3.6 隔離失敗原則 / 201

5.3.7 可視化原則 / 201

5.3.8 技術無關原則 / 202

5.4 解讀微服務架構九大特性 / 202

5.4.1 組件化與多服務 / 203

5.4.2 圍繞業務功能組織團隊 / 204

5.4.3 做產品而不是做項目 / 205

5.4.4 智慧型端點與傻瓜通道 / 206

5.4.5 去中心化的治理技術 / 207

5.4.6 去中心化的數據管理 / 209

5.4.7 基礎設施自動化 / 209

5.4.8 容錯設計 / 210

5.4.9 演化式設計 / 211

5.5 原則和特性帶來的優勢 / 212

5.5.1 組件可由不同技術棧實現 / 213

5.5.2 細粒度地按需擴縮容 / 213

5.5.3 局部不可用不會拖累整體 / 214

5.5.4 縮短功能面試時間 / 214

5.5.5 適合大規模團隊並行工作 / 215

5.5.6 一個服務可支持多種終端 / 215

5.5.7 服務可由開發團隊自治 / 216

5.6 微服務架構不是“銀彈” / 216

5.6.1 開發、部署、運維困難 / 216

5.6.2 存在網路延遲 / 219

5.6.3 相比單體架構更加脆弱 / 220

5.6.4 可能出現“孤兒服務” / 220

5.6.5 可被黑客攻擊的點多 / 221

5.7 在這些時候請不要使用微服務 / 222

5.7.1 無法忍受增加的成本 / 222

5.7.2 無法忍受架構複雜度 / 224

5.7.3 無法忍受網路延遲 / 225

5.7.4 無法建立有效的基礎設施 / 225

5.7.5 需要強事務一致性 / 226

5.7.6 需要頻繁變更接口 / 226

5.7.7 團隊規模較小 / 227

5.7.8 初創團隊 / 228

5.7.9 缺乏業務知識 / 228

5.7.10 由客戶自行安裝和管理的軟體 / 229

5.8 本章小結 / 229

第6章 領域驅動設計與微服務拆分 / 231

6.1 DDD可以用於微服務拆分嗎 / 231

6.2 拆分中必用的領域概念 / 233

6.2.1 有效溝通模式：統一語言 / 233

6.2.2 要溝通的對象：實體 / 234

6.2.3 粗粒度的拆分：子域 / 236

6.2.4 中粒度的拆分：限界上下文 / 238

6.2.5 細粒度的拆分：聚合 / 240

6.2.6 避免循環依賴：限界上下文映射圖 / 243

6.3 拆分中可用的領域概念 / 244

6.3.1 互動模式 / 244

6.3.2 模組單體的基礎：模組 / 246

6.4 拆分中不用的領域概念 / 247

6.4.1 指導編碼的值對象 / 247

6.4.2 與微服務中的“服務”不同含義的“服務” / 248

6.5 拆分中可用的設計模式 / 249

6.5.1 分層架構 / 249

6.5.2 六邊形架構 / 250

6.5.3 柔性設計 / 252

6.6 再談DDD中的邊界 / 252

6.7 本章小結 / 253

第7章 微服務拆分方法 / 254

7.1 領域分析法 / 254

7.1.1 四色建模法 / 255

7.1.2 四色建模法拆分步驟 / 255

7.1.3 事件風暴法 / 256

7.1.4 事件風暴法拆分步驟 / 256

7.1.5 領域分析法的不足 / 257

7.2 筆者總結的微服務拆分五步法 / 258

7.3 第一步：預備 / 258

7.3.1 組建架構開發團隊 / 259

7.3.2 評估企業能力成熟度 / 259

7.3.3 界定架構範圍及識別相關方 / 260

7.3.4 識別和定義架構原則 / 261

7.4 第二步：開發業務架構 / 262

7.4.1 粗粒度地拆分業務子域 / 262

7.4.2 選擇一個核心子域並遍歷其中的場景 / 263

7.4.3 分析每個場景中的用例 / 264

7.4.4 為不同的視角建立相應的視圖 / 266

7.5 第三步：領域分析 / 266

7.5.1 識別領域事件 / 267

7.5.2 識別決策命令 / 268

7.5.3 識別領域名詞 / 268

7.5.4 根據領域名詞識別聚合 / 268

7.5.5 拆分限界上下文 / 268

7.6 第四步：開發非業務架構 / 269

7.6.1 開發數據架構 / 269

7.6.2 開發套用架構 / 270

7.6.3 開發技術架構 / 270

7.7 第五步：用非業務架構審查拆分結果 / 270

7.7.1 消除循環依賴 / 271

7.7.2 審查是否滿足非業務架構 / 271

7.8 案例及內容模板 / 272

7.8.1 案例背景介紹 / 272

7.8.2 案例拆分第一步：預備 / 272

7.8.3 案例拆分第二步：開發業務架構 / 276

7.8.4 案例拆分第三步：領域分析 / 281

7.8.5 案例拆分第四步：開發非業務架構 / 285

7.8.6 案例拆分第五步：用非業務架構審查拆分結果 / 286

7.8.7 案例小結 / 288

7.9 本章小結 / 289

第8章 微服務治理實踐指南 / 291

8.1 基礎設施治理 / 291

8.1.1 資源治理 / 291

8.1.2 運行環境治理 / 293

8.1.3 容量治理 / 294

8.1.4 安全治理 / 295

8.2 微服務基礎能力治理 / 295

8.2.1 服務註冊 / 295

8.2.2 服務發現 / 301

8.2.3 服務通信 / 304

8.2.4 負載均衡 / 305

8.3 微服務一般能力治理 / 305

8.3.1 服務鑒權 / 306

8.3.2 流量控制 / 308

8.3.3 服務路由 / 311

8.3.4 熔斷隔離 / 312

8.3.5 服務容錯 / 314

8.4 微服務高級能力治理 / 314

8.4.1 單元化 / 315

8.4.2 滾動更新 / 316

8.4.3 優雅下線 / 317

8.4.4 健康檢查 / 317

8.4.5 自動伸縮 / 318

8.4.6 故障注入 / 319

8.5 本章小結 / 320

第9章 微服務架構實踐指南 / 321

9.1 微服務應該如何開始 / 321

9.1.1 正確認識微服務 / 321

9.1.2 調整組織架構 / 323

9.1.3 充分授權 / 324

9.1.4 提升團隊技能 / 325

9.1.5 建設基礎設施 / 326

9.1.6 從試點開始 / 327

9.2 如何套用微服務 / 329

9.2.1 堅守原則 / 329

9.2.2 管理例外 / 330

9.2.3 避免過早拆分 / 332

9.2.4 建立開發環境 / 333

9.2.5 適時地償還“技術債務” / 335

9.2.6 信息隱藏 / 336

9.2.7 保持接口穩定 / 337

9.2.8 管理代碼所有權 / 338

9.2.9 內部開源 / 340

9.3 如何上線微服務 / 341

9.3.1 測試左移 / 341

9.3.2 自動化必不可少 / 344

9.3.3 擁抱雲原生 / 344

9.3.4 套用DevOps / 344

9.3.5 不斷提升系統的可觀測性 / 345

9.4 如何管理微服務 / 346

9.4.1 套用企業架構標準 / 346

9.4.2 安裝“架構師電梯” / 346

9.4.3 擁抱敏捷 / 347

9.4.4 建立服務看板 / 349

9.4.5 建立技術委員會 / 350

9.4.6 建立團隊分類機制 / 350

9.5 如何遷移單體套用 / 351

9.5.1 明確遷移的目的 / 352

9.5.2 評估是否可以遷移 / 352

9.5.3 不要忘記資料庫 / 353

9.5.4 逐步遷移的重要性 / 354

9.5.5 模式：模組化單體 / 354

9.5.6 模式：扼殺無花果 / 355

9.5.7 模式：根據抽象建立分支 / 356

9.5.8 模式：並行運行 / 357

9.5.9 模式：裝飾者 / 357

9.5.10 模式：扼殺資料庫 / 358

9.5.11 模式：數據視圖 / 359

9.5.12 模式：數據服務 / 359

9.5.13 模式：接口資料庫 / 360

9.5.14 模式：在套用中同步數據 / 360

9.6 常見問題解答 / 361

Q：什麼時候應該使用微服務 / 361

Q：微服務應該有多大 / 361

Q：從新系統還是舊系統開始 / 363

Q：前端如何處理 / 364

Q：先拆代碼還是先拆資料庫 / 365

Q：整體最佳化還是局部最佳化 / 365

Q：如何處理一致性 / 367

Q：該不該用分散式事務 / 368

Q：如何跨服務查詢 / 369

Q：是否應以服務復用為重 / 371

Q：是否應該購買微服務平台 / 371

Q：如何技術選型 / 372

Q：系統安全如何保障 / 373

Q：接口需要冪等設計嗎 / 373

Q：服務應該是無狀態的嗎 / 373

Q：異構系統如何管理 / 374

Q：如何管理服務集 / 374

9.7 本章小結 / 376

★★第4篇 企業雲原生變革

第10章 企業雲原生實踐指南 / 378

10.1 企業頭上的“雲” / 378

10.1.1 雲計算的定義 / 378

10.1.2 是否要上雲 / 380

10.1.3 一朵又一朵的“雲” / 383

10.1.4 企業多雲 / 386

10.2 混合雲的劃分方法 / 387

10.2.1 以前後端為界 / 387

10.2.2 以新舊程度為界 / 388

10.2.3 以關鍵程度為界 / 389

10.2.4 以生命周期為界 / 389

10.2.5 以數據類型為界 / 390

10.2.6 以數據新鮮度為界 / 390

10.2.7 以運營狀態為界 / 391

10.2.8 以工作負載為界 / 391

10.3 推動變革的“領導變革八步法” / 392

10.3.1 領導變革 / 392

10.3.2 建立緊迫感 / 393

10.3.3 建立領導團隊 / 395

10.3.4 設定願景戰略 / 397

10.3.5 溝通變革願景 / 399

10.3.6 善於授權賦能 / 401

10.3.7 積累短期勝利 / 402

10.3.8 促進變革深入 / 403

10.3.9 成果融入文化 / 403

10.4 企業雲原生成熟度模型 / 404

10.4.1 技術成熟度模型 / 405

10.4.2 組織成熟度模型 / 406

10.4.3 套用成熟度模型 / 406

10.4.4 微服務成熟度模型 / 407

10.5 效果收益評估方法 / 408

10.5.1 評估方法 / 409

10.5.2 設定檢查點 / 409

10.5.3 避免沉默成本 / 409

10.6 本章小結 / 410

結束語 / 411

作者簡介

樊超

從事Java應用程式開發和架構設計工作10餘年，曾擔任某上市公司首席架構師、某網際網路企業技術總監等職位。

擁有數項軟體開發相關發明專利，作為中國信息通信研究院聘用專家參與雲原生相關標準的編寫和審核。