[套装书]中台战略：中台建设与数字商业+微服务架构设计模式（2册）

. 全书一共12章，逻辑上分为三个部分：

第一部分（第1-2章） 从宏观上交代了所有企业都面临数字化转型的大时代背景，并指出中台是企业数字化转型的关键驱动力，数字营销是企业数字化转型的3个重点领域之一。

第二部分（第3-7章） 从成功要素、建设方法论、架构设计、成熟度模型4个维度详细讲解技术中台、业务中台、数据中台的建设思路和方法。

第三部分（第8-12章） 从数字化转型和商业创新的角度讲解了中台为数字化营销赋能的底层商业逻辑、技术架构和实施路径，用3个真实的综合案例展示了实践的完整过程。


---------------------------微服务架构设计模式---------------------------


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

.云徙科技汽车事业部总经理，香港中文大学信息工程硕士，专注于汽车行业数字化营销研究。曾多次创业，包含社群电商、智能家居、互联网＋农业S2B2C中台项目，先后主导过长安汽车、一汽集团、长安福特等头部车企以及博郡汽车、爱驰汽车等新能源车企基于汽车行业中台的数字化营销项目。

江威
云徙科技地产事业部总经理，领导中台在地产方面的建设与落地，长期从事阿里中台赋能地产行业的研究与布道，拥有丰富的地产项目实施经验。曾任明源云、阿里云地产行业等业务总监，具备丰富的地产行业业务及产品经验，先后主导过万科、保利、新城、富力等多家大型地产的数字化项目。

2.6　面向营销的数字中台 39
第3章　全面解读中台
3.1　什么是中台 45
3.2　中台系统及其展现形式 50
3.3　中台的作用 52
3.4　中台的发展与进化 65
第4章　企业中台5大成功要素
4.1　中台文化：7个行为准则和行动纲领 80
4.2　组织架构：中台为组织架构赋能 94
4.3　人员能力要求：运营、业务、技术铁三角 99
4.4　业务执行：业务运营与敏捷开发 106
4.5　中台实施：1个经验和4个教训 118
第5章　中台建设方法论
5.1　中台架构整体策略 125
5.2　业务顶层设计 127
5.3　业务中台设计方法论 129
5.4　数据中台设计方法论 148
5.5　应用向中台迁移的3种途径和方法 156
第6章　中台的架构与设计
6.1　技术中台规划 159
6.2　业务中台的建设 160
6.3　数据中台的建设 175
第7章　中台成熟度模型
7.1　成熟度评估模型 205
7.2　成熟度能力评估 213
第8章　中台助力的数字营销
8.1　消费者全触点覆盖 217
8.2　全域消费者运营 219
8.3　全渠道交易 223
8.4　全链路服务 242
8.5　数据驱动的运营 254
8.6　营销的核心是运营用户数字资产 259
8.7　平台+运营，支撑企业营销变革 268
第9章　数字营销的技术架构与路径
9.1　基于中台架构，构建立体数字营销云 273
9.2　数字营销云技术架构和设计理念 275
9.3　数字营销云的3种部署架构 283
9.4　实现数字营销云的关键技术特性 285
第10章　A公司：快速响应数字营销的中台
10.1　案例背景 295
10.2　IT困境 296
10.3　确定中台方案 299
10.4　中台价值初现 304
10.5　未来规划 317
第11章　B公司：中台为数字营销赋能
11.1　案例背景 320
11.2　B公司数字化营销的动机和背景 321
11.3　B公司数字化营销价值链落地实践 323
11.4　IT与业务部门通力合作，推进营销数字化规划落地 331
11.5　未来展望 333
第12章　C公司：数字营销打造流量池运营体系
12.1　案例背景 336
12.2　实施过程 337
12.3　创新描述 345
12.4　市场应用及展望 346
12.5　价值评估 347



---------------------------微服务架构设计模式---------------------------


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

.　　1）连接消费者或客户，从企业的商品到消费者或客户的过程属于营销，连接的是企业的消费者或客户。营销的数字化，归结为数字营销领域。
　　2）连接员工，企业从订单到生产计划的过程属于企业内部管理，连接的是员工，让所有的员工在链路上协同，这是ERP管理的范畴。内部管理的数字化，属于数字管理领域。
　　3）连接设备和产品，生产计划下达后，从生产计划到MES系统生产线的过程连接的是生产设备。比如每一台设备怎么去生产，每道工序中给每一个产品拍个照片，然后通过数据解析来控制质量、工艺水平等。生产部分的数字化，属于工业大数据领域。
　　其中，数字管理（ERP）领域，应用已经比较成熟；工业大数据领域的应用还处于热点期，部分企业也在尝试，这个领域范畴大且难，大部分企业还在观望；相对其他两个领域，数字营销是一个新的领域，很多企业都没做过，这是互联网企业比较看好且容易出效率、出价值的领域，是企业数字化转型的突破口。
　　数字营销，用“技术＋数据”助力企业业务提升
　　数字营销是以“技术＋数据”为双驱动，对传统营销进行互联网化、数据化和智能化改造，进而帮助企业构建消费者全渠道触达，实现精准互动和交易的过程。其本质是借助数据、算法及营销资源，依靠实时数据跟踪，实现营销由粗放向集约发展；依靠中台的强大连接能力，实现渠道从单一向多元发展；内容策划和投放依靠数据算法的预测，从经验决策变为智能决策。最终帮助企业实现营销资源利用更高效，推广费用大幅降低。
　　数字营销是实现以消费者需求为核心的数字化体验创新，也是最终实现面向最终客户体验的触点创新。数字营销强调的是对新技术的运用、互联网业务逻辑分析的能力。数字营销赋予了营销组合新的内涵，是数字经济时代企业的主流营销方式和发展趋势。
　　企业做数字营销的目的或者价值是什么？收入增长。阿里的使命是“让天下没有难做的生意”，云徙的使命是“引领企业数字化创新”。云徙要用“双中台＋数字营销云＋运营”，助力企业业务提升。
　　中台成为构架企业数字营销的主要模式
　　在产业互联网时代，当数字化成为企业的核心战略后，如何实现业务数据化？如何使数据赋能企业推动业务转型升级？如何提升企业数字资产的价值？这些都成为制约企业发展的难题。在此背景下，数字中台成为指导企业数字化转型、实现数字营销的主流方法。
　　数字中台是基于企业级互联网及大数据架构打造的数字化创新平台，包含业务中台和数据中台。
　　一方面，数字中台可以在云厂商提供的运行机制和基础架构之上，支撑企业营销业务应用的标准化及快速定制化，同时为企业提供大数据数据采集、清洗、管理和分析能力，实现数据精细化运营。数据中台可以将企业内外割裂的数据进行汇聚、治理、建模加工，消除数据孤岛，实现数据资产化，为企业提供客户立体画像、商品智能推荐、业务实时监控，助力企业实现数据驱动业务。
　　另一方面，业务中台不仅可以将原本不同系统相同功能的服务聚合起来，统一标准，统一规范，统一出口，实现企业业务的整合；还可以通过服务的聚合实现资源与能力共享，支撑新应用与新业务的快速开发与迭代，以满足快速变化的用户需求。
　　数字中台模式是将共性业务服务和技术予以沉淀，避免相同功能重复建设和维护带来的资源浪费。集合了技术和产品能力的业务中台能快速、低成本地完成业务创新，数据中台则能实现数据资源的共享。未来，全面建立一个服务化架构的数字中台将会成为传统大型企业全面数字化转型的最佳解决方案，甚至成为未来数字营销的主导方案。同时，企业数字中台将朝着跨终端、全渠道、全域运营方向发展，基于云原生技术实现中台弹性扩容，依靠平台能力为各个系统产品输出统一管理能力，帮助企业实现业务数据化、数据业务化，赋能企业智能化营销。
　　阿里携手云徙，在企业服务过程中共创数字中台
　　自从2015年12月阿里巴巴集团宣布启动中台战略以来，阿里巴巴的“大中台，小前台”在阿里体系已经过大量商业实践和技术积累。基于“大中台，小前台”组织，及其业务机制及技术体系，淘宝逐渐衍生出了天猫、聚划算、闲鱼、飞猪等业务及应用，之后还成功支撑了这些业务及应用的正常运营、运行。科技普惠企业，阿里巴巴集团成立独立科技公司阿里云，携手伙伴向企业输出成功的商业实践和技术。
　　云徙科技是第一家认同阿里巴巴中台价值的ISV，跟随阿里云，以往三年共服务了近40家行业头部企业数字化转型，践行中台架构，通过与企业共同创新，积累和打造出业界领先的云徙数字中台。
　　
　　
　　---------------------------微服务架构设计模式---------------------------
　　
　　
　　我最喜欢的格言之一是：
　　未来已经到来，只是还没有平均分布。
　　—威廉·吉布森，科幻小说作家
　　这句话的实质是在说，新的想法和技术需要一段时间才能通过社区传播开来并被广泛采用。我发现并深入关注微服务的故事，就是新思想缓慢扩散的一个极好例子。这个故事始于 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 和 Marina Michaels。Cynthia Kane 帮助我启动了这本书，并在前几章与我合作。Marina Michaels 接替 Cynthia 并与我一起工作到最后。Marina 对书的内容提出了细致和建设性的意见，我将永远感激不尽。我还要感谢 Manning 出版社参与了这本书的出版的其他成员。
　　我要感谢技术编辑 Christian Mennerich、技术校对员 Andy Miles以及所有的外部审校员：Andy Kirsch、Antonio Pessolano、Areg Melik-Adamyan、Cage Slagel、Carlos Curotto、Dror Helper、Eros Pedrini、Hugo Cruz、Irina Romanenko、Jesse Rosalia、Joe Justesen、John Guthrie、Keerthi Shetty、Michele Mauro、Paul Grebenc、Pethuru Raj、Potito Coluccelli、Shobha Iyer、Simeon Leyzerzon、Srihari Sridharan、Tim Moore、Tony Sweets、Trent Whiteley、Wes Shaddix、William E. Wheeler 和 Zoltan Hamori。
　　我还要感谢所有购买 MEAP 预览版并在论坛或直接向我提供反馈的人。
　　我要感谢我曾经参与过的所有会议和聚会的组织者及与会者，他们给了我大量的机会，让我介绍和调整我关于微服务的想法。我要感谢我在世界各地的咨询和培训客户，让我有机会帮助他们将我关于微服务的想法付诸实践。
　　我还要感谢 Eventuate 公司的同事 Andrew、Valentin、Artem 和 Stanislav 对 Eventuate 产品和开源项目的贡献。
　　最后，我要感谢妻子 Laura 和孩子Ellie、Thomas 和 Janet，感谢他们在过去的 18 个月里给予我的支持和理解。这段时间我一直盯着我的笔记本电脑，以至于接连错过了观看 Ellie 的足球比赛、Thomas 学习飞行模拟器，以及尝试与 Janet 一起开设新餐馆这些重要的家庭活动。
　　谢谢你们！
　　

.　　
　　---------------------------微服务架构设计模式---------------------------
　　
　　
　　全面概述了团队在转向微服务时面临的挑战，以及针对这些问题的、经过行业检验的解决方案。
　　—— Tim Moore，Lightbend
　　系统性地阐述了一个重要的架构领域。
　　—— Simeon Leyzerzon，Excelsior Software
　　一本可靠的手册，可以加快你迁移到这个基于云的现代架构的速度。
　　—— John Guthrie，Dell/EMC
　　可帮你理解微服务方法并在现实生活中使用它。
　　—— Potito Coluccelli，Bizmatica Econocom
　　喻勇翻译的这本书是近几年我所看到的众多论述微服务架构书籍中最好的一本。该书围绕微服务的架构设计，深入浅出地介绍了微服务与SOA等其他架构的区别，软件系统服务的拆分策略，微服务的同步和异步通信模式，如何使用微服务进行事务管理，如何在微服务架构中设计业务逻辑。同时详细描述了微服务架构中的测试和生产部署策略。该书所总结出的架构经验对设计微服务架构有很好的指导作用，建议软件研发人员认真研读。
　　—— 陈斌，易宝支付CTO
　　这本书里，不仅有微服务领域已经识别出来的问题、解决思路和解决方案，也有相应的代码例子。这本书可以帮助微服务相关人员构建知行合一的能力……这是一本可以帮你在设计微服务架构时做出取舍的书，它能在你处理微服务相关问题左右为难的时候给你提供参考和建议。
　　—— 蔡书，独立顾问，PolarisTech 联合创始人
　　书中既包含了微服务的原理、原则，又包含了实际落地中的架构设计模式；既包含可举一反三的理念和概念，也包含类似领域驱动设计、Saga实现事务操作、CQRS构建事件驱动系统等具体可套用的范式……相信本书对于企业CIO推动公司数字化转型战略、软件开发者提升自身技术架构功力，以及云原生爱好者以微服务切入最新的云原生体系，都有着极其重要的实践指导意义。
　　—— 张鑫，才云科技CEO