重构到微服务 pdf下载

符合潮流发展的Java微服务框架技术。

微服务已成为当下最Z流行的技术名词之一。

每章带有经典案例，帮助读者逐步掌握。

　　O'Reilly以“分享创新知识、改变世界”为己任。40多年来我们一直向企业、个人提供成功所必需之技能及思想，激励他们创新并做得更好。
　　O'Reilly业务的核心是独特的专家及创新者网络，众多专家及创新者通过我们分享知识。我们的在线学习（Online Learning）平台提供直播培训、互动学习、认证体验、图书、视频，等等，使客户更容易获取业务成功所需的专业知识。几十年来O'Reilly图书一直被视为学习开创未来之技术的资料。我们所做的一切是为了帮助各领域的专业人士学习好的实践，发现并塑造科技行业未来的新趋势。
　　我们的客户渴望做出推动世界前进的创新之举，我们希望能助他们一臂之力。
　　对于单体系统，你是如何来进行梳理并且逐步将它演进到微服务架构的呢？你是如何在保证业务正常进行的同时来做这件事的？
　　作为其畅销著作《Building Microservices》的姊妹篇，《重构到微服务》详细阐释了一种从存量的单体应用迁移到微服务架构的可行方法。
　　《重构到微服务》作为一本改造指南，提供了大量针对如何将单体应用演进到微服务架构的实操建议。书中包含了大量图形化的示例、充满洞见的改造模式、涉及从改造的初始规划阶段到应用系统和数据库的解耦，涵盖了许多场景和策略，它们将帮助你实现成功的改造。
　　你将从《重构到微服务》中学到这些经过实践检验过的模式和技巧。在改造过程，你一定会发现它们非常有价值。
　　适合于期望演进到微服务，而不是重写的组织。
　　帮助组织决策是否要改造、何时改造、以及从哪里入手进行改造。
　　如何解决遗留系统的通信、集成和迁移问题。
　　阐述了若干不同的迁移模式，以及在什么情况下采用这些模式。
　　提供了多种数据库迁移方法的案例，以及对应的同步机制。
　　探索了应用系统解耦的方法，包括若干架构重构的模式。
　　深入探讨了数据库解耦的细节，包括打破参照完整性和事务完整性的影响，新的失败模式等。

作者介绍

经历了几个创业公司，并在Thoughtworks工作了12年之后，目前Sam Newman是一位独立顾问。他专注于微服务、云技术、以及持续交付方面。通过培训和技术咨询服务，Sam帮助分布在全球的客户实现更快且更可靠的软件交付。他是经验丰富的演讲者，曾在全球多个大会上发表演讲。同时，他也是O’Reilly出版的《Building Microservices》一书的作者。

译者介绍

王威，Thoughtworks总监级咨询师，知朴咨询创始人，DDD中国社区联合创始人，Cynefin框架培训讲师，微服务架构、领域驱动设计、遗留系统重构的实践者。

梅雪松，Thoughtworks总监级咨询师，遗留系统现代化服务负责人，微服务架构、领域驱动设计、遗留系统重构的实践者。

姚琪琳，Thoughtworks专家级咨询师，遗留系统现代化服务负责人，极客时间《遗留系统现代化实战》专栏作者，技术书籍译者。

　　★“在这本书中，本书作者为微服务改造定义了清晰的愿景，并且向你展示了在改造过程中需要注意哪些‘坑’（既有很明显的，也有一些比较隐蔽的）。同时，本书也提供了很多组织革新、架构革新、技术革新方面非常有用的参考模式。”
　　——Daniel Bryant，Data Wire和InfoQ的技术顾问（经历几个创业公司，并在Thoughtworks工作了12年之后，目前Sam Newman是一位独立顾问。他专注于微服务、云技术、以及持续交付方面。通过培训和技术咨询服务，Sam帮助分布在全球的客户实现更快且更可靠的软件交付。他是经验丰富的演讲者，曾在全球多个大会上发表演讲。同时，他也是O'Reilly出版的《Building Microservices》一书的作者。）

目录

前言 1

第1 章 刚刚好的微服务 7

1.1 什么是微服务？ 7

1.1.1 部署独立性 8

1.1.2 围绕业务领域建模 8

1.1.3 拥有自己的数据 12

1.1.4 微服务将带来哪些优势？ 13

1.1.5 微服务会带来什么问题？ 13

1.1.6 用户界面 .14

1.1.7 技术 14

1.1.8 颗粒度 15

1.1.9 所有权 17

1.2 单体架构19

1.2.1 单进程单体 19

1.2.2 分布式单体 21

1.2.3 第三方黑盒系统 22

1.2.4 单体架构的挑战 22

1.2.5 单体的优势 22

1.3 关于耦合和内聚 23

1.3.1 内聚 25

1.3.2 耦合 25

1.4 刚刚好的领域驱动设计 .36

1.4.1 聚合 37

1.4.2 限界上下文 38

1.4.3 将聚合和限界上下文映射到微服务 39

1.4.4 延伸阅读 .39

1.5 总结 .40

第2 章 规划迁移到微服务的过程 41

2.1 理解目标41

2.2 为什么要选择微服务？ .43

2.2.1 提高团队自主性 44

2.2.2 缩短上市时间 45

2.2.3 经济高效地扩展负载.46

2.2.4 提高健壮性 47

2.2.5 扩展开发人员的数量.48

2.2.6 拥抱新技术 49

2.3 什么时候微服务可能是个坏主意？.51

2.3.1 不明确的业务领域 .51

2.3.2 初创公司 .52

2.3.3 客户安装和管理的软件 54

2.3.4 没有好的理由！ 54

2.4 权衡利弊54

2.5 带人踏上旅途 .56

2.6 改变组织56

2.6.1 建立紧迫感 57

2.6.2 组建领导团队 58

2.6.3 制定愿景和战略 59

2.6.4 传达变革愿景 59

2.6.5 善于授权赋能 60

2.6.6 快速得到成果 61

2.6.7 促进变革深入 61

2.6.8 成果融入文化 62

2.7 增量迁移的重要性 62

2.8 变更成本64

2.8.1 可逆和不可逆的决定.64

2.8.2 更容易实验的地方 .66

2.9 那么我们从哪里开始呢？ 66

2.10 领域驱动设计 66

2.10.1 你需要走多远？ 67

2.10.2 事件风暴 68

2.10.3 利用领域模型进行优先级排序 68

2.11 一个组合模型 70

2.12 重组团队 .72

2.12.1 改变团队结构 .72

2.12.2 不要一刀切73

2.12.3 做出改变 75

2.12.4 改变技能 78

2.13 你如何知道转型成功与否？ .81

2.13.1 有定期检查点 .81

2.13.2 定量度量 82

2.13.3 定性度量 82

2.13.4 避免沉没成本误区 83

2.13.5 对新方法持开放态度 83

2.14 总结 84

第3 章 拆分单体 87

3.1 单体系统，修改还是不修改？ 87

3.1.1 剪切、复制或者重新开发？ .88

3.1.2 重构单体系统 89

3.2 迁移模式90

3.3 模式：绞杀应用 91

3.3.1 它是如何工作的 91

3.3.2 在哪里使用它 93

3.3.3 示例：HTTP 反向代理 .95

3.3.4 数据 98

3.3.5 代理选项 .98

3.3.6 更改协议 102

3.3.7 示例：FTP 105

3.3.8 示例：消息拦截 106

3.3.9 其他协议 109

3.3.10 绞杀植物模式的其他例子 . 109

3.4 迁移功能时改变行为 110

3.5 模式：UI 组合 . 110

3.5.1 示例：页面组合 111

3.5.2 示例：小部件（Widget）组合 112

3.5.3 示例：微前端 . 115

3.5.4 在哪里使用它 . 116

3.6 模式：抽象分支 . 116

3.6.1 它是如何工作的 117

3.6.2 作为后备机制 . 124

3.6.3 在哪里使用它 . 125

3.7 模式：并行运行 . 126

3.7.1 示例：比较信用衍生品定价 126

3.7.2 示例：Homegate 列表 128

3.7.3 验证技术 129

3.7.4 使用Spy 129

3.7.5 GitHub Scientist 130

3.7.6 灰度发布与金丝雀发布 . 131

3.7.7 在哪里使用它 . 131

3.8 模式：装饰合作者 . 131

3.8.1 示例：会员计划 132

3.8.2 在哪里使用它 . 133

3.9 模式：变更数据捕获 133

3.9.1 示例：发行会员卡 133

3.9.2 实现变更数据捕获 135

3.9.3 在哪里使用它 . 137

3.10 总结 138

第4 章 分解数据库 139

4.1 模式：共享数据库 . 139

4.1.1 应对模式 141

4.1.2 何处使用 141

4.2 但这是不可能做到的! . 141

4.3 模式：数据库视图 . 143

4.3.1 数据库即公共契约 143

4.3.2 通过视图来对外展现 144

4.3.3 限制条件 145

4.3.4 所有权 146

4.3.5 何处使用 146

4.4 模式：数据库包装服务 146

4.5 模式：数据库即服务接口 . 149

4.5.1 实现映射引擎 . 151

4.5.2 与视图相比 . 151

4.5.3 何处使用 151

4.6 转让所有权 152

4.6.1 模式：暴露单体中的聚合 152

4.6.2 模式：变更数据所有权 . 155

4.7 数据同步. 156

4.8 模式：在应用程序中同步数据 158

4.8.1 步骤1：批量同步数据 158

4.8.2 步骤2：同步写入，从旧表结构中读取 159

4.8.3 步骤3：同步写入，从新表结构中读取 160

4.8.4 在哪里使用它（一） 161

4.8.5 在哪里使用它（二） 161

4.9 模式：追踪器写入 . 162

4.9.1 数据同步 165

4.9.2 案例：Square 的订单 . 167

4.9.3 在哪里使用它 . 171

4.10 拆分数据库 . 171

4.11 先拆分数据库，还是先拆分代码？ 173

4.11.1 先拆分数据库 174

4.11.2 先拆分代码 178

4.11.3 将数据库和代码一起拆分 .183

4.11.4 那么，我应该先拆分哪个？ .184

4.12 表结构拆分示例 184

4.13 模式：拆分表 184

4.14 模式：将外键关系移动到代码中 187

4.14.1 移动连表查询 188

4.14.2 数据一致性 190

4.14.3 在哪里使用 192

4.14.4 示例：共享静态数据 192

4.15 事务 201

4.15.1 ACID 事务 .202

4.15.2 仍然保持ACID，但缺乏整体的原子性？ 203

4.15.3 两阶段提交 205

4.15.4 对分布式事务说不 207

4.16 saga . 208

4.16.1 saga 的失败模式 . 209

4.16.2 实施saga 213

4.16.3 saga 与分布式事务 220

4.17 总结 220

第5 章 成长的烦恼 223

5.1 服务越多，痛苦越多 223

5.2 规模化下的所有权 . 225

5.2.1 这个问题如何表现出来？ 225

5.2.2 这个问题什么时候会发生？ 226

5.2.3 潜在的解决方案 226

5.3 破坏性变更 227

5.3.1 这个问题如何表现出来？ 227

5.3.2 这个问题什么时候会发生？ 227

5.3.3 潜在的解决方案 228

5.4 报表 231

5.4.1 这个问题什么时候会发生？ 232

5.4.2 潜在的解决方案 . 233

5.5 监控和故障排除 . 234

5.5.1 什么时候会出现这些问题？ 234

5.5.2 这些问题是如何发生的？ . 235

5.5.3 潜在的解决方案 . 235

5.6 本地开发者体验 . 239

5.6.1 这个问题如何表现出来？ 239

5.6.2 什么时候会出现这些问题？ 239

5.6.3 潜在的解决方案 240

5.7 运行太多东西 240

5.7.1 这个问题如何表现出来？ 241

5.7.2 这个问题什么时候会发生？ 241

5.7.3 潜在的解决方案 241

5.8 端到端测试 242

5.8.1 这个问题如何表现出来？ 243

5.8.2 这个问题什么时候会发生？ 243

5.8.3 潜在的解决方案 243

5.9 全局与局部优化 . 245

5.9.1 这个问题如何表现出来？ 246

5.9.2 这个问题什么时候会发生？ 246

5.9.3 潜在的解决方案 247

5.10 健壮性和弹性 248

5.10.1 这个问题如何表现出来？ . 248

5.10.2 这个问题什么时候会发生？ 249

5.10.3 潜在的解决方案 . 249

5.11 孤儿服务 250

5.11.1 这个问题如何表现出来？ .250

5.11.2 这个问题什么时候会发生？ .250

5.11.3 潜在的解决方案 .251

5.12 总结 252

第6 章 结语 . 255

附录A 参考书目 . 257

附录B 模式列表 . 261

前言

几年前，我们当中的一些人还在讨论微服务是一个有趣的想法。后来的事情你已经知道了，它已经成为全球数以百计的公司的默认软件架构（这当中有许多初创公司，他们创办的目的可能是为了解决微服务引发的问题），并且让每个人在跑去跳上这辆马车的同时，又在担心它最终会消失在地平线上。

我必须承认，造成这种现象，我要承担部分的责任。自从我在2015 年就微服务写了《Building Microservices》一书后，我就靠与其他人合作来帮助人们理解这种架构类型而谋生。我一直在努力，打破对于概念的炒作，而帮助公司决定微服务是否适合他们。对于我的许多拥有现有（并非面向微服务的）存量系统的客户来说，挑战在于如何采用微服务架构。你如何在不停止所有其他工作的情况下，对现有系统进行重新架构？这就是本书的意义所在。同样重要的是，我的目标是给你一个对于微服务架构带来的挑战的诚实的评估，并帮助你了解开始这个旅程是否适合你。

你将学到什么？

本书旨在从思考和执行的维度，深入探讨如何将现有系统分解为微服务架构。我们将触及与微服务架构相关的许多主题，但重点在拆分事物的方面。有关微服务架构的通用性指南，我之前的书《Building Microservices》是一个不错的开始。事实上，我强烈建议你把那本书看作是本书的配套书籍。

第1 章包含了对什么是微服务的概述，以及进一步探讨了导致我们形成这类架构的想法。它对刚接触微服务的读者来说应该很有效，但我同样强烈建议那些有微服务实施经验的人不要跳过这一章。我认为在技术发展的浪潮中，一些重要的微服务的核心思想常常被忽略。这些是本书将反复提到的概念。

了解更多关于微服务的知识是好事，但知道它们是否适合你则是另一回事。在第2 章中，我将指导你如何去评估微服务是否适合你，并为你提供一些真正重要的指导方针，从而管理从单体架构到微服务架构的过渡过程。在这章中，我们将触及从领域驱动设计到组织变革模型的所有内容。即使你决定不采用微服务架构，这些重要的基础也将使你处于有利地位。

在第3 章和第4 章中，我们将深入探讨与拆分单体相关的技术问题。我们会探索一个真实世界的例子，并提取出了迁移的原则。第3 章的重点是应用拆分，第4章是深入研究数据库拆分的技术。如果你真的想从一个单体系统转移到一个微服务架构，我们必须要将数据库拆分开来!

第5 章探讨了随着采用微服务架构的推进而会出现的各种挑战。这些微服务系统可以带来巨大的好处，但同时，许多复杂的问题也会随之而来，这些问题是你之前从未遇到过的。在这一章中，我会帮助你在问题开始出现时就能及时发现它们，并会提供处理微服务带来的痛点难点的相关方法。

O’Reilly 在线学习平台（O’Reilly Online Learning）

近40 年来，O’Reilly Media 致力于提供技术和商业培训、知识和卓越见解，来帮助众多公司取得成功。

公司独有的专家和改革创新者网络通过O’Reilly 书籍、文章以及在线学习平台，分享他们的专业知识和实践经验。O’Reilly 在线学习平台按照您的需要提供实时培训课程、深入学习渠道、交互式编程环境以及来自O’Reilly 和其他200 多家出版商的大量书籍与视频资料。更多信息，请访问网站：https://www.oreilly.com/。

联系我们

任何有关本书的意见或疑问，请按照以下地址联系出版社。

美国：

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

中国：

北京市西城区西直门南大街2 号成铭大厦C 座807 室（100035）

奥莱利技术咨询（北京）有限公司

我们为这本书建立了一个网页，在那里我们列出了勘误表、样例和任何其他信息。

你可以访问这个页面来获取这些信息：https://oreil.ly/monolith-to-microservices。

请发送电子邮件至：errata@oreilly.com.cn，来对本书进行评论或提出技术问题。

关于我们的书籍、课程、会议和新闻的更多信息，请见我们的网站：http://www.oreilly.com。

我们的Facebook：http://facebook.com/oreilly。

我们的Twitter：http://twitter.com/oreillymedia。

我们的YouTube：http://www.youtube.com/oreillymedia。

鸣谢

如果没有我出色的妻子Lindy Stephens 的帮助和理解，这本书是不可能完成的。这本书是为她而写的。Lindy，很抱歉在各种截止日期来来去去时，我是如此的脾气暴躁。我还要感谢可爱的吉尔曼·斯德恩家族的所有支持，我很幸运，有这样一个美好的家庭。

本书极大地受益于那些自愿付出时间和精力去阅读各种草稿并提供宝贵见解的人们。我特别想感谢Chris O’Dell, Daniel Bryant, Pete Hodgson, Martin Fowler,Stefan Schrass 和Derek Hammer 在这方面所付出的努力。还有一些人以多种方式做出了他们的贡献，因此我还要感谢Graham Tackley, Erik Doernenberg,Marcin Zasepa, Michael Feathers, Randy Shoup, Kief Morris, Peter Gillard-Moss,Matt Heath, Steve Freeman, Rene Lengwinat, Sarah Wells, Rhys Evans 和Berke Sokhan。如果你在本书中发现错误，这些错误是我的，不是他们的。

O’Reilly 的团队也给予了我极大的支持，我想重点感谢我的编辑Eleanor Bru和Alicia Young，此外还有Christopher Guzikowski, Mary Treseler 和Rachel Roumeliotis。我还想对Helen Codling 和她在世界其他地方的同事说一声感谢，感谢他们继续带着我的书去参加各种会议，感谢Susan Conant 在不断变化的出版世界中让我保持清醒，感谢Mike Loukides 最初让我参与奥莱利。我知道还有很多人在幕后帮助我，所以也要感谢你们所有人。

除了那些直接为本书做出贡献的人之外，我还想鸣谢其他一些人，不管他们是否意识到，他们都为本书的诞生做出了贡献。因此，我想感谢（排名不分先后）：Martin Kelppmann, Ben Stopford, Charity Majors, Alistair Cockburn, Gregor Hohpe,Bobby Woolf, Eric Evans, Larry Constantine, Leslie Lamport, Edward Yourdon,David Parnas, Mike Bland, David Woods, John Allspaw,Alberto Brandolini, Frederick Brooks, Cindy Sridharan, Dave Farley, Jez Humble, Gene Kim, James Lewis, Nicole Forsgren, Hector Garcia-Molina, Sheep &Cheese, Kenneth Salem, Adrian Colyer,Pat Helland, Kresten Thorup, Henrik Kniberg, Anders Ivarsson, Manuel Pais, Steve Smith, Bernd Rucker, Matthew Skelton, Alexis Richardson, James Governor 和Kane Stephens。

与通常情况一样，我很可能漏掉了某些对这本书做出巨大贡献的人。对于这些人，我只能说很抱歉忘记了感谢你，希望你能原谅我。

最后，有些人时不时地问我写这本书时使用的工具。我使用Visual Studio Code和Jo?o Pinto 的AsciiDoc 插件在AsciiDoc 中写作。这本书是用Git 进行源代码控制的，使用O’Reilly 的Atlas 系统。我主要在我的笔记本电脑上写作，使用外部的Razer 机械键盘，但在最后也大量使用了运行工作副本的iPad Pro 来完成最后几项工作。这使我能够在旅行中写作，有一次，我在去奥克尼群岛的渡轮上写了关于数据库重构的文章，这个经历令人难忘。而由此产生的晕船症状是完全值得的。