掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
重構到微服務 版權信息
- ISBN：9787519879501
- 條形碼：9787519879501 ; 978-7-5198-7950-1
- 裝幀：平裝-膠訂
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
重構到微服務 本書特色
一句話推薦
單體遺留系統的現代化演進之道。本書旨在從思考和執行的維度，深入探討如何將現有系統分解為微服務架構。
編輯推薦
對于單體系統，你是如何來進行梳理并且逐步將它演進到微服務架構的呢？你是如何在保證業務正常進行的同時來做這件事的？作為其暢銷著作《Building Microservices》的姊妹篇，這本書詳細闡釋了一種從存量的單體應用遷移到微服務架構的可行方法。
本書作為一本改造指南，提供了大量針對如何將單體應用演進到微服務架構的實操建議。書中包含了大量圖形化的示例、充滿洞見的改造模式、涉及從改造的初始規劃階段到應用系統和數據庫的解耦，涵蓋了許多場景和策略，它們將幫助你實現成功的改造。你將從本書中學到這些經過實踐檢驗過的模式和技巧。在改造過程，你一定會發現它們非常有價值。
專家推薦
“在這本書中，本書作者為微服務改造定義了清晰的愿景，并且向你展示了在改造過程中需要注意哪些‘坑’（既有很明顯的，也有一些比較隱蔽的）。同時，本書也提供了很多組織革新、架構革新、技術革新方面非常有用的參考模式。”
——Daniel Bryant
DataWire和InfoQ的技術顧問
重構到微服務 內容簡介
本書作為一本改造指南，提供了大量針對如何將單體應用演進到微服務架構的實操建議。書中包含了大量圖形化的示例、充滿洞見的改造模式、涉及從改造的初始規劃階段到應用系統和數據庫的解耦，涵蓋了許多場景和策略，它們將幫助你實現成功的改造。你將從本書中學到這些經過實踐檢驗過的模式和技巧。在改造過程，你一定會發現它們非常有價值。本書的主要內容有：適合于期望演進到微服務，而不是重寫的組織。幫助組織決策是否要改造、何時改造、以及從哪里入手進行改造。如何解決遺留系統的通信、集成和遷移問題。闡述了若干不同的遷移模式，以及在什么情況下采用這些模式。提供了多種數據庫遷移方法的案例，以及對應的同步機制。探索了應用系統解耦的方法，包括若干架構重構的模式。深入探討了數據庫解耦的細節，包括打破參照完整性和事務完整性的影響，新的失敗模式等。
重構到微服務 目錄
目錄
前言 1
第1 章 剛剛好的微服務 7
1.1 什么是微服務？ 7
1.1.1 部署獨立性 8
1.1.2 圍繞業務領域建模 8
1.1.3 擁有自己的數據 12
1.1.4 微服務將帶來哪些優勢？ 13
1.1.5 微服務會帶來什么問題？ 13
1.1.6 用戶界面 .14
1.1.7 技術 14
1.1.8 顆粒度 15
1.1.9 所有權 17
1.2 單體架構19
1.2.1 單進程單體 19
1.2.2 分布式單體 21
1.2.3 第三方黑盒系統 22
1.2.4 單體架構的挑戰 22
1.2.5 單體的優勢 22
1.3 關于耦合和內聚 23
1.3.1 內聚 25
1.3.2 耦合 25
1.4 剛剛好的領域驅動設計 .36
1.4.1 聚合 37
1.4.2 限界上下文 38
1.4.3 將聚合和限界上下文映射到微服務 39
1.4.4 延伸閱讀 .39
1.5 總結 .40
第2 章 規劃遷移到微服務的過程 41
2.1 理解目標41
2.2 為什么要選擇微服務？ .43
2.2.1 提高團隊自主性 44
2.2.2 縮短上市時間 45
2.2.3 經濟高效地擴展負載.46
2.2.4 提高健壯性 47
2.2.5 擴展開發人員的數量.48
2.2.6 擁抱新技術 49
2.3 什么時候微服務可能是個壞主意？.51
2.3.1 不明確的業務領域 .51
2.3.2 初創公司 .52
2.3.3 客戶安裝和管理的軟件 54
2.3.4 沒有好的理由！ 54
2.4 權衡利弊54
2.5 帶人踏上旅途 .56
2.6 改變組織56
2.6.1 建立緊迫感 57
2.6.2 組建領導團隊 58
2.6.3 制定愿景和戰略 59
2.6.4 傳達變革愿景 59
2.6.5 善于授權賦能 60
2.6.6 快速得到成果 61
2.6.7 促進變革深入 61
2.6.8 成果融入文化 62
2.7 增量遷移的重要性 62
2.8 變更成本64
2.8.1 可逆和不可逆的決定.64
2.8.2 更容易實驗的地方 .66
2.9 那么我們從哪里開始呢？ 66
2.10 領域驅動設計 66
2.10.1 你需要走多遠？ 67
2.10.2 事件風暴 68
2.10.3 利用領域模型進行優先級排序 68
2.11 一個組合模型 70
2.12 重組團隊 .72
2.12.1 改變團隊結構 .72
2.12.2 不要一刀切73
2.12.3 做出改變 75
2.12.4 改變技能 78
2.13 你如何知道轉型成功與否？ .81
2.13.1 有定期檢查點 .81
2.13.2 定量度量 82
2.13.3 定性度量 82
2.13.4 避免沉沒成本誤區 83
2.13.5 對新方法持開放態度 83
2.14 總結 84
第3 章 拆分單體 87
3.1 單體系統，修改還是不修改？ 87
3.1.1 剪切、復制或者重新開發？ .88
3.1.2 重構單體系統 89
3.2 遷移模式90
3.3 模式：絞殺應用 91
3.3.1 它是如何工作的 91
3.3.2 在哪里使用它 93
3.3.3 示例：HTTP 反向代理 .95
3.3.4 數據 98
3.3.5 代理選項 .98
3.3.6 更改協議 102
3.3.7 示例：FTP 105
3.3.8 示例：消息攔截 106
3.3.9 其他協議 109
3.3.10 絞殺植物模式的其他例子 . 109
3.4 遷移功能時改變行為 110
3.5 模式：UI 組合 . 110
3.5.1 示例：頁面組合 111
3.5.2 示例：小部件（Widget）組合 112
3.5.3 示例：微前端 . 115
3.5.4 在哪里使用它 . 116
3.6 模式：抽象分支 . 116
3.6.1 它是如何工作的 117
3.6.2 作為后備機制 . 124
3.6.3 在哪里使用它 . 125
3.7 模式：并行運行 . 126
3.7.1 示例：比較信用衍生品定價 126
3.7.2 示例：Homegate 列表 128
3.7.3 驗證技術 129
3.7.4 使用Spy 129
3.7.5 GitHub Scientist 130
3.7.6 灰度發布與金絲雀發布 . 131
3.7.7 在哪里使用它 . 131
3.8 模式：裝飾合作者 . 131
3.8.1 示例：會員計劃 132
3.8.2 在哪里使用它 . 133
3.9 模式：變更數據捕獲 133
3.9.1 示例：發行會員卡 133
3.9.2 實現變更數據捕獲 135
3.9.3 在哪里使用它 . 137
3.10 總結 138
第4 章 分解數據庫 139
4.1 模式：共享數據庫 . 139
4.1.1 應對模式 141
4.1.2 何處使用 141
4.2 但這是不可能做到的! . 141
4.3 模式：數據庫視圖 . 143
4.3.1 數據庫即公共契約 143
4.3.2 通過視圖來對外展現 144
4.3.3 限制條件 145
4.3.4 所有權 146
4.3.5 何處使用 146
4.4 模式：數據庫包裝服務 146
4.5 模式：數據庫即服務接口 . 149
4.5.1 實現映射引擎 . 151
4.5.2 與視圖相比 . 151
4.5.3 何處使用 151
4.6 轉讓所有權 152
4.6.1 模式：暴露單體中的聚合 152
4.6.2 模式：變更數據所有權 . 155
4.7 數據同步. 156
4.8 模式：在應用程序中同步數據 158
4.8.1 步驟1：批量同步數據 158
4.8.2 步驟2：同步寫入，從舊表結構中讀取 159
4.8.3 步驟3：同步寫入，從新表結構中讀取 160
4.8.4 在哪里使用它（一） 161
4.8.5 在哪里使用它（二） 161
4.9 模式：追蹤器寫入 . 162
4.9.1 數據同步 165
4.9.2 案例：Square 的訂單 . 167
4.9.3 在哪里使用它 . 171
4.10 拆分數據庫 . 171
4.11 先拆分數據庫，還是先拆分代碼？ 173
4.11.1 先拆分數據庫 174
4.11.2 先拆分代碼 178
4.11.3 將數據庫和代碼一起拆分 .183
4.11.4 那么，我應該先拆分哪個？ .184
4.12 表結構拆分示例 184
4.13 模式：拆分表 184
4.14 模式：將外鍵關系移動到代碼中 187
4.14.1 移動連表查詢 188
4.14.2 數據一致性 190
4.14.3 在哪里使用 192
4.14.4 示例：共享靜態數據 192
4.15 事務 201
4.15.1 ACID 事務 .202
4.15.2 仍然保持ACID，但缺乏整體的原子性？ 203
4.15.3 兩階段提交 205
4.15.4 對分布式事務說不 207
4.16 saga . 208
4.16.1 saga 的失敗模式 . 209
4.16.2 實施saga 213
4.16.3 saga 與分布式事務 220
4.17 總結 220
第5 章 成長的煩惱 223
5.1 服務越多，痛苦越多 223
5.2 規；碌乃袡 . 225
5.2.1 這個問題如何表現出來？ 225
5.2.2 這個問題什么時候會發生？ 226
5.2.3 潛在的解決方案 226
5.3 破壞性變更 227
5.3.1 這個問題如何表現出來？ 227
5.3.2 這個問題什么時候會發生？ 227
5.3.3 潛在的解決方案 228
5.4 報表 231
5.4.1 這個問題什么時候會發生？ 232
5.4.2 潛在的解決方案 . 233
5.5 監控和故障排除 . 234
5.5.1 什么時候會出現這些問題？ 234
5.5.2 這些問題是如何發生的？ . 235
5.5.3 潛在的解決方案 . 235
5.6 本地開發者體驗 . 239
5.6.1 這個問題如何表現出來？ 239
5.6.2 什么時候會出現這些問題？ 239
5.6.3 潛在的解決方案 240
5.7 運行太多東西 240
5.7.1 這個問題如何表現出來？ 241
5.7.2 這個問題什么時候會發生？ 241
5.7.3 潛在的解決方案 241
5.8 端到端測試 242
5.8.1 這個問題如何表現出來？ 243
5.8.2 這個問題什么時候會發生？ 243
5.8.3 潛在的解決方案 243
5.9 全局與局部優化 . 245
5.9.1 這個問題如何表現出來？ 246
5.9.2 這個問題什么時候會發生？ 246
5.9.3 潛在的解決方案 247
5.10 健壯性和彈性 248
5.10.1 這個問題如何表現出來？ . 248
5.10.2 這個問題什么時候會發生？ 249
5.10.3 潛在的解決方案 . 249
5.11 孤兒服務 250
5.11.1 這個問題如何表現出來？ .250
5.11.2 這個問題什么時候會發生？ .250
5.11.3 潛在的解決方案 .251
5.12 總結 252
第6 章 結語 . 255
附錄A 參考書目 . 257
附錄B 模式列表 . 261
前言 1
第1 章 剛剛好的微服務 7
1.1 什么是微服務？ 7
1.1.1 部署獨立性 8
1.1.2 圍繞業務領域建模 8
1.1.3 擁有自己的數據 12
1.1.4 微服務將帶來哪些優勢？ 13
1.1.5 微服務會帶來什么問題？ 13
1.1.6 用戶界面 .14
1.1.7 技術 14
1.1.8 顆粒度 15
1.1.9 所有權 17
1.2 單體架構19
1.2.1 單進程單體 19
1.2.2 分布式單體 21
1.2.3 第三方黑盒系統 22
1.2.4 單體架構的挑戰 22
1.2.5 單體的優勢 22
1.3 關于耦合和內聚 23
1.3.1 內聚 25
1.3.2 耦合 25
1.4 剛剛好的領域驅動設計 .36
1.4.1 聚合 37
1.4.2 限界上下文 38
1.4.3 將聚合和限界上下文映射到微服務 39
1.4.4 延伸閱讀 .39
1.5 總結 .40
第2 章 規劃遷移到微服務的過程 41
2.1 理解目標41
2.2 為什么要選擇微服務？ .43
2.2.1 提高團隊自主性 44
2.2.2 縮短上市時間 45
2.2.3 經濟高效地擴展負載.46
2.2.4 提高健壯性 47
2.2.5 擴展開發人員的數量.48
2.2.6 擁抱新技術 49
2.3 什么時候微服務可能是個壞主意？.51
2.3.1 不明確的業務領域 .51
2.3.2 初創公司 .52
2.3.3 客戶安裝和管理的軟件 54
2.3.4 沒有好的理由！ 54
2.4 權衡利弊54
2.5 帶人踏上旅途 .56
2.6 改變組織56
2.6.1 建立緊迫感 57
2.6.2 組建領導團隊 58
2.6.3 制定愿景和戰略 59
2.6.4 傳達變革愿景 59
2.6.5 善于授權賦能 60
2.6.6 快速得到成果 61
2.6.7 促進變革深入 61
2.6.8 成果融入文化 62
2.7 增量遷移的重要性 62
2.8 變更成本64
2.8.1 可逆和不可逆的決定.64
2.8.2 更容易實驗的地方 .66
2.9 那么我們從哪里開始呢？ 66
2.10 領域驅動設計 66
2.10.1 你需要走多遠？ 67
2.10.2 事件風暴 68
2.10.3 利用領域模型進行優先級排序 68
2.11 一個組合模型 70
2.12 重組團隊 .72
2.12.1 改變團隊結構 .72
2.12.2 不要一刀切73
2.12.3 做出改變 75
2.12.4 改變技能 78
2.13 你如何知道轉型成功與否？ .81
2.13.1 有定期檢查點 .81
2.13.2 定量度量 82
2.13.3 定性度量 82
2.13.4 避免沉沒成本誤區 83
2.13.5 對新方法持開放態度 83
2.14 總結 84
第3 章 拆分單體 87
3.1 單體系統，修改還是不修改？ 87
3.1.1 剪切、復制或者重新開發？ .88
3.1.2 重構單體系統 89
3.2 遷移模式90
3.3 模式：絞殺應用 91
3.3.1 它是如何工作的 91
3.3.2 在哪里使用它 93
3.3.3 示例：HTTP 反向代理 .95
3.3.4 數據 98
3.3.5 代理選項 .98
3.3.6 更改協議 102
3.3.7 示例：FTP 105
3.3.8 示例：消息攔截 106
3.3.9 其他協議 109
3.3.10 絞殺植物模式的其他例子 . 109
3.4 遷移功能時改變行為 110
3.5 模式：UI 組合 . 110
3.5.1 示例：頁面組合 111
3.5.2 示例：小部件（Widget）組合 112
3.5.3 示例：微前端 . 115
3.5.4 在哪里使用它 . 116
3.6 模式：抽象分支 . 116
3.6.1 它是如何工作的 117
3.6.2 作為后備機制 . 124
3.6.3 在哪里使用它 . 125
3.7 模式：并行運行 . 126
3.7.1 示例：比較信用衍生品定價 126
3.7.2 示例：Homegate 列表 128
3.7.3 驗證技術 129
3.7.4 使用Spy 129
3.7.5 GitHub Scientist 130
3.7.6 灰度發布與金絲雀發布 . 131
3.7.7 在哪里使用它 . 131
3.8 模式：裝飾合作者 . 131
3.8.1 示例：會員計劃 132
3.8.2 在哪里使用它 . 133
3.9 模式：變更數據捕獲 133
3.9.1 示例：發行會員卡 133
3.9.2 實現變更數據捕獲 135
3.9.3 在哪里使用它 . 137
3.10 總結 138
第4 章 分解數據庫 139
4.1 模式：共享數據庫 . 139
4.1.1 應對模式 141
4.1.2 何處使用 141
4.2 但這是不可能做到的! . 141
4.3 模式：數據庫視圖 . 143
4.3.1 數據庫即公共契約 143
4.3.2 通過視圖來對外展現 144
4.3.3 限制條件 145
4.3.4 所有權 146
4.3.5 何處使用 146
4.4 模式：數據庫包裝服務 146
4.5 模式：數據庫即服務接口 . 149
4.5.1 實現映射引擎 . 151
4.5.2 與視圖相比 . 151
4.5.3 何處使用 151
4.6 轉讓所有權 152
4.6.1 模式：暴露單體中的聚合 152
4.6.2 模式：變更數據所有權 . 155
4.7 數據同步. 156
4.8 模式：在應用程序中同步數據 158
4.8.1 步驟1：批量同步數據 158
4.8.2 步驟2：同步寫入，從舊表結構中讀取 159
4.8.3 步驟3：同步寫入，從新表結構中讀取 160
4.8.4 在哪里使用它（一） 161
4.8.5 在哪里使用它（二） 161
4.9 模式：追蹤器寫入 . 162
4.9.1 數據同步 165
4.9.2 案例：Square 的訂單 . 167
4.9.3 在哪里使用它 . 171
4.10 拆分數據庫 . 171
4.11 先拆分數據庫，還是先拆分代碼？ 173
4.11.1 先拆分數據庫 174
4.11.2 先拆分代碼 178
4.11.3 將數據庫和代碼一起拆分 .183
4.11.4 那么，我應該先拆分哪個？ .184
4.12 表結構拆分示例 184
4.13 模式：拆分表 184
4.14 模式：將外鍵關系移動到代碼中 187
4.14.1 移動連表查詢 188
4.14.2 數據一致性 190
4.14.3 在哪里使用 192
4.14.4 示例：共享靜態數據 192
4.15 事務 201
4.15.1 ACID 事務 .202
4.15.2 仍然保持ACID，但缺乏整體的原子性？ 203
4.15.3 兩階段提交 205
4.15.4 對分布式事務說不 207
4.16 saga . 208
4.16.1 saga 的失敗模式 . 209
4.16.2 實施saga 213
4.16.3 saga 與分布式事務 220
4.17 總結 220
第5 章 成長的煩惱 223
5.1 服務越多，痛苦越多 223
5.2 規；碌乃袡 . 225
5.2.1 這個問題如何表現出來？ 225
5.2.2 這個問題什么時候會發生？ 226
5.2.3 潛在的解決方案 226
5.3 破壞性變更 227
5.3.1 這個問題如何表現出來？ 227
5.3.2 這個問題什么時候會發生？ 227
5.3.3 潛在的解決方案 228
5.4 報表 231
5.4.1 這個問題什么時候會發生？ 232
5.4.2 潛在的解決方案 . 233
5.5 監控和故障排除 . 234
5.5.1 什么時候會出現這些問題？ 234
5.5.2 這些問題是如何發生的？ . 235
5.5.3 潛在的解決方案 . 235
5.6 本地開發者體驗 . 239
5.6.1 這個問題如何表現出來？ 239
5.6.2 什么時候會出現這些問題？ 239
5.6.3 潛在的解決方案 240
5.7 運行太多東西 240
5.7.1 這個問題如何表現出來？ 241
5.7.2 這個問題什么時候會發生？ 241
5.7.3 潛在的解決方案 241
5.8 端到端測試 242
5.8.1 這個問題如何表現出來？ 243
5.8.2 這個問題什么時候會發生？ 243
5.8.3 潛在的解決方案 243
5.9 全局與局部優化 . 245
5.9.1 這個問題如何表現出來？ 246
5.9.2 這個問題什么時候會發生？ 246
5.9.3 潛在的解決方案 247
5.10 健壯性和彈性 248
5.10.1 這個問題如何表現出來？ . 248
5.10.2 這個問題什么時候會發生？ 249
5.10.3 潛在的解決方案 . 249
5.11 孤兒服務 250
5.11.1 這個問題如何表現出來？ .250
5.11.2 這個問題什么時候會發生？ .250
5.11.3 潛在的解決方案 .251
5.12 總結 252
第6 章 結語 . 255
附錄A 參考書目 . 257
附錄B 模式列表 . 261
展開全部
重構到微服務 作者簡介
作者介紹經歷了幾個創業公司，并在Thoughtworks工作了12年之后，目前Sam Newman是一位獨立顧問。他專注于微服務、云技術、以及持續交付方面。通過培訓和技術咨詢服務，Sam幫助分布在全球的客戶實現更快且更可靠的軟件交付。他是經驗豐富的演講者，曾在全球多個大會上發表演講。同時，他也是O’Reilly出版的《Building Microservices》一書的作者。譯者介紹王威，Thoughtworks總監級咨詢師，知樸咨詢創始人，DDD中國社區聯合創始人，Cynefin框架培訓講師，微服務架構、領域驅動設計、遺留系統重構的實踐者。梅雪松，Thoughtworks總監級咨詢師，遺留系統現代化服務負責人，微服務架構、領域驅動設計、遺留系統重構的實踐者。姚琪琳，Thoughtworks專家級咨詢師，遺留系統現代化服務負責人，極客時間《遺留系統現代化實戰》專欄作者，技術書籍譯者。
書友推薦
- >
山海經
- >
新文學天穹兩巨星--魯迅與胡適/紅燭學術叢書(紅燭學術叢書)
- >
羅曼·羅蘭讀書隨筆-精裝
- >
詩經-先民的歌唱
- >
苦雨齋序跋文-周作人自編集
- >
月亮虎
- >
推拿
- >
唐代進士錄
本類暢銷
