企业架构与绕不开的微服务（双色）

图书标准信息

• 作者 樊超
• 出版社 电子工业出版社
• 出版时间 2022-03
• 版次 1
• ISBN 9787121430169
• 定价 119.00元
• 装帧 其他
• 开本 16开
• 页数 424页
• 字数 508.8千字

【内容简介】

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

【作者简介】

樊超上海安畅网络科技股份有限公司微服务架构师被中国信息通信研究院聘为可信云标准专家参与编写了《微服务拆分规范指南》《云原生成熟度模型》《微服务应用架构白皮书》等多个行业规范和标准，作为评审专家参与了多个大型企业架构的评级工作

【目录】

★第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  服务