企業(yè)架構(gòu)與繞不開的微服務(wù)(雙色) 版權(quán)信息
- ISBN:9787121430169
- 條形碼:9787121430169 ; 978-7-121-43016-9
- 裝幀:一般膠版紙
- 冊數(shù):暫無
- 重量:暫無
- 所屬分類:>>
企業(yè)架構(gòu)與繞不開的微服務(wù)(雙色) 本書特色
融合了企業(yè)架構(gòu)和微服務(wù);含服務(wù)拆分方法、治理原則、*佳實踐在內(nèi)等細節(jié);尤其適合擁有大量IT資產(chǎn)的非互聯(lián)網(wǎng)企業(yè)中落地微服務(wù)。
不想想當架構(gòu)師的程序員,不是好程序員
企業(yè)架構(gòu)有哪些困境?
企業(yè)架構(gòu)有哪些反模式?
怎么樣才是是一個EA架構(gòu)師?
企業(yè)架構(gòu)的目標有哪些?
云原生能不能拯救企業(yè)架構(gòu)?
我真的需要微服務(wù)?
微服務(wù)怎么拆拆拆?
拆了又怎么治理?
應(yīng)以怎樣的姿勢擁抱云原生?
企業(yè)架構(gòu),不是學學工具就可以的理論知識對突破架構(gòu)師瓶頸真的很重要。
企業(yè)架構(gòu)與繞不開的微服務(wù)(雙色) 內(nèi)容簡介
本書分析了當今企業(yè)架構(gòu)面臨的挑戰(zhàn),介紹了如何使用微服務(wù)架構(gòu)來應(yīng)對這些挑戰(zhàn)。 企業(yè)在應(yīng)用微服務(wù)時面臨許多痛點,本書對痛點出現(xiàn)的原因和場景進行了深入的分析,提出了可用于消除或緩解痛點影響的模式。
本書內(nèi)容注重理論和實踐的結(jié)合。
- 在理論方面,介紹了企業(yè)架構(gòu)標準、云原生思想和相關(guān)技術(shù)、微服務(wù)的前世今生,以及領(lǐng)域驅(qū)動設(shè)計等;
- 在實踐方面,介紹了用于拆分微服務(wù)的“五步法”、包含4個維度的“企業(yè)云原生成熟度模型”,以及衡量企業(yè)變革成果的“效果收益評估方法”等。 本書的核心內(nèi)容包括:
- 企業(yè)架構(gòu)的定義與企業(yè)架構(gòu)師的職責;
- 企業(yè)架構(gòu)是否設(shè)計良好的評判依據(jù);
- 云原生的相關(guān)思想和技術(shù);
- 微服務(wù)的起源、演化、特性、拆分方法和落地指南;
- 云原生為企業(yè)帶來的機遇與變革等。 本書可以幫助企業(yè)明確痛點、制定原則、規(guī)劃路徑、建設(shè)能力和評估成效,*終實現(xiàn)微服務(wù)架構(gòu)在企業(yè)中的持續(xù)運營和持續(xù)演化,從而應(yīng)對日益增多的業(yè)務(wù)挑戰(zhàn)。
企業(yè)架構(gòu)與繞不開的微服務(wù)(雙色) 目錄
第1篇 企業(yè)中的架構(gòu)和架構(gòu)師
-
第1章 被輕視的企業(yè)架構(gòu) / 2
1.1 被濫用的架構(gòu) / 2
1.1.1 來源于建筑卻不同于建筑 / 2
1.1.2 難以統(tǒng)一的定義 / 3
1.1.3 架構(gòu)與架構(gòu)風格 / 4
1.2 常見的架構(gòu)風格 / 5
1.2.1 三層架構(gòu) / 5
1.2.2 SOA架構(gòu) / 8
1.2.3 單體架構(gòu) / 12
1.2.4 微服務(wù)架構(gòu) / 13
1.3 與眾不同的企業(yè)架構(gòu) / 14
1.3.1 更大的范圍 / 14
1.3.2 更大的風險 / 15
1.3.3 更大的收益 / 15
1.3.4 支撐企業(yè)數(shù)字化轉(zhuǎn)型 / 16
1.4 舉步維艱的企業(yè)架構(gòu) / 18
1.4.1 企業(yè)內(nèi)的重視程度不足 / 18
1.4.2 系統(tǒng)間的壁壘和代溝 / 20
1.4.3 簡單粗暴的集成方式 / 22
1.4.4 尷尬的IT部門 / 24
1.4.5 難以量化的生產(chǎn)力 / 26
1.4.6 快速變化的外部環(huán)境 / 27
1.5 企業(yè)架構(gòu)反模式 / 28
1.5.1 采用“雙速IT” / 28
1.5.2 視IT部門為成本中心 / 31
1.5.3 以為“買買買”可以解決一切問題 / 33
1.5.4 主數(shù)據(jù)管理與微服務(wù)思想矛盾 / 34
1.5.5 以技術(shù)驅(qū)動架構(gòu)設(shè)計 / 37
1.6 企業(yè)架構(gòu)標準來拯救 / 38
1.6.1 TOGAF簡介 / 39
1.6.2 首先要有愿景 / 42
1.6.3 一切都圍繞著需求 / 46
1.6.4 4種架構(gòu) / 48
1.6.5 架構(gòu)開發(fā)方法 / 50
1.6.6 遷移要被規(guī)劃 / 51
1.6.7 實施要被治理 / 54
1.6.8 變更要被管理 / 56
1.6.9 TOGAF的能力框架 / 59
1.6.10 企業(yè)架構(gòu)標準小結(jié) / 63
1.7 本章小結(jié) / 64
-
第2章 不一樣的EA架構(gòu)師 / 65
2.1 誰是架構(gòu)師? / 65
2.2 不一樣的EA架構(gòu)師 / 68
2.2.1 與建筑師不一樣 / 68
2.2.2 與技術(shù)架構(gòu)師不一樣 / 70
2.2.3 與業(yè)務(wù)架構(gòu)師不一樣 / 73
2.2.4 與敏捷架構(gòu)師不一樣 / 75
2.2.5 這才是EA架構(gòu)師 / 79
2.3 EA架構(gòu)師工作反模式 / 81
2.3.1 獨立的架構(gòu)組 / 82
2.3.2 中央集權(quán)和獨裁 / 86
2.3.3 以有“技術(shù)潔癖”為榮 / 89
2.3.4 妄想“技術(shù)改變世界” / 92
2.4 做好一個EA架構(gòu)師 / 94
2.4.1 成為漩渦的中心 / 95
2.4.2 成為導師:為他人轉(zhuǎn)身 / 98
2.4.3 搭上“架構(gòu)師電梯” / 102
2.5 本章小結(jié) / 107
-
第3章 企業(yè)架構(gòu)的目標 / 108
3.1 評估架構(gòu)的4個維度 / 108
3.2 為企業(yè)“松綁” / 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 讓系統(tǒng)變成“打不死的小強” / 139
3.4.4 自動化系統(tǒng)的韌性 / 142
3.5 生生不息地持續(xù)演化 / 143
3.6 本章小結(jié) / 145
-
第2篇 云原生來拯救
-
第4章 云原生 / 147
4.1 云原生的定義 / 147
4.1.1 云原生應(yīng)用 / 147
4.1.2 云原生技術(shù) / 148
4.1.3 云原生架構(gòu) / 148
4.2 云原生的代表技術(shù) / 149
4.2.1 新一代虛擬化技術(shù):容器 / 149
4.2.2 細粒度分布式架構(gòu):微服務(wù) / 150
4.2.3 第三代微服務(wù)架構(gòu):服務(wù)網(wǎng)格 / 151
4.2.4 只能重建不能修改:不可變基礎(chǔ)設(shè)施 / 152
4.2.5 關(guān)注目的而非過程:聲明式API / 154
4.3 再談容器 / 156
4.3.1 容器 VS 虛擬機 / 156
4.3.2 容器與鏡像 / 157
4.3.3 容器編排技術(shù) / 159
4.3.4 容器與微服務(wù) / 161
4.4 再談服務(wù)網(wǎng)格 / 161
4.4.1 服務(wù)網(wǎng)格的實現(xiàn) / 161
4.4.2 與API網(wǎng)關(guān)的關(guān)系 / 163
4.4.3 服務(wù)網(wǎng)格與微服務(wù) / 165
4.4.4 適用場景 / 167
4.4.5 不適用場景 / 168
4.5 云原生技術(shù)改變企業(yè)架構(gòu) / 169
4.5.1 云原生技術(shù)帶來的改變 / 169
4.5.2 新的架構(gòu)原則 / 172
4.5.3 新的架構(gòu)模式 / 173
4.6 云原生架構(gòu)的評判標準 / 176
4.6.1 是否符合“12因素” / 176
4.6.2 是否使用了微服務(wù)架構(gòu) / 182
4.6.3 是否使用了DevOps / 184
4.7 不是“銀彈”,也不免費 / 186
4.7.1 終極架構(gòu)謬誤 / 186
4.7.2 比想象中更高的成本 / 187
4.8 本章小結(jié) / 190
-
第3篇 云原生的核心:微服務(wù)
-
第5章 微服務(wù)的前世今生 / 192
5.1 前世與今生 / 192
5.2 從單體到微服務(wù) / 193
5.2.1 微服務(wù)的反面:單體 / 193
5.2.2 微服務(wù)的前世:SOA / 195
5.2.3 微服務(wù)架構(gòu)的定義 / 195
5.3 微服務(wù)架構(gòu)原則 / 197
5.3.1 業(yè)務(wù)驅(qū)動原則 / 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 技術(shù)無關(guān)原則 / 202
5.4 解讀微服務(wù)架構(gòu)九大特性 / 202
5.4.1 組件化與多服務(wù) / 203
5.4.2 圍繞業(yè)務(wù)功能組織團隊 / 204
5.4.3 做產(chǎn)品而不是做項目 / 205
5.4.4 智能端點與傻瓜通道 / 206
5.4.5 去中心化的治理技術(shù) / 207
5.4.6 去中心化的數(shù)據(jù)管理 / 209
5.4.7 基礎(chǔ)設(shè)施自動化 / 209
5.4.8 容錯設(shè)計 / 210
5.4.9 演化式設(shè)計 / 211
5.5 原則和特性帶來的優(yōu)勢 / 212
5.5.1 組件可由不同技術(shù)棧實現(xiàn) / 213
5.5.2 細粒度地按需擴縮容 / 213
5.5.3 局部不可用不會拖累整體 / 214
5.5.4 縮短功能面試時間 / 214
5.5.5 適合大規(guī)模團隊并行工作 / 215
5.5.6 一個服務(wù)可支持多種終端 / 215
5.5.7 服務(wù)可由開發(fā)團隊自治 / 216
5.6 微服務(wù)架構(gòu)不是“銀彈” / 216
5.6.1 開發(fā)、部署、運維困難 / 216
5.6.2 存在網(wǎng)絡(luò)延遲 / 219
5.6.3 相比單體架構(gòu)更加脆弱 / 220
5.6.4 可能出現(xiàn)“孤兒服務(wù)” / 220
5.6.5 可被黑客攻擊的點多 / 221
5.7 在這些時候請不要使用微服務(wù) / 222
5.7.1 無法忍受增加的成本 / 222
5.7.2 無法忍受架構(gòu)復(fù)雜度 / 224
5.7.3 無法忍受網(wǎng)絡(luò)延遲 / 225
5.7.4 無法建立有效的基礎(chǔ)設(shè)施 / 225
5.7.5 需要強事務(wù)一致性 / 226
5.7.6 需要頻繁變更接口 / 226
5.7.7 團隊規(guī)模較小 / 227
5.7.8 初創(chuàng)團隊 / 228
5.7.9 缺乏業(yè)務(wù)知識 / 228
5.7.10 由客戶自行安裝和管理的軟件 / 229
5.8 本章小結(jié) / 229
-
第6章 領(lǐng)域驅(qū)動設(shè)計與微服務(wù)拆分 / 231
6.1 DDD可以用于微服務(wù)拆分嗎 / 231
6.2 拆分中必用的領(lǐng)域概念 / 233
6.2.1 有效溝通模式:統(tǒng)一語言 / 233
6.2.2 要溝通的對象:實體 / 234
6.2.3 粗粒度的拆分:子域 / 236
6.2.4 中粒度的拆分:限界上下文 / 238
6.2.5 細粒度的拆分:聚合 / 240
6.2.6 避免循環(huán)依賴:限界上下文映射圖 / 243
6.3 拆分中可用的領(lǐng)域概念 / 244
6.3.1 交互模式 / 244
6.3.2 模塊單體的基礎(chǔ):模塊 / 246
6.4 拆分中不用的領(lǐng)域概念 / 247
6.4.1 指導編碼的值對象 / 247
6.4.2 與微服務(wù)中的“服務(wù)”不同含義的“服務(wù)” / 248
6.5 拆分中可用的設(shè)計模式 / 249
6.5.1 分層架構(gòu) / 249
6.5.2 六邊形架構(gòu) / 250
6.5.3 柔性設(shè)計 / 252
6.6 再談DDD中的邊界 / 252
6.7 本章小結(jié) / 253
-
第7章 微服務(wù)拆分方法 / 254
7.1 領(lǐng)域分析法 / 254
7.1.1 四色建模法 / 255
7.1.2 四色建模法拆分步驟 / 255
7.1.3 事件風暴法 / 256
7.1.4 事件風暴法拆分步驟 / 256
7.1.5 領(lǐng)域分析法的不足 / 257
7.2 筆者總結(jié)的微服務(wù)拆分五步法 / 258
7.3 **步:預(yù)備 / 258
7.3.1 組建架構(gòu)開發(fā)團隊 / 259
7.3.2 評估企業(yè)能力成熟度 / 259
7.3.3 界定架構(gòu)范圍及識別相關(guān)方 / 260
7.3.4 識別和定義架構(gòu)原則 / 261
7.4 第二步:開發(fā)業(yè)務(wù)架構(gòu) / 262
7.4.1 粗粒度地拆分業(yè)務(wù)子域 / 262
7.4.2 選擇一個核心子域并遍歷其中的場景 / 263
7.4.3 分析每個場景中的用例 / 264
7.4.4 為不同的視角建立相應(yīng)的視圖 / 266
7.5 第三步:領(lǐng)域分析 / 266
7.5.1 識別領(lǐng)域事件 / 267
7.5.2 識別決策命令 / 268
7.5.3 識別領(lǐng)域名詞 / 268
7.5.4 根據(jù)領(lǐng)域名詞識別聚合 / 268
7.5.5 拆分限界上下文 / 268
7.6 第四步:開發(fā)非業(yè)務(wù)架構(gòu) / 269
7.6.1 開發(fā)數(shù)據(jù)架構(gòu) / 269
7.6.2 開發(fā)應(yīng)用架構(gòu) / 270
7.6.3 開發(fā)技術(shù)架構(gòu) / 270
7.7 第五步:用非業(yè)務(wù)架構(gòu)審查拆分結(jié)果 / 270
7.7.1 消除循環(huán)依賴 / 271
7.7.2 審查是否滿足非業(yè)務(wù)架構(gòu) / 271
7.8 案例及內(nèi)容模板 / 272
7.8.1 案例背景介紹 / 272
7.8.2 案例拆分**步:預(yù)備 / 272
7.8.3 案例拆分第二步:開發(fā)業(yè)務(wù)架構(gòu) / 276
7.8.4 案例拆分第三步:領(lǐng)域分析 / 281
7.8.5 案例拆分第四步:開發(fā)非業(yè)務(wù)架構(gòu) / 285
7.8.6 案例拆分第五步:用非業(yè)務(wù)架構(gòu)審查拆分結(jié)果 / 286
7.8.7 案例小結(jié) / 288
7.9 本章小結(jié) / 289
-
第8章 微服務(wù)治理實踐指南 / 291
8.1 基礎(chǔ)設(shè)施治理 / 291
8.1.1 資源治理 / 291
8.1.2 運行環(huán)境治理 / 293
8.1.3 容量治理 / 294
8.1.4 安全治理 / 295
8.2 微服務(wù)基礎(chǔ)能力治理 / 295
8.2.1 服務(wù)注冊 / 295
8.2.2 服務(wù)發(fā)現(xiàn) / 301
8.2.3 服務(wù)通信 / 304
8.2.4 負載均衡 / 305
8.3 微服務(wù)一般能力治理 / 305
8.3.1 服務(wù)鑒權(quán) / 306
8.3.2 流量控制 / 308
8.3.3 服務(wù)路由 / 311
8.3.4 熔斷隔離 / 312
8.3.5 服務(wù)容錯 / 314
8.4 微服務(wù)高級能力治理 / 314
8.4.1 單元化 / 315
8.4.2 滾動更新 / 316
8.4.3 優(yōu)雅下線 / 317
8.4.4 健康檢查 / 317
8.4.5 自動伸縮 / 318
8.4.6 故障注入 / 319
8.5 本章小結(jié) / 320
-
第9章 微服務(wù)架構(gòu)實踐指南 / 321
9.1 微服務(wù)應(yīng)該如何開始 / 321
9.1.1 正確認識微服務(wù) / 321
9.1.2 調(diào)整組織架構(gòu) / 323
9.1.3 充分授權(quán) / 324
9.1.4 提升團隊技能 / 325
9.1.5 建設(shè)基礎(chǔ)設(shè)施 / 326
9.1.6 從試點開始 / 327
9.2 如何應(yīng)用微服務(wù) / 329
9.2.1 堅守原則 / 329
9.2.2 管理例外 / 330
9.2.3 避免過早拆分 / 332
9.2.4 建立開發(fā)環(huán)境 / 333
9.2.5 適時地償還“技術(shù)債務(wù)” / 335
9.2.6 信息隱藏 / 336
9.2.7 保持接口穩(wěn)定 / 337
9.2.8 管理代碼所有權(quán) / 338
9.2.9 內(nèi)部開源 / 340
9.3 如何上線微服務(wù) / 341
9.3.1 測試左移 / 341
9.3.2 自動化必不可少 / 344
9.3.3 擁抱云原生 / 344
9.3.4 應(yīng)用DevOps / 344
9.3.5 不斷提升系統(tǒng)的可觀測性 / 345
9.4 如何管理微服務(wù) / 346
9.4.1 應(yīng)用企業(yè)架構(gòu)標準 / 346
9.4.2 安裝“架構(gòu)師電梯” / 346
9.4.3 擁抱敏捷 / 347
9.4.4 建立服務(wù)看板 / 349
9.4.5 建立技術(shù)委員會 / 350
9.4.6 建立團隊分類機制 / 350
9.5 如何遷移單體應(yīng)用 / 351
9.5.1 明確遷移的目的 / 352
9.5.2 評估是否可以遷移 / 352
9.5.3 不要忘記數(shù)據(jù)庫 / 353
9.5.4 逐步遷移的重要性 / 354
9.5.5 模式:模塊化單體 / 354
9.5.6 模式:扼殺無花果 / 355
9.5.7 模式:根據(jù)抽象建立分支 / 356
9.5.8 模式:并行運行 / 357
9.5.9 模式:裝飾者 / 357
9.5.10 模式:扼殺數(shù)據(jù)庫 / 358
9.5.11 模式:數(shù)據(jù)視圖 / 359
9.5.12 模式:數(shù)據(jù)服務(wù) / 359
9.5.13 模式:接口數(shù)據(jù)庫 / 360
9.5.14 模式:在應(yīng)用中同步數(shù)據(jù) / 360
9.6 常見問題解答 / 361
Q:什么時候應(yīng)該使用微服務(wù) / 361
Q:微服務(wù)應(yīng)該有多大 / 361
Q:從新系統(tǒng)還是舊系統(tǒng)開始 / 363
Q:前端如何處理 / 364
Q:先拆代碼還是先拆數(shù)據(jù)庫 / 365
Q:整體優(yōu)化還是局部優(yōu)化 / 365
Q:如何處理一致性 / 367
Q:該不該用分布式事務(wù) / 368
Q:如何跨服務(wù)查詢 / 369
Q:是否應(yīng)以服務(wù)復(fù)用為重 / 371
Q:是否應(yīng)該購買微服務(wù)平臺 / 371
Q:如何技術(shù)選型 / 372
Q:系統(tǒng)安全如何保障 / 373
Q:接口需要冪等設(shè)計嗎 / 373
Q:服務(wù)應(yīng)該是無狀態(tài)的嗎 / 373
Q:異構(gòu)系統(tǒng)如何管理 / 374
Q:如何管理服務(wù)集 / 374
9.7 本章小結(jié) / 376
-
第4篇 企業(yè)云原生變革
-
第10章 企業(yè)云原生實踐指南 / 378
10.1 企業(yè)頭上的“云” / 378
10.1.1 云計算的定義 / 378
10.1.2 是否要上云 / 380
10.1.3 一朵又一朵的“云” / 383
10.1.4 企業(yè)多云 / 386
10.2 混合云的劃分方法 / 387
10.2.1 以前后端為界 / 387
10.2.2 以新舊程度為界 / 388
10.2.3 以關(guān)鍵程度為界 / 389
10.2.4 以生命周期為界 / 389
10.2.5 以數(shù)據(jù)類型為界 / 390
10.2.6 以數(shù)據(jù)新鮮度為界 / 390
10.2.7 以運營狀態(tài)為界 / 391
10.2.8 以工作負載為界 / 391
10.3 推動變革的“領(lǐng)導變革八步法” / 392
10.3.1 領(lǐng)導變革 / 392
10.3.2 建立緊迫感 / 393
10.3.3 建立領(lǐng)導團隊 / 395
10.3.4 設(shè)定愿景戰(zhàn)略 / 397
10.3.5 溝通變革愿景 / 399
10.3.6 善于授權(quán)賦能 / 401
10.3.7 積累短期勝利 / 402
10.3.8 促進變革深入 / 403
10.3.9 成果融入文化 / 403
10.4 企業(yè)云原生成熟度模型 / 404
10.4.1 技術(shù)成熟度模型 / 405
10.4.2 組織成熟度模型 / 406
10.4.3 應(yīng)用成熟度模型 / 406
10.4.4 微服務(wù)成熟度模型 / 407
10.5 效果收益評估方法 / 409
10.5.1 評估方法 / 409
10.5.2 設(shè)置檢查點 / 409
10.5.3 避免沉默成本 / 410
10.6 本章小結(jié) / 410
展開全部
企業(yè)架構(gòu)與繞不開的微服務(wù)(雙色) 作者簡介
樊超
微服務(wù)架構(gòu)師
從事軟件研發(fā)和架構(gòu)設(shè)計十余年
被中國信息通信研究院聘為可信云標準專家參與編寫了《微服務(wù)拆分規(guī)范指南》《云原生成熟度模型》《微服務(wù)應(yīng)用架構(gòu)白皮書》等多個行業(yè)規(guī)范和標準
作為評審專家參與了多個大型企業(yè)架構(gòu)的評級工作