具体描述
成功地开发基于微服务架构的应用软件,需要掌握一系列全新的架构思想和实践。在这本独特的书籍中,微服务架构的先驱、Java 开发者社区的意见领袖 Chris Richardson 收集、分类并解释了 44 个架构设计模式,这些模式用来解决诸如服务拆分、事务管理、查询和跨服务通信等难题。
本书将教会你如何开发和部署生产级别的微服务架构应用。这套宝贵的架构设计模式建立在数十年的分布式系统经验之上,Chris 还为开发服务添加了新的模式,并将它们组合成可在真实条件下可靠地扩展和执行的系统。本书不仅仅是一个模式目录,还提供了经验驱动的建议,以帮助你设计、实现、测试和部署基于微服务的应用程序。
本书包含:
如何(以及为什么)使用微服务架构
服务拆分的策略
事务管理和查询相关的模式
高效的测试策略
包括容器和 Serverless 在内的部署模式
本书专为熟悉标准企业应用程序架构的开发人员编写,使用 Java 编写所有示例代码。
作者简介
克里斯·理查森(Chris Richardson)
世界著名的软件大师,《POJOS in Action》等技术名著的作者,也是著名开源项目 Cloud Foundry 和 Eventuate 的创始人。他的研究领域包括微服务架构设计、分布式数据管理、事件驱动的应用架构 、领域驱动设计、持续交付、Spring 框架、Scala、NoSQL 数据库等。
喻勇
在技术圈驰骋多年,曾担任过微软技术布道师,VMware Cloud Foundry 生态建设负责人,并有幸引领了国内容器技术的创业浪潮。目前定居加拿大,关注微服务架构、云原生应用等领域。
Chris 与喻勇曾在 VMware 全球开发者关系团队共事多年,现在他们合作为国内企业客户提供微服务相关的咨询和培训服务,他们的中文网站是:www.chrisrichardson.cn
目录信息
写给中文版读者的话
译者序
中文版序一
中文版序二
前言
引言
第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
· · · · · · (收起)
读后感
本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQRS,以及如何进行测试。本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQRS,以及如何进行测试。本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQ...
精读了2,4-8章,大部分都是我们开发中在使用的,只是这本书进行了很好的总结,有些还提炼成模式。 有几点感想: 1. 六边形是一个不错的描述架构的方式,尤其对于那些依赖多或者涉及message的系统。可以用到以后的架构图中 2. 微服务大小并不那么重要,重要的是减少依赖,尽量...
本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQRS,以及如何进行测试。本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQRS,以及如何进行测试。本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQ...
精读了2,4-8章,大部分都是我们开发中在使用的,只是这本书进行了很好的总结,有些还提炼成模式。 有几点感想: 1. 六边形是一个不错的描述架构的方式,尤其对于那些依赖多或者涉及message的系统。可以用到以后的架构图中 2. 微服务大小并不那么重要,重要的是减少依赖,尽量...
本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQRS,以及如何进行测试。本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQRS,以及如何进行测试。本书涵盖了一些非常流行的概念,比如处理事务的Sagas、构建事件驱动系统的CQ...
用户评价
我是一名有一定微服务实践经验的开发者,正在寻求将现有系统进行重构,或者在设计新系统时,能够更加深入地理解微服务架构的深层原理和最佳实践。这本书正好满足了我的需求。它不是一本教你如何“写”微服务的操作指南,而是一本帮助你“思考”微服务架构设计哲学的书籍。书中深入探讨了微服务拆分的度量、服务间的通信模式选择(同步 vs 异步,REST vs gRPC),以及如何平衡服务的独立性与一致性。令我印象深刻的是关于“领域驱动设计”(DDD)与微服务结合的章节,它清晰地阐述了如何利用DDD来指导微服务的边界划分,从而构建出真正解耦、易于维护的微服务体系。书中对“康威定律”的解读也让我重新审视了团队组织与微服务架构的关系,认识到技术选型与组织架构的协同演进是微服务成功的关键。另外,书中对“分布式系统的挑战”的剖析,如数据一致性、监控、故障排除等,都给出了非常深刻的见解和实用的策略。读这本书,我感觉自己不再是仅仅停留在“知道”微服务有哪些组件,而是开始“理解”它们为什么这么设计,以及在不同场景下应该如何灵活应用。
作为一名刚刚接触微服务领域不久的技术人员,这本书简直就像及时雨!我之前一直被单体应用的种种局限性困扰,比如代码耦合度高、部署困难、扩展性差等等。在工作中,也零星听说过微服务的概念,但总觉得有点遥不可及,不知道该如何下手。这本书的出现,让我看到了一个清晰的蓝图。它没有上来就讲一堆晦涩难懂的理论,而是从解决实际问题的角度出发,循序渐进地介绍了微服务架构的核心思想。特别是关于服务拆分策略的章节,详细讲解了如何根据业务领域、数据边界等因素来划分服务,这对我来说至关重要。我曾尝试过几次不成功的服务拆分,结果适得其反,导致服务间依赖混乱,维护成本飙升。这本书中的案例分析非常贴合实际,让我茅塞顿开,明白了之前犯错的原因。此外,书中对服务注册与发现、API网关、分布式事务等关键组件的讲解也相当到位,让我对微服务架构的整体运作有了更深入的理解。这本书的语言通俗易懂,图文并茂,非常适合我这样的初学者。我甚至可以在通勤路上,利用碎片时间阅读,吸收其中的知识。
作为一名负责技术选型和平台建设的技术负责人,我一直在寻找能够指导团队构建现代化、可伸缩、易于运维的微服务平台的最佳实践。这本书提供了一套非常系统化的解决方案。它不仅仅是列举了各种设计模式,更是强调了在实际落地过程中需要考虑的方方面面。书中对“基础设施即代码”(IaC)与微服务部署的结合,以及如何利用容器化技术(如Docker和Kubernetes)来管理和编排微服务,都给出了非常实用的建议。这对于我们团队在云原生时代构建高效的CI/CD流水线至关重要。另外,书中对“可观测性”(Observability)的重视,比如日志、度量、追踪的统一管理,让我意识到这才是保证微服务系统稳定运行的关键。我们曾经在排查线上问题时,因为缺乏有效的日志聚合和分布式追踪,花费了大量的时间和精力。这本书中的相关章节,让我看到了构建一个具备强大可观测性的微服务平台的路径。总体而言,这本书为我提供了一个全面的框架,能够帮助我带领团队更好地拥抱微服务,并构建出能够应对未来业务挑战的强大系统。
作为一个在大型互联网公司工作的架构师,我时常面临着如何在复杂的业务场景下,设计出可扩展、高可用、易于维护的微服务系统。这本书为我提供了宝贵的参考和启发。书中对“弹性设计”的强调,比如服务降级、熔断、限流等策略,让我深刻认识到在分布式环境中,拥抱故障并设计出能够优雅处理异常的系统是多么重要。我曾在处理高并发场景时,由于缺乏有效的故障转移机制,导致整个服务雪崩。这本书中的相关章节,通过具体的案例和模式,展示了如何构建更加健壮的微服务。此外,书中关于“数据管理”的讨论也让我受益匪浅。在微服务架构下,如何处理分布式数据一致性,如何选择合适的数据库技术,如何进行跨服务的数据查询和聚合,这些都是我工作中经常遇到的难题。书中对“Saga模式”的详细介绍,以及与其他分布式事务解决方案的对比,让我对如何在高并发、强一致性要求下设计数据流程有了更清晰的思路。这本书的内容深度和广度都非常适合我这样的资深从业者,它能够帮助我优化现有的架构,并在未来的设计中规避潜在的陷阱。
我是一名刚刚毕业,对软件架构充满好奇心的学生。在学校的学习中,我们接触了很多关于单体应用、面向对象的设计等基础知识。但当我开始接触到实际的开发项目,特别是看到一些成熟的互联网产品时,我意识到传统的单体架构已经无法满足现代软件开发的需求。这本书的出现,为我打开了新世界的大门。它用一种非常直观的方式,解释了微服务架构的优势,以及它如何解决单体架构的瓶颈。书中关于“服务拆分”的原则,比如“围绕业务能力拆分”,让我明白了为什么要这样拆分,以及拆分后的好处。我特别喜欢书中对“API网关”的讲解,它就像是微服务系统的大门,负责请求的路由、认证、限流等等,这让我对整个系统的入口有了更清晰的认识。书中还提到了“服务治理”的概念,比如服务注册、发现、健康检查等,这些都是我之前从未深入了解过的。虽然有些概念对我来说还有些陌生,但我可以通过书中的图示和解释,大致理解它们的作用。这本书为我提供了一个学习微服务架构的良好起点,我希望能继续深入研究其中的每一个模式。
【英文版】
事务事件日志,一种类似财务复式记账的方法在书中的业务设计中用出来彩,想一想,事务不就主要用在钱上吗,如果再结合blockchain,可能会有其他创新点。
从单体应用到微服务的设计演进,讲解比较全面,推荐一读。
泛泛而谈,还是当初看《微服务设计》更有收获
总体感觉就是我知道的大神都知道,我不知道的大神也知道.无论是学习微服务还是实施微服务,这本书都能达到解惑的目标.在学习spring cloud,kerbernete的时候,一直都有疑问,为什么要这么做,多种方式效果差不多,怎么选之类,读了这书,真的让我茅塞顿开--一切都是取舍.架构师的作用就是分清现实和目标,做好取舍.书里面不仅仅做比较,还根据具体的示例说明推荐的方案.收获超级多,短期内还需要结合代码复习一下.