[套装书]微服务架构设计模式+企业级业务架构设计：方法论与实践（2册）

作者
[美]克里斯·理查森（Chris Richardson）付晓岩
丛书名
架构师书库
出版社
机械工业出版社
ISBN
9782002072116
简要
简介
内容简介书籍计算机书籍 ---------------------------微服务架构设计模式--------------------------- 本书共13章，第1章引入了微服务架构模式语言的概述；第2章解释了为什么软件架构很重要，并描述了可用于将应用程序分解为服务的模式；第3章介绍了微服务架构中强大的进程间通信的几种模式；第4章介绍Saga模式；第5章介绍领域驱动设计（DDD）的聚合和领域事件等模式的使用；第6章介绍如何使用事件溯源模式；第7章介绍如何使用 API 组合模式或命令查询责任隔离（CQRS）模式；第8章介绍外部 API 模式；第9章和第10章介绍微服务自动化测试技术；第11章介绍开发生产就绪服务的各个方面；第12章介绍部署模式；第13章介绍绞杀者模式。 ---------------------------企业级业务架构设计：方法论与实践--------------------------- 内容简介 这是一部从方法论和工程实践双维度阐述企业级业务架构设计的著作。 作者是一位资深的业务架构师，在金融行业工作超过19年，有丰富的大规模复杂金融系统业务架构设计和落地实施经验。本书在出版前邀请了微软、亚马逊、阿里、百度、网易、Dell、Thoughtworks、58、转转等10余家企业的13位在行业内久负盛名的资深架构师和技术专家对本书的内容进行了点评，一致好评推荐。 作者在书中倡导“知行合一”的业务架构思想，全书内容围绕“行线”和“知线”两条主线展开。“行线”涵盖企业级业务架构的战略分析、架构设计、架构落地、长期管理的完整过程，“知线”则重点关注架构方法论的持续改良。 全书分为五个部分： 业务架构基础篇（第1～3章） 介绍了业务架构的发展历程、作用、与IT架构的关系，以及业务模型的相关知识。 业务架构设计篇（第4～7章） . 详细讲解了战略分析、对标分析、组织结构的影响、业务架构设计方法、标准化方法，并以一个虚拟案例综合演示了业务架构的设计过程。 业务架构落地篇（第8～13章） 演示了业务架构方案制作、基于业务架构的实施、项目完成后的管理机制，比较了与敏捷开发的异同，集中讨论了企业级项目的实施困难，最后以一个设计实例展示了业务架构设计对提升企业开发效率的作用。 架构方法改良篇（第14～16章） 系统总结了如何进行面向构件化的业务架构设计、如何构建轻量级架构设计工具、如何基于构件模型提升传统企业产品创新效率，该部分属于对之前方法的改良设想，需要读者对此多加思索，切勿生搬硬套。 业务架构与中台篇（第17章） 将业务架构设计方法与当前热点——“中台”模式进行了对比，“传统”方法并不一定会因新技术、新概念的发展而黯然失色，对方法论的深入探索和积极思考往往会让“传统”焕发新的“生命力”，深度思考比追逐热点更重要。
目录



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


写给中文版读者的话
译者序
中文版序一
中文版序二
前言
引言
第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
1.1　Zachman模型2
1.2　TOGAF4
1.3　FEA和DODAF5
1.4　沉吟至今6
1.5　业务架构的定义8
第2章　业务架构的作用及与IT架构的关系10
2.1　业务架构的作用10
2.2　业务架构与IT架构的关系14
第3章　架构伴侣：业务模型18
3.1　模型与业务模型18
3.2　常见的建模方法21
3.3　建模原则与模型思维的应用25
第二部分 　业务架构设计篇
第4章　业务架构的设计起点33
4.1　企业战略分析33
4.2　对标分析38
4.3　组织结构的影响不容忽视40
第5章　业务架构的设计过程44
5.1　价值链分析44
5.2　行为分析：业务领域和业务流程46
5.3　数据分析：企业级数据模型49
5.4　组件分析：行为与数据的结合51
5.5　业务架构的整体逻辑关系53
第6章　业务架构的设计难点56
6.1　基本的标准化方法56
6.2　避免“过度整合”59
6.3　何以解忧，唯有“融合”59
第7章　虚拟案例：商业银行业务架构设计61
7.1　价值链设计61
7.2　存款领域的模型设计63
7.3　贷款领域的模型设计65
7.4　跨领域的标准化67
7.5　组件设计70
7.6　案例总结73
第三部分 　业务架构落地篇
第8章　从业务架构模型到业务架构方案76
8.1　业务架构设计不是为了替代需求分析76
8.2　制作业务架构方案77
8.3　小团队的应对之道83
8.4　需要充分解释架构方案84
8.5　努力打造“通用语言”85
第9章　基于业务架构方案的实施过程88
9.1　基于业务架构的设计89
9.2　基于业务架构的协调94
9.3　处理架构调整的原则96
9.4　企业级物有所值吗？100
第10章　建立转型后的长期应用机制103
10.1　项目结束了该怎么办？103
10.2　促进深度融合的需求管理机制106
第11章　这个“笨重”的过程与敏捷沾边吗？110
11.1　传说中和现实中的双模开发110
11.2　与正宗的敏捷对比112
11.3　与非正宗的敏捷对比114
11.4　且行且珍惜115
第12章　企业级的“五难” 117
12.1　捷径难寻118
12.2　文化难建119
12.3　预期难控120
12.4　权责难定121
12.5　长志难立123
第13章　实战：实现了快速设计的案例124
13.1　项目背景及需求124
13.2　设计思路和业务架构方案125
13.3　案例总结129
第四部分 　架构方法改良篇
第14章　如何支持面向构件的设计132
14.1　“乐高积木”式的软件设计132
14.2　“颗粒度”问题134
14.3　构件模型的设计方式136
14.4　建立构件模型的虚拟案例139
14.5　构件模型的技术设计建议146
14.6　本章小结148
第15章　构建轻量级架构管理工具150
15.1　构件模型的抽象要素及逻辑关系150
15.2　轻量级架构管理工具的设计原理153
15.3　采集项目信息的价值155
15.4　轻量级架构管理工具的优缺点155
15.5　应用轻量级架构管理工具管理新需求156
第16章　基于构件模型谈谈传统企业的产品创新159
16.1　信息传导：打造信息传递高速公路160
16.2　信息分析：创造高维数据162
16.3　创新平台：扩展构件模型165
16.4　构件模型及其应用设想的不足169
第五部分 　业务架构与中台篇
第17章　中台之上172
17.1　阿里中台简介172
17.2　企业文化的作用174
17.3　由业务架构方法可以推导出中台设计吗？176
尾声　对实践的再次思考179
附录A　位置、力量、资源183
附录B　积木式创新187



有问题微信扫码联系

推荐

Understand China
桂ICP备20004708号-4