正版 企业架构与绕不开的微服务 樊超 电子工业出版社 9787121430

第1篇 企业中的架构和架构师
-
第1章 被轻视的企业架构 / 2
1.1 被滥用的架构 / 2
1.1.1 来源于建筑却不同于建筑 / 2
1.1.2 难以统一的定义 / 3
1.1.3 架构与架构风格 / 4
1.2 常见的架构风格 / 5
1.2.1 三层架构 / 5
1.2.2 SOA架构 / 8
1.2.3 单体架构 / 12
1.2.4 微服务架构 / 13
1.3 与众不同的企业架构 / 14
1.3.1 更大的范围 / 14
1.3.2 更大的风险 / 15
1.3.3 更大的收益 / 15
1.3.4 支撑企业数字化转型 / 16
1.4 举步维艰的企业架构 / 18
1.4.1 企业内的重视程度不足 / 18
1.4.2 系统间的壁垒和代沟 / 20
1.4.3 简单粗暴的集成方式 / 22
1.4.4 尴尬的IT部门 / 24
1.4.5 难以量化的生产力 / 26
1.4.6 快速变化的外部环境 / 27
1.5 企业架构反模式 / 28
1.5.1 采用“双速IT” / 28
1.5.2 视IT部门为成本中心 / 31
1.5.3 以为“买买买”可以解决一切问题 / 33
1.5.4 主数据管理与微服务思想矛盾 / 34
1.5.5 以技术驱动架构设计 / 37
1.6 企业架构标准来拯救 / 38
1.6.1 TOGAF简介 / 39
1.6.2 首先要有愿景 / 42
1.6.3 一切都围绕着需求 / 46
1.6.4 4种架构 / 48
1.6.5 架构开发方法 / 50
1.6.6 迁移要被规划 / 51
1.6.7 实施要被治理 / 54
1.6.8 变更要被管理 / 56
1.6.9 TOGAF的能力框架 / 59
1.6.10 企业架构标准小结 / 63
1.7 本章小结 / 64
-
第2章 不一样的EA架构师 / 65
2.1 谁是架构师？ / 65
2.2 不一样的EA架构师 / 68
2.2.1 与建筑师不一样 / 68
2.2.2 与技术架构师不一样 / 70
2.2.3 与业务架构师不一样 / 73
2.2.4 与敏捷架构师不一样 / 75
2.2.5 这才是EA架构师 / 79
2.3 EA架构师工作反模式 / 81
2.3.1 独立的架构组 / 82
2.3.2 中央集权和独裁 / 86
2.3.3 以有“技术洁癖”为荣 / 89
2.3.4 妄想“技术改变世界” / 92
2.4 做好一个EA架构师 / 94
2.4.1 成为漩涡的中心 / 95
2.4.2 成为导师：为他人转身 / 98
2.4.3 搭上“架构师电梯” / 102
2.5 本章小结 / 107
-
第3章 企业架构的目标 / 108
3.1 评估架构的4个维度 / 108
3.2 为企业“松绑” / 109
3.2.1 不可避免的绑定 / 109
3.2.2 8种绑定类型 / 110
3.2.3 绑定有害 / 113
3.2.4 松绑模式 / 120
3.2.5 绑定依然不可避免 / 127
3.3 让功能尽快面世 / 127
3.3.1 好与快，一个都不能少 / 128
3.3.2 为飞行中的飞机更换零件 / 130
3.3.3 让人月不再是神话 / 132
3.4 不再被半夜的电话惊醒 / 133
3.4.1 抵御安全事件 / 134
3.4.2 让性能不再是空话 / 137
3.4.3 让系统变成“打不死的小强” / 139
3.4.4 自动化系统的韧性 / 142
3.5 生生不息地持续演化 / 143
3.6 本章小结 / 145
-
第2篇 云原生来拯救
-
第4章 云原生 / 147
4.1 云原生的定义 / 147
4.1.1 云原生应用 / 147
4.1.2 云原生技术 / 148
4.1.3 云原生架构 / 148
4.2 云原生的代表技术 / 149
4.2.1 新一代虚拟化技术：容器 / 149
4.2.2 细粒度分布式架构：微服务 / 150
4.2.3 第三代微服务架构：服务网格 / 151
4.2.4 只能重建不能修改：不可变基础设施 / 152
4.2.5 关注目的而非过程：声明式API / 154
4.3 再谈容器 / 156
4.3.1 容器 VS 虚拟机 / 156
4.3.2 容器与镜像 / 157
4.3.3 容器编排技术 / 159
4.3.4 容器与微服务 / 161
4.4 再谈服务网格 / 161
4.4.1 服务网格的实现 / 161
4.4.2 与API网关的关系 / 163
4.4.3 服务网格与微服务 / 165
4.4.4 适用场景 / 167
4.4.5 不适用场景 / 168
4.5 云原生技术改变企业架构 / 169
4.5.1 云原生技术带来的改变 / 169
4.5.2 新的架构原则 / 172
4.5.3 新的架构模式 / 173
4.6 云原生架构的评判标准 / 176
4.6.1 是否符合“12因素” / 176
4.6.2 是否使用了微服务架构 / 182
4.6.3 是否使用了DevOps / 184
4.7 不是“银弹”，也不免费 / 186
4.7.1 终极架构谬误 / 186
4.7.2 比想象中更高的成本 / 187
4.8 本章小结 / 190
-
第3篇 云原生的核心：微服务
-
第5章 微服务的前世今生 / 192
5.1 前世与今生 / 192
5.2 从单体到微服务 / 193
5.2.1 微服务的反面：单体 / 193
5.2.2 微服务的前世：SOA / 195
5.2.3 微服务架构的定义 / 195
5.3 微服务架构原则 / 197
5.3.1 业务驱动原则 / 197
5.3.2 单一职责原则 / 199
5.3.3 信息隐藏原则 / 199
5.3.4 去中心化原则 / 200
5.3.5 独立部署原则 / 200
5.3.6 隔离失败原则 / 201
5.3.7 可视化原则 / 201
5.3.8 技术无关原则 / 202
5.4 解读微服务架构九大特性 / 202
5.4.1 组件化与多服务 / 203
5.4.2 围绕业务功能组织团队 / 204
5.4.3 做产品而不是做项目 / 205
5.4.4 智能端点与傻瓜通道 / 206
5.4.5 去中心化的治理技术 / 207
5.4.6 去中心化的数据管理 / 209
5.4.7 基础设施自动化 / 209
5.4.8 容错设计 / 210
5.4.9 演化式设计 / 211
5.5 原则和特性带来的优势 / 212
5.5.1 组件可由不同技术栈实现 / 213
5.5.2 细粒度地按需扩缩容 / 213
5.5.3 局部不可用不会拖累整体 / 214
5.5.4 缩短功能面试时间 / 214
5.5.5 适合大规模团队并行工作 / 215
5.5.6 一个服务可支持多种终端 / 215
5.5.7 服务可由开发团队自治 / 216
5.6 微服务架构不是“银弹” / 216
5.6.1 开发、部署、运维困难 / 216
5.6.2 存在网络延迟 / 219
5.6.3 相比单体架构更加脆弱 / 220
5.6.4 可能出现“孤儿服务” / 220
5.6.5 可被黑客攻击的点多 / 221
5.7 在这些时候请不要使用微服务 / 222
5.7.1 无法忍受增加的成本 / 222
5.7.2 无法忍受架构复杂度 / 224
5.7.3 无法忍受网络延迟 / 225
5.7.4 无法建立有效的基础设施 / 225
5.7.5 需要强事务一致性 / 226
5.7.6 需要频繁变更接口 / 226
5.7.7 团队规模较小 / 227
5.7.8 初创团队 / 228
5.7.9 缺乏业务知识 / 228
5.7.10 由客户自行安装和管理的软件 / 229
5.8 本章小结 / 229
-
第6章 领域驱动设计与微服务拆分 / 231
6.1 DDD可以用于微服务拆分吗 / 231
6.2 拆分中必用的领域概念 / 233
6.2.1 有效沟通模式：统一语言 / 233
6.2.2 要沟通的对象：实体 / 234
6.2.3 粗粒度的拆分：子域 / 236
6.2.4 中粒度的拆分：限界上下文 / 238
6.2.5 细粒度的拆分：聚合 / 240
6.2.6 避免循环依赖：限界上下文映射图 / 243
6.3 拆分中可用的领域概念 / 244
6.3.1 交互模式 / 244
6.3.2 模块单体的基础：模块 / 246
6.4 拆分中不用的领域概念 / 247
6.4.1 指导编码的值对象 / 247
6.4.2 与微服务中的“服务”不同含义的“服务” / 248
6.5 拆分中可用的设计模式 / 249
6.5.1 分层架构 / 249
6.5.2 六边形架构 / 250
6.5.3 柔性设计 / 252
6.6 再谈DDD中的边界 / 252
6.7 本章小结 / 253
-
第7章 微服务拆分方法 / 254
7.1 领域分析法 / 254
7.1.1 四色建模法 / 255
7.1.2 四色建模法拆分步骤 / 255
7.1.3 事件风暴法 / 256
7.1.4 事件风暴法拆分步骤 / 256
7.1.5 领域分析法的不足 / 257
7.2 笔者总结的微服务拆分五步法 / 258
7.3 第一步：预备 / 258
7.3.1 组建架构开发团队 / 259
7.3.2 评估企业能力成熟度 / 259
7.3.3 界定架构范围及识别相关方 / 260
7.3.4 识别和定义架构原则 / 261
7.4 第二步：开发业务架构 / 262
7.4.1 粗粒度地拆分业务子域 / 262
7.4.2 选择一个核心子域并遍历其中的场景 / 263
7.4.3 分析每个场景中的用例 / 264
7.4.4 为不同的视角建立相应的视图 / 266
7.5 第三步：领域分析 / 266
7.5.1 识别领域事件 / 267
7.5.2 识别决策命令 / 268
7.5.3 识别领域名词 / 268
7.5.4 根据领域名词识别聚合 / 268
7.5.5 拆分限界上下文 / 268
7.6 第四步：开发非业务架构 / 269
7.6.1 开发数据架构 / 269
7.6.2 开发应用架构 / 270
7.6.3 开发技术架构 / 270
7.7 第五步：用非业务架构审查拆分结果 / 270
7.7.1 消除循环依赖 / 271
7.7.2 审查是否满足非业务架构 / 271
7.8 案例及内容模板 / 272
7.8.1 案例背景介绍 / 272
7.8.2 案例拆分第一步：预备 / 272
7.8.3 案例拆分第二步：开发业务架构 / 276
7.8.4 案例拆分第三步：领域分析 / 281
7.8.5 案例拆分第四步：开发非业务架构 / 285
7.8.6 案例拆分第五步：用非业务架构审查拆分结果 / 286
7.8.7 案例小结 / 288
7.9 本章小结 / 289
-
第8章 微服务治理实践指南 / 291
8.1 基础设施治理 / 291
8.1.1 资源治理 / 291
8.1.2 运行环境治理 / 293
8.1.3 容量治理 / 294
8.1.4 安全治理 / 295
8.2 微服务基础能力治理 / 295
8.2.1 服务注册 / 295
8.2.2 服务发现 / 301
8.2.3 服务通信 / 304
8.2.4 负载均衡 / 305
8.3 微服务一般能力治理 / 305
8.3.1 服务鉴权 / 306
8.3.2 流量控制 / 308
8.3.3 服务路由 / 311
8.3.4 熔断隔离 / 312
8.3.5 服务容错 / 314
8.4 微服务高级能力治理 / 314
8.4.1 单元化 / 315
8.4.2 滚动更新 / 316
8.4.3 优雅下线 / 317
8.4.4 健康检查 / 317
8.4.5 自动伸缩 / 318
8.4.6 故障注入 / 319
8.5 本章小结 / 320
-
第9章 微服务架构实践指南 / 321
9.1 微服务应该如何开始 / 321
9.1.1 正确认识微服务 / 321
9.1.2 调整组织架构 / 323
9.1.3 充分授权 / 324
9.1.4 提升团队技能 / 325
9.1.5 建设基础设施 / 326
9.1.6 从试点开始 / 327
9.2 如何应用微服务 / 329
9.2.1 坚守原则 / 329
9.2.2 管理例外 / 330
9.2.3 避免过早拆分 / 332
9.2.4 建立开发环境 / 333
9.2.5 适时地偿还“技术债务” / 335
9.2.6 信息隐藏 / 336
9.2.7 保持接口稳定 / 337
9.2.8 管理代码所有权 / 338
9.2.9 内部开源 / 340
9.3 如何上线微服务 / 341
9.3.1 测试左移 / 341
9.3.2 自动化必不可少 / 344
9.3.3 拥抱云原生 / 344
9.3.4 应用DevOps / 344
9.3.5 不断提升系统的可观测性 / 345
9.4 如何管理微服务 / 346
9.4.1 应用企业架构标准 / 346
9.4.2 安装“架构师电梯” / 346
9.4.3 拥抱敏捷 / 347
9.4.4 建立服务看板 / 349
9.4.5 建立技术委员会 / 350
9.4.6 建立团队分类机制 / 350
9.5 如何迁移单体应用 / 351
9.5.1 明确迁移的目的 / 352
9.5.2 评估是否可以迁移 / 352
9.5.3 不要忘记数据库 / 353
9.5.4 逐步迁移的重要性 / 354
9.5.5 模式：模块化单体 / 354
9.5.6 模式：扼杀无花果 / 355
9.5.7 模式：根据抽象建立分支 / 356
9.5.8 模式：并行运行 / 357
9.5.9 模式：装饰者 / 357
9.5.10 模式：扼杀数据库 / 358
9.5.11 模式：数据视图 / 359
9.5.12 模式：数据服务 / 359
9.5.13 模式：接口数据库 / 360
9.5.14 模式：在应用中同步数据 / 360
9.6 常见问题解答 / 361
Q：什么时候应该使用微服务 / 361
Q：微服务应该有多大 / 361
Q：从新系统还是旧系统开始 / 363
Q：前端如何处理 / 364
Q：先拆代码还是先拆数据库 / 365
Q：整体优化还是局部优化 / 365
Q：如何处理一致性 / 367
Q：该不该用分布式事务 / 368
Q：如何跨服务查询 / 369
Q：是否应以服务复用为重 / 371
Q：是否应该购买微服务平台 / 371
Q：如何技术选型 / 372
Q：系统安全如何保障 / 373
Q：接口需要幂等设计吗 / 373
Q：服务应该是无状态的吗 / 373
Q：异构系统如何管理 / 374
Q：如何管理服务集 / 374
9.7 本章小结 / 376
-
第4篇 企业云原生变革
-
第10章 企业云原生实践指南 / 378
10.1 企业头上的“云” / 378
10.1.1 云计算的定义 / 378
10.1.2 是否要上云 / 380
10.1.3 一朵又一朵的“云” / 383
10.1.4 企业多云 / 386
10.2 混合云的划分方法 / 387
10.2.1 以前后端为界 / 387
10.2.2 以新旧程度为界 / 388
10.2.3 以关键程度为界 / 389
10.2.4 以生命周期为界 / 389
10.2.5 以数据类型为界 / 390
10.2.6 以数据新鲜度为界 / 390
10.2.7 以运营状态为界 / 391
10.2.8 以工作负载为界 / 391
10.3 推动变革的“领导变革八步法” / 392
10.3.1 领导变革 / 392
10.3.2 建立紧迫感 / 393
10.3.3 建立领导团队 / 395
10.3.4 设定愿景战略 / 397
10.3.5 沟通变革愿景 / 399
10.3.6 善于授权赋能 / 401
10.3.7 积累短期胜利 / 402
10.3.8 促进变革深入 / 403
10.3.9 成果融入文化 / 403
10.4 企业云原生成熟度模型 / 404
10.4.1 技术成熟度模型 / 405
10.4.2 组织成熟度模型 / 406
10.4.3 应用成熟度模型 / 406
10.4.4 微服务成熟度模型 / 407
10.5 效果收益评估方法 / 409
10.5.1 评估方法 / 409
10.5.2 设置检查点 / 409
10.5.3 避免沉默成本 / 410
10.6 本章小结 / 410

樊超从事Java应用程序开发和架构设计工作10余年，曾担任某上市公司首席架构师、某互联网企业技术总监等职位。
拥有数项软件开发相关发明专利，作为中国信息通信研究院聘用专家参与云原生相关标准的编写和审核。
目前作为微服务架构师为各大企业提供云原生架构相关的规划和咨询工作。

融合了企业架构和微服务；含服务拆分方法、治理原则、最佳实践在内等细节；尤其适合拥有大量IT资产的非互联网企业中落地微服务。
不想想当架构师的程序员，不是好程序员
企业架构有哪些困境?
企业架构有哪些反模式?
怎么样才是是一个EA架构师?
企业架构的目标有哪些?
云原生能不能拯救企业架构?
我真的需要微服务?
微服务怎么拆拆拆?
拆了又怎么治理?
应以怎样的姿势拥抱云原生?

企业架构，不是学学工具就可以的理论知识对突破架构师瓶颈真的很重要。

本书分析了当今企业架构面临的挑战，介绍了如何使用微服务架构来应对这些挑战。企业在应用微服务时面临许多痛点，本书对痛点出现的原因和场景进行了深入的分析，提出了可用于消除或缓解痛点影响的模式。 本书内容注重理论和实践的结合。在理论方面，介绍了企业架构标准、云原生思想和相关技术、微服务的前世今生，以及领域驱动设计等；在实践方面，介绍了用于拆分微服务的“五步法”、包含4个维度的“企业云原生成熟度模型”，以及衡量企业变革成果的“效果收益评估方法”等。 本书的核心内容包括：企业架构的定义与企业架构师的职责；企业架构是否设计良好的评判依据；云原生的相关思想和技术；微服务的起源、演化、特性、拆分方法和落地指南；云原生为企业带来的机遇与变革等。 本书可以帮助企业明确痛点、制定原则、规划路径、建设能力和评估成效，最终实现微服务架构在企业中的持续运营和持续演化，从而应对日益增多的业务挑战。

"不想想当架构师的程序员，不是好程序员 企业架构有哪些困境? 企业架构有哪些反模式? 怎么样才是是一个EA架构师? 企业架构的目标有哪些? 云原生能不能拯救企业架构? 我真的需要微服务? 微服务怎么拆拆拆? 拆了又怎么治理? 应以怎样的姿势拥抱云原生? 企业架构，不是学学工具就可以的 理论知识对突破架构师瓶颈真的很重要。"