[套装书]Service Mesh微服务架构设计+微服务架构设计模式（2册）

1.4　微服务化开展前的准备工作 …… 8
1.4.1　微服务开发框架 …… 8
1.4.2　微服务标准化 …… 15
1.4.3　持续集成与发布 …… 17
1.5　微服务实施 …… 17
1.5.1　微服务拆分 …… 17
1.5.2　微服务通信 …… 19
1.5.3　微服务稳定性保障 …… 20
1.6　本章小结 …… 25
第2章　微服务治理 …… 26
2.1　微服务治理基础 …… 26
2.1.1　服务治理由来 …… 26
2.1.2　服务治理的目标与愿景 …… 27
2.1.3　服务治理的工作范畴 …… 28
2.1.4　服务治理闭环体系 …… 29
2.2　正向服务治理 …… 29
2.2.1　效率治理 …… 30
2.2.2　稳定性治理 …… 31
2.3　效果治理 …… 34
2.4　可见可观测 …… 35
2.4.1　服务可见性 …… 35
2.4.2　变更可见性 …… 36
2.4.3　可观测性 …… 36
2.5　量化分析体系 …… 41
2.5.1　稳定性风险度量 …… 41
2.5.2　基于多维度监控的故障定位 …… 42
2.5.3　风险分析 …… 43
2.6　线上治理 …… 43
2.6.1　线上预案体系 …… 43
2.6.2　基于Metric的预案自动触发 …… 44
2.6.3　治理参数动态调整 …… 44
2.7　线下治理 …… 47
2.7.1　链路稳定性治理 …… 47
2.7.2　架构与资源治理 …… 50
2.8　服务治理演进 …… 50
2.8.1　远程Proxy方式 …… 51
2.8.2　基于智能客户端的服务框架 …… 52
2.8.3　本地Proxy …… 52
2.9　理想的服务治理架构 …… 53
2.10　本章小结 …… 54
第3章　下一代微服务框架Service Mesh概要 …… 55
3.1　Service Mesh基础 …… 55
3.1.1　什么是Service Mesh …… 55
3.1.2　Service Mesh的基本模式 …… 56
3.2　Service Mesh的发展历程 …… 58
3.3　Service Mesh项目Linkerd …… 60
3.3.1　Linkerd演进 …… 60
3.3.2　Linkerd路由机制 …… 62
3.3.3　Linkerd 2.0核心架构 …… 63
3.4　Service Mesh项目Istio …… 64
3.4.1　Envoy …… 64
3.4.2　Istio …… 66
3.5　Service Mesh其他解决方案 …… 67
3.5.1　国外其他Service Mesh项目 …… 67
3.5.2　Service Mesh在中国的发展 …… 68
3.6　Service Mesh云上产品 …… 69
3.6.1　AWS App Mesh …… 69
3.6.2　Azure Service Fabric Mesh …… 69
3.6.3　Google Cloud Service Mesh …… 70
3.6.4　SuperGloo …… 70
3.7　Service Mesh标准化 …… 71
3.8　本章小结 …… 71
第二篇　架　构　篇
第4章　Envoy架构剖析 …… 74
4.1　Envoy整体架构 …… 74
4.1.1　关键设计约束 …… 74
4.1.2　设计原则 …… 75
4.1.3　整体架构 …… 76
4.2　Envoy网络模型 …… 78
4.2.1　Envoy事件调度模型 …… 78
4.2.2　Envoy线程模型 …… 81
4.2.3　线程本地存储机制 …… 81
4.3　Envoy扩展模型 …… 84
4.3.1　插件扩展机制 …… 84
4.3.2　网络相关插件 …… 86
4.3.3　其他扩展插件 …… 88
4.4　Envoy数据平面API …… 88
4.4.1　XDS协议语义 …… 88
4.4.2　XDS协议通信 …… 90
4.5　Envoy启动管理 …… 91
4.5.1　正常启动 …… 92
4.5.2　热重启 …… 94
4.6　Envoy与Nginx架构层面的对比 …… 95
4.6.1　功能与定位 …… 96
4.6.2　网络模型 …… 96
4.6.3　连接处理 …… 97
4.6.4　插件机制 …… 98
4.6.5　配置管理 …… 99
4.6.6　内存管理 …… 99
4.6.7　部署与运维 …… 100
4.6.8　观测与诊断 …… 100
4.7　本章小结 …… 100
第5章　Istio架构剖析 …… 101
5.1　Istio整体架构 …… 101
5.1.1　数据平面组件 …… 102
5.1.2　控制平面组件 …… 103
5.2　Istio的Kubernetes基础 …… 104
5.2.1　Kubernetes综述 …… 104
5.2.2　Kubernetes网络访问模型 …… 107
5.2.3　Kubernetes API管理 …… 110
5.2.4　Istio与Kubernetes的相互关系 …… 111
5.3　Istio流量控制模型 …… 112
5.3.1　流量管理API …… 112
5.3.2　Istio Mesh模型 …… 116
5.4　Mixer模型 …… 118
5.4.1　Mixer基本概念 …… 119
5.4.2　Mixer通用配置模型 …… 119
5.4.3　Mixer架构演进以及对性能的影响 …… 121
5.5　Istio安全 …… 122
5.5.1　Istio安全基础 …… 122
5.5.2　Istio认证架构 …… 123
5.6　Istio配置处理框架 …… 124
5.6.1　配置验证 …… 125
5.6.2　配置变更处理和分发 …… 125
5.7　本章小结 …… 125
第6章　Istio控制流设计 …… 126
6.1　Envoy生命周期管理 …… 126
6.1.1　Envoy注入 …… 126
6.1.2　Envoy启动管理 …… 128
6.1.3　Envoy配置和运行状态监控 …… 131
6.2　Istio配置变更管理 …… 133
6.2.1　通用模型和机制 …… 133
6.2.2　Kubernetes具体实现 …… 137
6.3　控制平面和数据平面的XDS交互 …… 138
6.3.1　控制平面的gRPC Server启动 …… 139
6.3.2　Envoy的XDS请求 …… 140
6.3.3　Istio XDS配置下发 …… 140
6.3.4　Envoy的XDS消息接收 …… 143
6.4　XDS配置生成 …… 143
6.4.1　可见性 …… 143
6.4.2　配置生成机制 …… 145
6.4.3　XDS配置生成实现 …… 147
6.5　XDS配置的Envoy处理 …… 149
6.5.1　XDS配置变更的判断 …… 149
6.5.2　CDS配置的延迟处理 …… 150
6.5.3　集群和节点配置处理 …… 152
6.5.4　路由配置处理 …… 153
6.5.5　监听器配置处理 …… 153
6.6　本章小结 …… 155
第7章　Istio数据流设计 …… 156
7.1　Iptables …… 156
7.1.1　Iptables的基本原理 …… 156
7.1.2　Iptables在Istio中的使用 …… 158
7.2　监听管理 …… 158
7.2.1　监听器建立 …… 158
7.2.2　监听器和工作线程绑定 …… 159
7.3　连接管理 …… 160
7.3.1　监听器匹配 …… 160
7.3.2　协议过滤器匹配 …… 161
7.3.3　创建新连接 …… 161
7.4　网络I/O和缓冲区管理 …… 162
7.4.1　传输层数据读取 …… 162
7.4.2　插件处理 …… 163
7.5　Thrift协议处理 …… 164
7.5.1　Thrift插件的整体架构 …… 164
7.5.2　协议解析 …… 165
7.5.3　协议相关的插件机制 …… 166
7.6　HTTP请求处理 …… 168
7.6.1　HTTP请求处理流程 …… 168
7.6.2　协议解析 …… 169
7.6.3　路由管理 …… 171
7.6.4　HTTP过滤链处理 …… 174
7.6.5　负载均衡 …… 176
7.6.6　连接池实现 …… 179
7.7　本章小结 …… 182
第8章　Istio微服务治理 …… 183
8.1　链路稳定性治理 …… 183
8.1.1　超时机制 …… 183
8.1.2　重试机制和重试策略 …… 185
8.1.3　节点熔断和健康检查机制 …… 188
8.1.4　资源限制机制 …… 189
8.1.5　全局限流机制 …… 190
8.2　链路可观测性 …… 190
8.2.1　Envoy分布式跟踪支持 …… 190
8.2.2　Envoy Metric支持 …… 194
8.2.3　Envoy Log支持 …… 198
8.3　本章小结 …… 200
第9章　Service Mesh架构的工程化设计 …… 201
9.1　复用和解耦 …… 201
9.2　架构扩展机制 …… 203
9.2.1　服务注册中心插件机制 …… 203
9.2.2　Envoy Filter插件机制 …… 203
9.3　性能设计 …… 204
9.3.1　基于TLS的无锁设计 …… 204
9.3.2　多级缓存机制 …… 205
9.3.3　批量更新机制 …… 205
9.4　架构设计的权衡 …… 206
9.5　API和SDK设计 …… 207
9.5.1　声明式API设计 …… 207
9.5.2　代码自动生成机制 …… 207
9.6　配置管理 …… 208
9.6.1　基于Protobuf 3的配置Scheme描述 …… 208
9.6.2　配置动态加载机制 …… 210
9.7　本章小结 …… 210
第10章　Service Mesh与云原生架构 …… 211
10.1　Service Mesh和Serverless …… 211
10.1.1　Serverless基础 …… 211
10.1.2　Knative …… 213
10.2　东西向和南北向通信的统一 …… 215
10.3　云原生时代的Service Mesh …… 216
10.4　Service Mesh现状和展望 …… 217
10.5　本章小结 …… 218
附录　Service Mesh迁移的要点与原则 …… 219



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


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

.　　第3章为Service Mesh概述，讲述为什么Service Mesh能够解决微服务治理中的痛点问题，以及Service Mesh的发展历程和当前现状。
　　架构篇（第4～10章），本篇深入剖析Istio/Envoy在架构设计层面的原理和实现，以及Service Mesh未来展望。
　　第4章详细分析Envoy的整体架构，并且就架构设计层面与Nginx进行全方位的对比分析；
　　第5章分析Istio的整体架构以及各个组件的功能和设计；
　　第6章和第7章分别从控制流与数据流的角度，分析请求的处理策略与配置以及在整个Service Mesh中的流向和处理；
　　第8章讨论Istio的服务治理，重点聚焦可观测性和链路治理；
　　第9章讨论如何将Service Mesh中的一些架构思想和设计运用到平常的工程架构中去。
　　第10章展望Service Mesh技术在云原生架构下的未来和发展。
　　其中，第4～7章为本书的重点章节，如果你没有充足的时间完成全书的阅读，可以选择阅读重点章节。如果你是有着一定经验的资深人员，本书会是一本不错的案头书。
　　勘误和支持
　　由于笔者的水平有限，编写时间仓促，书中难免会出现一些错误或者不准确的地方，恳请读者批评指正。可以通过微信号cloudnative_techdev，或者邮箱junhai0909@qq.com联系到我。期待能够得到大家的真挚反馈，在技术之路上互勉共进。
　　致谢
　　感谢百度谢广军、孙晓，滴滴出行卢红波、王正克、姜泰旭、段俊伟、奚媛，好未来张国辉、陈雷、韩天峰在工作和技术上无微不至的指导，我的成长离不开各位的大力支持和栽培。
　　感谢ServiceMesher技术社区的全体同仁，特别是ServiceMesher技术社区的组织者，是他们通过大量技术布道，最早将Service Mesh技术引入国内，对国内Service Mesh技术发展做出了很大贡献。
　　特别致谢
　　最后，我要特别感谢太太刘敏和儿子，为写作这本书我牺牲了很多陪伴他们的时间，也正因为有他们的付出与支持，我才能坚持写下去。
　　同时，感谢我的父母和岳父母，有了他们的帮助和支持，我才有时间和精力去完成写作工作。
　　最后要重点感谢高婧雅编辑，得益于她的耐心审稿、宝贵的建议以及用心的修改，本书的质量才进一步得到提升。
　　谨以此书献给我最亲爱的家人，以及众多热爱微服务技术和Service Mesh技术的朋友们！
　　刘俊海
　　
　　
　　---------------------------微服务架构设计模式---------------------------
　　
　　
　　我最喜欢的格言之一是：
　　未来已经到来，只是还没有平均分布。
　　—威廉·吉布森，科幻小说作家
　　这句话的实质是在说，新的想法和技术需要一段时间才能通过社区传播开来并被广泛采用。我发现并深入关注微服务的故事，就是新思想缓慢扩散的一个极好例子。这个故事始于 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 一起开设新餐馆这些重要的家庭活动。
　　谢谢你们！
　　

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