阅读(3034) (0)

微服务架构设计模式

2021-04-21 17:46:05 更新

微服务架构设计模式


[美] 克里斯·理查森(Chris Richardson) 著,喻勇 译

  • 出版社: 机械工业出版社
  • ISBN:9787111624127
  • 版次:1
  • 商品编码:12595796
  • 品牌:机工出版
  • 包装:平装
  • 丛书名: 架构师书库
  • 开本:16开
  • 出版时间:2019-05-01
  • 用纸:胶版纸
  • 页数:455

点此购买

编辑推荐

适读人群 :本书的重点是架构和开发,适合负责开发和交付软件的任何人(例如开发人员、架构师、 CTO等)阅读。示例代码使用Java语言和Spring框架

本书由世界十大软件架构师之一、微服务架构的先驱、Java开发者社区的意见领袖Chris Richardson亲笔撰写,旨在帮助架构师和程序员学会使用微服务架构成功开发应用程序。书中描述了如何解决我们将面临的众多架构设计挑战,包括如何管理分布式数据,还介绍了如何将单体应用程序重构为微服务架构,涵盖44个架构设计模式,系统解决服务拆分、事务管理、查询和跨服务通信等难题。本书并不是鼓吹微服务架构的宣言,作者既介绍了微服务的原理、原则,又详细讲解了实际落地中的架构设计模式,将使你理解微服务架构、它的好处和弊端,以及应该何时使用微服务架构。本书将帮助你建立微服务的全局视野,并学会在纷繁复杂的情况下做出正确的架构选择和取舍。

本书将教会你如何开发和部署生产级别的微服务架构应用。这套宝贵的架构设计模式建立在数十年的分布式系统经验之上,Chris还为开发服务添加了新的模式,并将它们组合成可在真实条件下可靠地扩展和执行的系统。本书不仅仅是一个模式目录,还提供了经验驱动的建议,以帮助你设计、实现、测试和部署基于微服务的应用程序。

本书包含:

●如何(以及为什么)使用微服务架构

●服务拆分的策略

●事务管理和查询相关的模式

●高效的测试策略

●包括容器和Serverless在内的部署模式

本书专为熟悉标准企业应用程序架构的开发人员编写,使用Java语言和Spring框架编写所有示例代码。


内容简介

成功地开发基于微服务架构的应用软件,需要掌握一系列全新的架构思想和实践。在这本独特的书籍中,世界十大软件架构师之一、微服务架构先驱Chris Richardson收集、分类并解释了44个架构设计模式,这些模式用来解决诸如服务拆分、事务管理、查询和跨服务通信等难题。

本书的目标是让架构师和程序员学会使用微服务架构成功开发应用程序。

书中不仅讨论了微服务架构的好处,还描述了它们的弊端。读者将掌握如何在使用单体架构和使用微服务架构之间做出正确的权衡。

【谁应该阅读本书】

本书的重点是架构和开发,适合负责开发和交付软件的任何人(例如开发人员、架构师、CTO 等)阅读。

本书侧重于解释微服务架构的设计模式和其他概念。无论读者使用何种技术栈,我的目标都是让你们可以轻松读懂这本书。你只需要熟悉企业应用程序架构和设计的基础知识即可。特别是,需要了解三层架构、Web 应用程序设计、关系型数据库、使用消息和基于 REST 的进程间通信,以及应用程序安全性的基础知识等概念。本书的代码示例使用 Java 和 Spring 框架。为了充分利用它们,读者应该对 Spring 框架有所了解。

【本书内容安排】

本书由13章组成。

●第1章描述了所谓“单体地狱”的症状,当单体应用程序超出其架构时会出现这种问题,这可以通过采用微服务架构来规避。这一章还概述了微服务架构模式语言,这也是本书大部分内容的主题。

●第2章解释了为什么软件架构很重要,描述了可用于将应用程序分解为服务集合的模式,并解释了如何克服在此过程中遇到的各种障碍。

●第3章介绍了微服务架构中强大的进程间通信的几种模式,解释了为什么异步和基于消息的通信通常是最佳选择。

●第4章介绍如何使用 Saga 模式维护服务间的数据一致性。Saga 是通过传递异步消息的方式进行协调的一系列本地事务。

●第5章介绍如何使用领域驱动设计(DDD)的聚合和领域事件等模式为服务设计业务逻辑。

●第6章以第5章为基础,解释了如何使用事件溯源模式开发业务逻辑,事件溯源模式是一种以事件为中心的设计思路,用来构建业务逻辑和持久化领域对象。

●第7章介绍如何使用API组合模式或命令查询职责隔离(CQRS)模式,这两个模式用来实现查询分散在多个服务中的数据。

●第8章介绍了处理来自各种外部客户端请求的外部 API 模式,例如移动应用程序、基于浏览器的 JavaScript 应用程序和第三方应用程序。

●第9章是关于微服务自动化测试技术的两章中的第一章,介绍了重要的测试概念,例如测试金字塔,描述了测试套件中每种测试类型的相对比例,还展示了如何编写构成测试金字塔基础的单元测试。

●第10章以第9章为基础,描述了如何在测试金字塔中编写其他类型的测试,包括集成测试、消费者契约测试和组件测试等。

●第11章介绍了开发生产就绪服务的各个方面,包括安全性、外部化配置模式和服务可观测性模式。服务可观测性模式包括日志聚合、应用指标和分布式追踪。

●第12章介绍了可用于部署服务的各种部署模式,包括虚拟机、容器和 Serverless 模式。还介绍了使用服务网格的好处,服务网格是在微服务架构中处理服务间通信的一个网络软件层。

●第13章介绍了如何通过采用绞杀者(Strangler)模式逐步将单体架构重构为微服务架构,绞杀者模式是指以服务形式实现新功能,从单体中提取模块将其转换为服务。

在学习这些章节的过程中,读者将了解微服务架构的不同方面。


作者简介

克里斯·理查森(Chris Richardson)

世界十大软件架构师之一,《POJOS in Action》等技术名著的作者,也是著名开源项目 Cloud Foundry 和 Eventuate 的创始人。他的研究领域包括微服务架构设计、分布式数据管理、事件驱动的应用架构、领域驱动设计、持续交付、Spring 框架、Scala、NoSQL 数据库等。

喻勇

在技术圈驰骋多年,曾担任过微软技术布道师,VMware Cloud Foundry生态建设负责人,并有幸引领了国内容器技术的创业浪潮。目前定居加拿大,关注微服务架构、云原生应用等领域。

Chris与喻勇曾在VMware全球开发者关系团队共事多年,现在他们合作为国内企业客户提供微服务相关的咨询和培训服务,他们的中文网站是:www.chrisrichardson.cn


精彩书评

“全面概述了团队在转向微服务时面临的挑战,以及针对这些问题的、经过行业检验的解决方案。”

——Tim Moore,Lightbend

“系统性地阐述了一个重要的架构领域。”

——Simeon Leyzerzon,Excelsior Software

“一本可靠的手册,可以加快你迁移到这个基于云的现代架构的速度。”

——John Guthrie,Dell/EMC

“可帮你理解微服务方法并在现实生活中使用它。”

——Potito Coluccelli,Bizmatica Econocom

“喻勇翻译的这本书是近几年我所看到的众多论述微服务架构书籍中好的一本。该书围绕微服务的架构设计,深入浅出地介绍了微服务与SOA等其他架构的区别,软件系统服务的拆分策略,微服务的同步和异步通信模式,如何使用微服务进行事务管理,如何在微服务架构中设计业务逻辑。同时详细描述了微服务架构中的测试和生产部署策略。该书所总结出的架构经验对设计微服务架构有很好的指导作用,建议软件研发人员认真研读。”

——陈斌,易宝支付CTO

“这本书里,不仅有微服务领域已经识别出来的问题、解决思路和解决方案,也有相应的代码例子。这本书可以帮助微服务相关人员构建知行合一的能力……这是一本可以帮你在设计微服务架构时做出取舍的书,它能在你处理微服务相关问题“左右为难”的时候给你提供参考和建议。”

——蔡书,独立顾问,PolarisTech联合创始人

“书中既包含了微服务的原理、原则,又包含了实际落地中的架构设计模式;既包含可举一反三的理念和概念,也包含类似领域驱动设计、Saga实现事务操作、CQRS构建事件驱动系统等具体可套用的范式……相信本书对于企业CIO推动公司数字化转型战略、软件开发者提升自身技术架构功力,以及云原生爱好者以微服务切入新的云原生体系,都有着极其重要的实践指导意义。”

——张鑫,才云科技CEO


目录

●第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

8.2APIGateway模式/250

8.2.1什么是APIGateway模式/250

8.2.2APIGateway模式的好处和弊端/256

8.2.3以Netflix为例的APIGateway/257

8.2.4APIGateway的设计难题/258

8.3实现一个APIGateway/260

8.3.1使用现成的APIGateway产品或服务/261

8.3.2开发自己的APIGateway/262

8.3.3使用GraphQL实现APIGateway/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的OrderService编写组件测试/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上部署RestaurantService/389

12.4.3部署APIGateway/392

12.4.4零停机部署/393

12.4.5使用服务网格分隔部署与发布流程/394

12.5部署模式:Serverless部署/402

12.5.1使用AWSLambda进行Serverless部署/403

12.5.2开发Lambda函数/404

12.5.3调用Lambda函数/404

12.5.4使用Lambda函数的好处/405

12.5.5使用Lambda函数的弊端/406

12.6使用AWSLambda和AWSGateway部署RESTful服务/406

12.6.1AWSLambda版本的RestaurantService/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.1DelayedDeliveryService的设计/441

13.4.2为DelayedDeliveryService设计集成胶水/442

13.5从单体中提取送餐管理功能/444

13.5.1现有的送餐管理功能/444

13.5.2DeliveryService概览/446

13.5.3设计DeliveryService的领域模型/447

13.5.4DeliveryService集成胶水的设计/450

13.5.5修改FTGO单体使其能够与DeliveryService交互/451


前言/序言

【写给中文版读者的话】

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日

【前  言】

我很喜欢的格言之一是:

未来已经到来,只是还没有平均分布。

—威廉·吉布森,科幻小说作家

这句话的实质是在说,新的想法和技术需要一段时间才能通过社区传播开来并被广泛采用。我发现并深入关注微服务的故事,就是新思想缓慢扩散的一个极好例子。这个故事始于 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经常难以跟上业务需求。大家都很想知道如何采用微服务架构来解决所有这些问题。

本书的目标就是回答这个问题。它将使读者对微服务架构、它的好处和弊端,以及应该何时使用微服务架构有一个很好的理解。书中描述了如何解决我们将面临的众多架构设计挑战,包括如何管理分布式数据,还介绍了如何将单体应用程序重构为微服务架构。但本书并不是鼓吹微服务架构的宣言。相反,它的内容围绕着一系列模式进行展开。模式是在特定上下文中发生的问题的可重用解决方案。模式的优点在于,除了描述解决方案的好处之外,还描述了成功实施解决方案时必须克服的弊端和问题。根据我的经验,在选择解决方案时,这种客观性会带来更好的决策。我希望你会喜欢阅读这本书,它会教你如何成功开发基于微服务架构的应用程序。


点此购买