微服务架构设计模式[美]克里斯·理查森

写给中文版读者的话

7年前，我带着对美食和技术的热情，开始了我的首次中国之旅。在那之前，我对中国的美食和软件社区都知之甚少。7年之后，经过多次中国之行，我对这两者都有了深刻的认识：我爱上了地道的中国菜，也对中国的软件开发者印象深刻。

2012年我首次访问中国，参加我在VMware公司的同事Frank举办的几场开发者会议。我一口气在北京和上海做了好几场演讲，包括云计算、Cloud Foundry、Node.js、Spring、NoSQL数据库，当然，还有微服务。我与2000多位参加会议的来宾讨论Cloud Foundry，这次旅行让我意识到中国开发者社区的规模和热情，也让我有机会品尝了地道的中国菜。我甚至还忙里偷闲，在北京参加了一天中餐烹饪课程。

2013年，Frank再次邀请我来到北京，参加中国首场SpringOne大会，发表关于微服务和NoSQL的演讲。这次旅行的亮点是访问豆瓣和百度，这是我与中国科技公司的第一次近距离接触。他们的规模和创新技术都给我留下了非常深刻的印象。在这次旅行中，我参观了北京奥林匹克公园，回忆了曾在这里举行的2008年北京奥运会开幕式。我也抓住机会，继续“进修”中餐烹饪课程。

这次大会结束后不久，我离开VMware公司，再次走上了创业的道路。我搭建了microservices.io网站，撰写了大量的文章和课件，搭乘我钟爱的United Airlines，为世界各地的客户提供微服务架构咨询和培训服务。我还创立了eventuate.io公司，发布了用于微服务架构的数据访问框架。这些工作促成了我和Frank的再度合作，我有幸在2016年4月和8月再次访问中国。从那以后，我在中美之间多次往返，帮助中国的企业客户实施微服务架构。这些公司的业务多种多样，包括保险、汽车制造、电信和企业软件。地域上的跨度，也从北京和上海延伸到了深圳、武汉和杭州。在这些旅行中，我爱上了烤鱼、新疆菜和蒙古菜。

中国企业和开发者对微服务架构的热情让我印象深刻。但如同我给所有客户的忠告一样，我想对本书的读者说：

第一，要记住微服务不是解决所有问题的万能“银弹”。

第二，编写整洁的代码和使用自动化测试至关重要，因为这是现代软件开发的基础。

第三，关注微服务的本质，即服务的分解和定义，而不是技术，如容器和其他工具。

第四，确保你的服务松耦合，并且可以独立开发、测试和部署，不要搞成分布式单体（Distributed Monolith），那将会是巨大的灾难。

第五，也是最重要的，不能只是在技术上采用微服务架构。拥抱DevOps的原则和实践，在组织结构上实现跨职能的自治团队，这必不可少。

还必须记住：实现微服务架构并不是你的目标。你的目标是加速大型复杂应用程序的开发。

最后，我要感谢中国的所有客户，让我有机会与你们探讨微服务。我还要感谢那些让我能够讨论技术而不用学说中文（这可比微服务难多了）的同传翻译。我希望你会喜欢阅读这本书，它会教你如何成功开发微服务。我期待着再次访问中国，与我的读者见面，帮助更多企业客户实施微服务架构。

Chris Richardson

2019年2月13日

中文版序一

良马难乘，然可以任重致远；良才难令，然可以致君见尊。

—墨子

曾经有一个客户把他们遇到的微服务问题列出来给我看，当时我觉得头绪万千但又无从说起，于是想到了墨子的这句话。

如果现在有人问我这个问题，那么我会推荐他们一边看Chris Richardson的这本书，一边在实践中尝试和体验各种模式的优势与特点，然后大家一起讨论遇到的问题并提出解决思路。

大概从五六年前开始，我在工作中越来越多地谈到了微服务，并参与了一些客户应用的微服务改造，其中不乏成功的例子，当然也有没达到预期的情况。随着网络基础设施的高速发展，以及越来越多的企业和组织需要通过互联网提供服务，在考虑构建可以支持海量请求以及多变业务的软件平台时，微服务架构成为多数人的首选。微服务架构的出现是符合事物发展规律的：当问题足够大、有足够多的不确定性因素时，人们习惯把大的问题拆分成小的问题，通过分割、抽象和重用小而可靠的功能模块来构建整体的方案。但是当这些小的、可重用的部分越来越多时，又会出现新的问题。在相似的阶段，人们遇到的问题通常也是相似的，这个时候我们需要一些共识，需要用一些通用的词汇来描述问题以及解题思路和方案，这也是人们知识的总结。微服务模式就是这样一种总结和概括，是一种可以通用的共识，用于描述微服务领域中的问题及解决方案、方法和思路。这是我向大家推荐这本书的理由之一：讨论微服务的时候，这本书提供了必要的共同语言。

在和Chris交流时，我深深地被他高度的思维能力所折服，尤其是对问题的深刻理解和对解决思路的高度抽象。与有敏锐思维且有高度抽象能力的人讨论问题是件快乐的事情，他总是能把自己的经验和概括总结出的信息用清晰的方式表述出来。现在，他把关于微服务的这些抽象整理成了这本书。可以说，这是广大微服务相关工作人员的福音。在这本书里，不仅有微服务领域已经识别出来的问题、解决思路和解决方案，也有相应的代码例子。这就使得高度抽象的内容有了非常具体的表现，可以帮助我们在遇到问题之前就了解可能的潜在问题；有些代码例子甚至是可以直接使用的。这种知行合一的能力，是我钦佩Chris的又一个重要原因，也是我向大家推荐这本书的理由之二：这本书可以帮助微服务相关人员构建知行合一的能力。

在一次关于“架构的关键是什么”的讨论中，我们和Chris很快达成了共识：架构就是取舍，进而架构师就是做出取舍的人。大家都认同，做架构的人的特征之一应该是“Independent”（独立），这也是我选择做独立解决方案进而设计产品的重要原因。在我们看来，只有独立才有可能让我们在做架构设计时做出中立和独特的方案。面对问题时，大多数人会希望有人可以给出“正确的”建议，但是多数时候，困扰人们的不是“什么才是正确的”，而是“取舍之间”。这正是我推荐这本书的理由之三：这是一本可以帮你在设计微服务架构时做出取舍的书，它能在你处理微服务相关问题左右为难的时候给你提供参考和建议。

我们生活在一个高速发展的时代，微服务领域的技术、产品、模式日新月异，我们非常有幸参与和见证这个时代的发展。我们从解决昨天的问题里走出来，又走向更多的问题。在这个过程中，我们解决的问题的规模和复杂度都是成倍提升的。相信很多和我一样喜欢体验这种从无到有的过程、喜欢亲手解决问题的成就感、喜欢用独立思维去面对问题的人，都会喜欢这本书。在此，再次对ChrisRichardson先生表示感谢，他为这个领域贡献了宝贵的知识财富。

蔡书

独立顾问，PolarisTech联合创始人

中文版序二

国际数据公司（IDC）研究表明，2018～2021年间，全球数字化转型方面的直接支出将达到5.9万亿美元。埃森哲（Accenture）指出，目前在中国仅有7%的企业成功地实现了数字化转型，而这些成功转型的公司，它们的业绩复合增长率是尚未转型的同行企业的5倍之多。

数字化转型依赖技术创新。美国风险投资机构Work-Bench在《2018企业软件调研年报》中推论：以微服务为代表的云原生技术是帮助企业实现有效数字化转型的唯一技术途径。数字化转型背景下客户的预期越来越高，需要企业的线上业务能快速迭代满足动态的市场需求，并能弹性扩展应对业务的突发式增长；而微服务由于其敏捷灵活等特性成了满足这些诉求的最佳答案。因此，微服务可成为企业进行数字化转型的强力催化剂。

微服务的概念虽然直观易懂，但“细节是魔鬼”，微服务在实操落地的环节中存在诸多挑战。我们在为企业提供PaaS、人工智能、云原生平台等数字化转型解决方案时也发现，企业实现云原生，并充分利用PaaS能力的第一步，往往是对已有应用架构进行现代化微服务改造，而如何进行微服务拆分、设计微服务逻辑、实现微服务治理等实操问题成为很大的挑战。

本书英文原作由微服务权威架构师ChrisRichardson先生所著。书中既包含了微服务的原理、原则，又包含了实际落地中的架构设计模式；既包含可举一反三的理念和概念，也包含类似领域驱动设计、Saga实现事务操作、CQRS构建事件驱动系统等具体可套用的范式。本书可以帮助读者把传统的单体巨石型应用循序渐进地改造为微服务架构，从微服务的拆分，微服务架构下业务逻辑的设计以及事务、API、通信等的实现，一直到微服务系统的测试与生产上线，帮助读者建立从无到有的完整微服务系统搭建的生命周期。

本书译者在云计算、云原生与微服务领域有多年实践经验和建树，译文既精确地还原了原著的内容，又结合译者自身的理解，让中文版本更加通俗易懂。虽身在云计算行业多年，我在通读译著后依然受益匪浅。相信本书对于企业CIO推动公司数字化转型战略、软件开发者提升自身技术架构功力，以及云原生爱好者以微服务切入最新的云原生体系，都有着极其重要的实践指导意义。

张鑫

才云科技CEO

译者序

2012年年初，我有幸加入了VMware公司的CloudFoundry团队，与ChrisRichardson、PatrickChanezon、JoshLong等业界大咖共事，在全球范围内开展CloudFoundry开发者社区和生态建设工作。7年前，云计算的市场格局与现在大为不同。那时，IaaS正高歌猛进，PaaS的价值仍旧备受质疑，“十二原则”还不为人所知，云端分布式系统的架构演化也正“摸着石头过河”。在这个时候，ChrisRichardson率先在业界提出了“FunctionalDecomposition”（功能性拆分）的概念，提出云计算环境下的分布式软件，应该按照功能性拆分的方式进行架构重构。这个想法与稍后业界公认的“微服务”概念不谋而合。

在VMware公司工作期间，以及之后各自的创业经历中，我跟Chris保持着良好的个人关系和工作合作关系。Chris是一个风趣、博学、经验丰富的架构师，他在软件行业有将近30年的经验，在Java社区更是享有盛名。在离开VMware公司后，他建立了microservices.io网站，专注微服务架构的咨询和培训工作，我也曾为他牵线搭桥，使他有机会为国内的企业客户提供咨询服务。

经过这些年的发展，微服务已经成为软件领域的新宠，国外Netflix、Amazon的成功案例，国内数字化转型的一波波浪潮，推动着PaaS厂商和开发者深度关注微服务。大家围绕着微服务展开了大量的讨论。在这个过程中，我们认识到，虽然很多企业客户视微服务如救命稻草，但微服务并不能解决一切问题。很多客户，亦盲从于各种厂商的“忽悠”，着力建设底层基础设施。

面对这些迷茫，Chris曾对我说，软件的架构设计，就是选择和取舍。面对围绕微服务的众多杂音，开发者和架构师应该具备选择和取舍的能力，应该站在比较高的角度俯瞰全局、权衡利弊，做出正确的架构和技术选择。这也是最初Chris写作本书的动机之一：为架构师提供一个微服务的全局视野，并教会架构师如何在纷繁复杂的情况下做出正确的架构选择和取舍。

本书英文版的写作开始于2017年春天，2018年10月正式出版。在英文版出版后，我集中利用两个多月的时间完成了中文版的翻译工作。这是一本30万字的大部头，Chris曾数次对英文版做出较大的结构性修改。为了确保中文版的一致性和准确性，并且以最快速度翻译出版，中文版初稿完成后，先后经历了7轮修改润色和校对。在后期校对阶段，我邀请了数位好友帮助把关，他们是：薛江波、王天青、季奔牛、刘果、蔡书、张鑫、张扬、黄雨婷、毛艳玲。我特别感谢这些朋友，因为他们细致地校对了所有翻译稿，帮我找到并修正了大量足以让我“晚节不保”的低级错误。蔡书和张鑫还在繁忙的创业工作之余细读整本书，并撰写了推荐序。

本书的中文版出版后，我将与Chris重启针对中国市场的微服务咨询和培训业务。为此，我们发布了中文网站www.chrisrichardson.cn，并有针对性地设计了微服务培训和技术咨询的服务项目。我们期待与读者面对面交流的机会。

喻勇

2019年2月14日

克里斯·理查森（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.1FTGO应用程序的架构/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.4FTGO的微服务架构/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.3API的演化/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.2Saga的协调模式/113

4.2.1协同式Saga/113

4.2.2编排式Saga/117

4.3解决隔离问题/121

4.3.1缺乏隔离导致的问题/122

4.3.2Saga模式下实现隔离的对策/123

4.4OrderService和CreateOrderSaga的设计/127

4.4.1OrderService类/128

4.4.2CreateOrderSaga的实现/129

4.4.3OrderCommandHandlers类/136

4.4.4OrderServiceConfiguration类/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.4KitchenService的业务逻辑/162

5.5OrderService的业务逻辑/167

5.5.1Order聚合/169

5.5.2OrderService类/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.1EventuateLocal事件存储库的工作原理/195

6.2.2Eventuate的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.1findOrder()查询操作/213

7.1.2什么是API组合模式/214

7.1.3使用API组合模式实现findOrder()查询操作/215

7.1.4API组合模式的设计缺陷/216

7.1.5API组合模式的好处和弊端/219

7.2使用CQRS模式/220

7.2.1为什么要使用CQRS/220

7.2.2什么是CQRS/223

7.2.3CQRS的好处/226

7.2.4CQRS的弊端/227

7.3设计CQRS视图/228

7.3.1选择视图存储库/229

7.3.2设计数据访问模块/230

7.3.3添加和更新CQRS视图/232

7.4实现基于AWSDynamoDB的CQRS视图/233

7.4.1OrderHistoryEventHandlers模块/234

7.4.2DynamoDB中的数据建模和查询设计/235

7.4.3OrderHistoryDaoDynamoDb类/239

第8章外部API模式/244

8.1外部API的设计难题/245

8.1.1FTGO移动客户端API的设计难题/246

8.1.2其他类型客户端API的设计难题/248