微服務架構設計模式 (Microservices Patterns: With examples in Java)
[美] 克裡斯·理查森(Chris Richardson) 著
- 出版商: 機械工業
- 出版日期: 2019-04-01
- 售價: $834
- 貴賓價: 9.5 折 $792
- 語言: 簡體中文
- ISBN: 7111624122
- ISBN-13: 9787111624127
-
相關分類:
Microservices 微服務、SOA、Design Pattern
- 此書翻譯自: Microservices Patterns: With examples in Java (Paperback) 銷售排行: 👍 2022 年度 簡體中文書 銷售排行 第 12 名
🥈 2022/6 簡體中文書 銷售排行 第 2 名
👍 2021 年度 簡體中文書 銷售排行 第 9 名
🥇 2021/1 簡體中文書 銷售排行 第 1 名
👍 2020 年度 簡體中文書 銷售排行 第 5 名
🥉 2020/12 簡體中文書 銷售排行 第 3 名
立即出貨 (庫存 < 4)
買這商品的人也買了...
-
$653$614 -
$580$458 -
$450$383 -
$650$507 -
$780$616 -
$580$452 -
$403Spring 微服務實戰 (Spring Microservices in Action)
-
$594$564 -
$1,280$998 -
$755Kubernetes in Action (簡體中文版)
-
$680$530 -
$480$379 -
$580$458 -
$454Java 微服務測試:基於 Arquillian、Hoverfly、AssertJ、JUnit、Selenium 與 Mockito (Testing Java Microservices: Using Arquillian, Hoverfly, AssertJ, JUnit, Selenium, and Mockito)
-
$720$562 -
$505微服務體系建設和實踐
-
$980$774 -
$454$427 -
$454微服務實戰 (Microservices in Action)
-
$714$678 -
$534$507 -
$680$537 -
$580$458 -
$800$624 -
$520$410
商品描述
成功地開發基於微服務架構的應用軟件,需要掌握一系列全新的架構思想和實踐。在這本獨特的書籍中,微服務架構的先驅、Java開發者社區的意見領袖Chris Richardson收集、分類並解釋了44個架構設計模式,這些模式可用來解決諸如服務拆分、事務管理、查詢和跨服務通信等難題。
本書將教會你如何開發和部署生產級別的微服務架構應用。這套寶貴的架構設計模式建立在數十年的分佈式系統經驗之上,Chris還為開發服務添加了新的模式,並將它們組合成可在真實條件下可靠地擴展和執行的系統。本書不僅僅是一個模式目錄,還提供了經驗驅動的建議,以幫助你設計、實現、測試和部署基於微服務的應用程序。
本書包含
如何(以及為什麽)使用微服務架構
服務拆分的策略
事務管理和查詢相關的模式
高效的測試策略
包括容器和Serverless在內的部署模式
本書專為熟悉標準企業應用程序架構的開發人員編寫,使用Java編寫所有示例代碼。
目錄大綱
目錄
寫給中文版讀者的話
譯者序
中文版序一
中文版序二
前言
引言
第1章逃離單體地獄/ 1
1.1邁向單體地獄的漫長旅程/ 2
1.1.1 FTGO應用程序的架構/ 3
1.1.2單體架構的好處/ 4
1.1.3什麼是單體地獄/ 4
1.2為什麼本書與你有關/ 7
1.3你會在本書中學到什麼/ 8
1.4拯救之道:微服務架構/ 8
1.4.1擴展立方體和服務/ 9
1.4.2微服務架構作為模塊化的一種形式/ 11
1.4.3每個服務都擁有自己的數據庫/ 12
1.4.4 FTGO的微服務架構/ 12
1.4.5微服務架構與SOA的異同/ 14
1.5微服務架構的好處和弊端/ 15
1.5.1微服務架構的好處/ 15
1.5.2微服務架構的弊端/ 17
1.6微服務架構的模式語言/ 19
1.6.1微服務架構並不是“銀彈” / 20
1.6.2模式和模式語言/ 21
1.6.3微服務架構的模式語言概述/ 24
1.7微服務之上:流程和組織/ 29
1.7.1進行軟件開發和交付的組織/ 30
1.7.2進行軟件開發和交付的流程/ 31
1.7.3採用微服務架構時的人為因素/ 32
第2章服務的拆分策略/ 34
2.1微服務架構到底是什麼/ 35
2.1.1軟件架構是什麼,為什麼它如此重要/ 35
2.1.2什麼是架構的風格/ 37
2.1.3微服務架構是一種架構風格/ 40
2.2為應用程序定義微服務架構/ 43
2.2.1識別系統操作/ 45
2.2.2根據業務能力進行服務拆分/ 50
2.2.3根據子域進行服務拆分/ 53
2.2.4拆分的指導原則/ 54
2.2.5拆分單體應用為服務的難點/ 56
2.2.6定義服務API / 59
第3章微服務架構中的進程間通信/ 63
3.1微服務架構中的進程間通信概述/ 64
3.1.1交互方式/ 64
3.1.2在微服務架構中定義API / 66
3.1.3 API的演化/ 67
3.1.4消息的格式/ 69
3.2基於同步遠程過程調用模式的通信/ 70
3.2.1使用REST / 71
3.2.2使用gRPC / 74
3.2.3使用斷路器模式處理局部故障/ 75
3.2.4使用服務發現/ 78
3.3基於異步消息模式的通信/ 82
3.3.1什麼是消息傳遞/ 83
3.3.2使用消息機制實現交互方式/ 84
3.3.3為基於消息機制的服務API創建API規範/ 86
3.3.4使用消息代理/ 87
3.3.5處理並發和消息順序/ 91
3.3.6處理重複消息/ 92
3.3.7事務性消息/ 93
3.3.8消息相關的類庫和框架/ 97
3.4使用異步消息提高可用性/ 99
3.4.1同步消息會降低可用性/ 99
3.4.2消除同步交互/ 101
第4章使用Saga管理事務/ 106
4.1微服務架構下的事務管理/ 107
4.1.1微服務架構對分佈式事務的需求/ 108
4.1.2分佈式事務的挑戰/ 109
4.1.3使用Saga模式維護數據一致性/ 109
4.2 Saga的協調模式/ 113
4.2.1協同式Saga / 113
4.2.2編排式Saga / 117
4.3解決隔離問題/ 121
4.3.1缺乏隔離導致的問題/ 122
4.3. 2 Saga模式下實現隔離的對策/ 123
4.4 Order Service和Create Order Saga的設計/ 127
4.4.1 OrderService類/ 128
4.4.2 Create Order Saga的實現/ 129
4.4.3 OrderCommandHandlers類/ 136
4.4.4 OrderServiceConfiguration類/ 138
第5章微服務架構中的業務邏輯設計/ 141
5.1業務邏輯組織模式/ 142
5.1.1使用事務腳本模式設計業務邏輯/ 143
5.1.2使用領域模型模式設計業務邏輯/ 144
5.1.3關於領域驅動設計/ 146
5.2使用聚合模式設計領域模型/ 146
5.2.1模糊邊界所帶來的問題/ 147
5.2.2聚合擁有明確的邊界/ 149
5.2.3聚合的規則/ 150
5.2.4聚合的顆粒度/ 152
5.2.5使用聚合設計業務邏輯/ 153
5.3發布領域事件/ 154
5.3. 1為什麼需要發布變更事件/ 154
5.3.2什麼是領域事件/ 155
5.3.3事件增強/ 155
5.3.4識別領域事件/ 156
5.3.5生成和發布領域事件/ 157
5.3.6消費領域事件/ 161
5.4 Kitchen Service的業務邏輯/ 162
5.5 Order Service的業務邏輯/ 167
5.5 .1 Order聚合/ 169
5.5.2 OrderService類/ 173
第6章使用事件溯源開發業務邏輯/ 176
6.1使用事件溯源開發業務邏輯概述/ 177
6.1.1傳統持久化技術的問題/ 177
6.1.2什麼是事件溯源/ 179
6.1.3使用樂觀鎖處理並發更新/ 186
6.1.4事件溯源和發布事件/ 186
6.1.5使用快照提升性能/ 188
6.1.6冪等方式的消息處理/ 189
6.1.7領域事件的演化/ 190
6.1.8事件溯源的好處/ 192
6.1.9事件溯源的弊端/ 193
6.2實現事件存儲庫/ 194
6.2.1 Eventuate Local事件存儲庫的工作原理/ 195
6.2.2 Eventuate的Java客戶端框架/ 198
6.3同時使用Saga和事件溯源/ 201
6.3 .1使用事件溯源實現協同式Saga / 203
6.3.2創建編排式Saga / 203
6.3.3實現基於事件溯源的Saga參與方/ 205
6.3.4實現基於事件溯源的Saga編排器/ 208
第7章在微服務架構中實現查詢/ 212
7.1使用API組合模式進行查詢/ 213
7.1.1 findOrder()查詢操作/ 213
7.1.2什麼是API組合模式/ 214
7.1.3使用API組合模式實現findOrder()查詢操作/ 215
7.1.4 API組合模式的設計缺陷/ 216
7.1.5 API組合模式的好處和弊端/ 219
7.2使用CQRS模式/ 220
7.2.1為什麼要使用CQRS / 220
7.2.2什麼是CQRS / 223
7.2.3 CQRS的好處/ 226
7.2.4 CQRS的弊端/ 227
7.3設計CQRS視圖/ 228
7.3.1選擇視圖存儲庫/ 229
7.3. 2設計數據訪問模塊/ 230
7.3.3添加和更新CQRS視圖/ 232
7.4實現基於AWS DynamoDB的CQRS視圖/ 233
7.4.1 OrderHistoryEventHandlers模塊/ 234
7.4.2 DynamoDB中的數據建模和查詢設計/ 235
7.4. 3 OrderHistoryDaoDynamoDb類/ 239
第8章外部API模式/ 244
8.1外部API的設計難題/ 245
8.1.1 FTGO移動客戶端API的設計難題/ 246
8.1.2其他類型客戶端API的設計難題/ 248
8.2 API Gateway模式/ 250
8.2.1什麼是API Gateway模式/ 250
8.2.2 API Gateway模式的好處和弊端/ 256
8.2.3以Netflix為例的API Gateway / 257
8.2.4 API Gateway的設計難題/ 258
8.3實現一個API Gateway / 260
8.3.1使用現成的API Gateway產品或服務/ 261
8.3.2開發自己的API Gateway / 262
8.3.3使用GraphQL實現API Gateway / 269
第9章微服務架構中的測試策略(上) / 282
9.1微服務架構中的測試策略概述/ 284
9.1.1什麼是測試/ 284
9.1.2微服務架構中的測試挑戰/ 289
9.1.3部署流水線/ 295
9.2為服務編寫單元測試/ 296
9.2.1為實體編寫單元測試/ 298
9.2.2為值對象編寫單元測試/ 299
9.2.3為Saga編寫單元測試/ 300
9.2.4為領域服務編寫單元測試/ 302
9.2.5為控制器編寫單元測試/ 303
9.2.6為事件和消息處理程序編寫單元測試/ 305
第10章微服務架構中的測試策略(下) / 308
10.1編寫集成測試/ 308
10.1.1針對持久化層的集成測試/ 311
10.1.2針對基於REST的請求/響應式交互的集成測試/ 312
10.1.3針對發布/訂閱式交互的集成測試/ 316
10.1.4針對異步請求/響應式交互的集成契約測試/ 320
10.2編寫組件測試/ 324
10.2.1定義驗收測試/ 325
10.2.2使用Gherkin編寫驗收測試/ 326
10.2.3設計組件測試/ 328
10.2. 4為FTGO的Order Service編寫組件測試/ 330
10.3端到端測試/ 334
10.3.1設計端到端測試/ 335
10.3.2編寫端到端測試/ 335
10.3.3運行端到端測試/ 336
第11章開發麵向生產環境的微服務應用/ 338
11.1開發安全的服務/ 339
11.1.1傳統單體應用程序的安全性/ 340
11.1.2在微服務架構中實現安全性/ 343
11.2設計可配置的服務/ 349
11.2.1使用基於推送的外部化配置/ 350
11.2.2使用基於拉取的外部化配置/ 352
11.3設計可觀測的服務/ 353
11.3.1使用健康檢查API模式/ 355
11.3.2使用日誌聚合模式/ 357
11.3.3使用分佈式追踪模式/ 358
11.3.4使用應用程序指標模式/ 361
11.3.5使用異常追踪模式/ 364
11.3.6使用審計日誌模式/ 365
11.4使用微服務基底模式開發服務/ 367
11.4.1使用微服務基底/ 368
11.4.2從微服務基底到服務網格/ 368
第12章部署微服務應用/ 371
12.1部署模式:編程語言特定的發布包格式/ 374
12.1.1使用編程語言特定的發布包格式進行部署的好處/ 376
12.1.2使用編程語言特定的發布包格式進行部署的弊端/ 377
12.2部署模式:將服務部署為虛擬機/ 378
12.2.1將服務部署為虛擬機的好處/ 380
12.2.2將服務部署為虛擬機的弊端/ 380
12.3部署模式:將服務部署為容器/ 381
12.3.1使用Docker部署服務/ 383
12.3.2將服務部署為容器的好處/ 385
12.3.3將服務部署為容器的弊端/ 386
12.4使用Kubernetes部署FTGO應用程序/ 386
12.4.1什麼是Kubernetes / 386
12.4.2在Kubernetes上部署Restaurant Service / 389
12.4.3部署API Gateway / 392
12.4.4零停機部署/ 393
12.4.5使用服務網格分隔部署與發布流程/ 394
12.5部署模式:Serverless部署/ 402
12.5.1使用AWS Lambda進行Serverless部署/ 403
12.5.2開發Lambda函數/ 404
12.5.3調用Lambda函數/ 404
12.5 .4使用Lambda函數的好處/ 405
12.5.5使用Lambda函數的弊端/ 406
12.6使用AWS Lambda和AWS Gateway部署RESTful服務/ 406
12.6.1 AWS Lambda版本的Restaurant Service / 407
12.6.2把服務打包為ZIP文件/ 411
12.6.3使用Serverless框架部署Lambda函數/ 412
第13章微服務架構的重構策略/ 415
13.1重構到微服務需要考慮的問題/ 416
13.1.1為什麼要重構單體應用/ 416
13.1.2絞殺單體應用/ 417
13.2將單體應用重構為微服務架構的若干策略/ 420
13.2.1將新功能實現為服務/ 420
13.2.2隔離表現層與後端/ 422
13.2.3提取業務能力到服務中/ 423
13.3設計服務與單體的協作方式/ 429
13.3.1設計集成膠水/ 430
13.3.2在服務和單體之間維持數據一致性/ 434
13.3.3處理身份驗證和訪問授權/ 438
13.4將新功能實現為服務:處理錯誤配送訂單/ 440
13.4.1 Delayed Delivery Service的設計/ 441
13.4.2為Delayed Delivery Service設計集成膠水/ 442
13.5從單體中提取送餐管理功能/ 444
13.5.1現有的送餐管理功能/ 444
13.5.2 Delivery Service概覽/ 446
13.5.3設計Delivery Service的領域模型/ 447
13.5.4 Delivery Service集成膠水的設計/ 450
13.5.5修改FTGO單體使其能夠與Delivery Service交互/ 451