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

樊超

  • 出版商: 電子工業
  • 出版日期: 2022-03-01
  • 售價: $714
  • 貴賓價: 9.5$678
  • 語言: 簡體中文
  • 頁數: 424
  • ISBN: 7121430169
  • ISBN-13: 9787121430169
  • 相關分類: Microservices 微服務SOA
  • 立即出貨

買這商品的人也買了...

商品描述

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