微服务架构设计模式

成功地开发基于微服务架构的应用软件，需要掌握一系列全新的架构思想和实践。在这本独特的书籍中，世界十大软件架构师之一、微服务架构的先驱、Java开发者社区的意见领袖 Chris Richardson 收集、分类并解释了 44 个架构设计模式，这些模式用来解决诸如服务拆分、事务管理、查询和跨服务通信等难题。本书将教会你如何开发和部署生产级别的微服务架构应用。这套宝贵的架构设计模式建立在数十年的分布式系统经验之上，Chris 还为开发服务添加了新的模式，并将它们组合成可在真实条件下可靠地扩展和执行的系统。本书不仅仅是一个模式目录，还提供了经验驱动的建议，以帮助你设计、实现、测试和部署基于微服务的应用程序。本书包含：? 如何（以及为什么）使用微服务架构? 服务拆分的策略? 事务管理和查询相关的模式? 高效的测试策略? 包括容器和 Serverless 在内的部署模式本书专为熟悉标准企业应用程序架构的开发人员编写，使用 Java 编写所有示例代码。

本书共13章，第1章引入了微服务架构模式语言的概述；第2章解释了为什么软件架构很重要，并描述了可用于将应用程序分解为服务的模式；第3章介绍了微服务架构中强大的进程间通信的几种模式；第4章介绍Saga模式；第5章介绍领域驱动设计（DDD）的聚合和领域事件等模式的使用；第6章介绍如何使用事件溯源模式；第7章介绍如何使用 API 组合模式或命令查询责任隔离（CQRS）模式；第8章介绍外部 API 模式；第9章和第10章介绍微服务自动化测试技术；第11章介绍开发生产就绪服务的各个方面；第12章介绍部署模式；第13章介绍绞杀者模式。

写给中文版读者的话
译者序
中文版序一
中文版序二
前言
引言
第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.

我 喜欢的格言之一是：
未来已经到来，只是还没有平均分布。
—威廉·吉布森，科幻小说作家
这句话的实质是在说，新的想法和技术需要一段时间才能通过社区传播开来并被广泛采用。我发现并深入关注微服务的故事，就是新思想缓慢扩散的一个极好例子。这个故事始于 2006 年，当时受到 AWS 布道师一次演讲的启发，我开始走上了一条 终导致我创建早期 Cloud Foundry 的道路，它与今天的 Cloud Foundry 相同的是名称。Cloud Foundry 采用平台即服务（PaaS）模式，用于在 EC2 上自动部署 Java 应用程序。与我构建的其他每个企业级 Java 应用程序一样，我的 Cloud Foundry 采用了单体架构，它由单个 Java Web 应用程序（WAR）文件构成。
将初始化、配置、监控和管理等各种复杂的功能捆绑到一个单体架构中，这给开发和运维都带来了挑战。例如，你无法在不测试和重新部署整个应用程序的情况下更改它的用户界面。因为监控和管理组件依赖于维护内存状态的复杂事件处理（CEP）引擎，所以我们无法运行应用程序的多个实例！这是个令人尴尬的事实，但我可以说的是，我是一名软件开发人员，就让我这个无辜的码农来指出这些问题吧。
显然，单体架构无法满足应用程序的需求，但替代方案是什么？在eBay 和亚马逊等公司，软件界已经开始逐渐尝试一些新东西。例如，亚马逊在 2002 年左右开始逐步从单体架构迁移（https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq）。新架构用一系列松散耦合的服务取代了单体。服务由亚马逊称为“两个比萨”的团队所维护：团队规模小到两个比萨饼就能让所有人吃饱。
亚马逊采用这种架构来加快软件开发速度，以便公司能够更快地进行创新并赢得竞争。结果令人印象深刻：据报道，亚马逊平均每11.6秒就能够将代码的更改部署到生产环境中！
2010年年初，当我转向其他项目之后，我终于领悟了软件架构的未来。那时我正在读Michael T. Fisher和Martin L. Abbott 撰写的《The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise》（Addison-Wesley Professional，2009）。该书中的一个关键思想是扩展立方体，如第2章所述，它是一个用于扩展应用程序的三维模型。由扩展立方体定义的 Y 轴扩展功能将应用程序功能分解为服务。事后来看，这是显而易见的，但对我来说，这是一个让我醍醐灌顶的时刻！如果将 Cloud Foundry 设计为一组服务，我本可以解决两年前面临的挑战！
2012年4月，我首次就这种架构方法发表了题为“Decomposing Applications for Scalability and Deployability”的演讲（www.slideshare.net/chris.e.richardson/decomposing-applications-for-scalability-and-deployability-april-2012）。当时，这种架构并没有一个被普遍接受的名称。我有时称它为模块化多语言架构，因为服务可以用不同的语言编写。
未来还没有平均分布的另一个佐证是，微服务这个词在 2011 年的软件架构研讨会上被用来描述这种架构（https://en.wikipedia.org/wiki/Microservices）。当我听到 Fred George 在 Oredev 2013 上发表演讲时，我次遇到这个词，我立刻喜欢上了它！
2014年1月，我创建了https://microservices.io 网站，以记录我遇到的与微服务有关的架构和设计模式。在 2014 年 3 月，James Lewis 和 Martin Fowler 发表了一篇关于微服务的博客文章（https://martinfowler.com/articles/microservices.html）。随着微服务这个术语被广泛传播，这篇博客文章使整个软件社区开始围绕微服务这个新概念展开更进一步的思考和行动。
小型、松散耦合的团队快速可靠地开发和运维微服务的思想正在通过软件社区慢慢扩散。但是，这种对未来的看法可能与日常现实截然不同。如今，业务关键型企业应用程序通常是由大型团队开发的大型单体应用。虽然软件版本不经常更新，但每次更新都会给所涉及的参与人员带来巨大的痛苦。IT经常难以跟上业务需求。大家都很想知道如何采用微服务架构来解决所有这些问题。
本书的目标就是回答这个问题。它将使读者对微服务架构、它的好处和弊端，以及应该何时使用微服务架构有一个很好的理解。书中描述了如何解决我们将面临的众多架构设计挑战，包括如何管理分布式数据，还介绍了如何将单体应用程序重构为微服务架构。但本书并不是鼓吹微服务架构的宣言。相反，它的内容围绕着一系列模式进行展开。模式是在特定上下文中发生的问题的可重用解决方案。模式的优点在于，除了描述解决方案的好处之外，还描述了成功实施解决方案时必须克服的弊端和问题。根据我的经验，在选择解决方案时，这种客观性会带来更好的决策。我希望你会喜欢阅读这本书，它会教你如何成功开发基于微服务架构的应用程序。
致谢
写作是一项孤独的活动，但是把粗略的草稿变成一本完整的图书，却需要来自各方的共同努力。
首先，我要感谢 Manning 出版社的 Erin Twohey 和 Michael Stevens，他们一直鼓励我在《POJOs in Action》之后再写一本书。我还要感谢我的编辑 Cynthia Kane