企業架構與繞不開的微服務

購買商店

---

企業架構與繞不開的微服務

$714.00

馬上購買

---

內容描述

---

本書分析了當今企業架構面臨的挑戰，介紹瞭如何使用微服務架構來應對這些挑戰。企業在應用微服務時面臨許多痛點，本書對痛點出現的原因和場景進行了深入的分析，提出了可用於消除或緩解痛點影響的模式。 本書內容註重理論和實踐的結合。在理論方面，介紹了企業架構標準、雲原生思想和相關技術、微服務的前世今生，以及領域驅動設計等；在實踐方面，介紹了用於拆分微服務的“五步法”、包含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

---