目錄
前言 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