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

★第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