第1 篇 架构方法论

1 有关架构的概念认知.. 2

1.1 引言.. 2

1.2 认识架构... 2

1.3 规划、架构与设计 4

1.3.1 三个不同层次的概念 4

1.3.2 规划与架构 4

1.3.3 架构与设计 5

1.4 解耦与服务化... 6

1.5 分工与组件化... 6

1.6 集中与分布... 7

1.7 规划还是演化... 8

1.8 简化也很必要... 9

1.9 架构与软件开发（软件过程） .11

1.9.1 敏捷软件开发11

1.9.2 敏捷软件开发与微服务架构..12

1.10 探讨传统企业IT 系统架构.12

1.10.1 从架构角度解决企业应用痛点.13

1.10.2 企业应用系统架构服务化迁移步骤...13

1.10.3 企业应用系统架构服务化参考模型...14

1.11 总结....15

2 以终为始的架构设计..16

2.1 缘起.16

2.2 我们的思考方式....17

2.3 为什么要做架构设计18

2.3.1 由模型到实施18

2.3.2 业务规模发展带来的复杂度..19

2.3.3 从沟通视角看软件架构20

2.4 如何做架构设计....20

2.4.1 以终为始，不忘初心....21

2.4.2 PMC 框架..21

2.4.3 从多视角、多层次看架构.23

2.4.4 满足利益相关者的需要25

2.4.5 聚焦SLA..26

2.4.6 抽象、协作、扩展、复用.28

2.4.7 分析全息视图29

2.5 架构是什么..29

2.5.1 架构兼具组成和决策的特点..30

2.5.2 架构是演进来的..30

2.5.3 无纯粹的非功能特性....31

2.6 总结.32

3 闭环架构方法34

3.1 系统提升的一般性方法和反馈环..34

3.2 产品创新闭环..36

3.3 组织闭环..37

3.4 研发流程闭环..39

3.5 系统架构闭环..40

3.6 一个反馈闭环实例....41

3.7 总结.44

4 复杂与架构演进的关系..46

4.1 什么是复杂..46

4.1.1 规模47

4.1.2 结构51

4.1.3 变化58

4.2 用架构思维控制复杂67

4.2.1 分而治之，控制规模....67

4.2.2 保持架构的清晰与一致67

4.2.3 拥抱变化..70

4.3 总结.71

5 架构师的核心能力.72

5.1 架构师承担的职责....72

5.2 架构师的核心能力....73

5.2.1 经验73

5.2.2 沟通74

5.2.3 快速学习..74

5.2.4 解决问题的能力..76

5.3 架构能力的修炼....76

5.4 总结.77

第2 篇 面向架构的架构（微服务）

6 快速继承微服务实践..80

6.1 概述.80

6.2 我们希望的微服务是什么样子的..81

6.3 实现微服务..82

6.4 实现的考量及调研....83

6.4.1 gRPC 有什么问题....83

6.4.2 如何提高易用性..83

6.5 让微服务快速落地....87

6.6 总结.89

7 微服务架构下的事务处理...90

7.1 概述.90

7.2 使用传统的本地事务和分布式事务保证一致性....90

7.3 在微服务架构中应满足数据最终一致性原则....92

7.4 微服务架构实现最终一致性的三种模式...92

7.4.1 可靠事件模式93

7.4.2 业务补偿模式...101

7.4.3 TCC（Try-Confirm-Cancel）模式.106

7.5 总结....109

8 微服务架构模式与实践110

8.1 微服务的主要架构模式...110

8.1.1 一体化模式..110

8.1.2 聚合模式.110

8.1.3 代理模式.111

8.1.4 资源共享模式...112

8.1.5 异步消息模式...112

8.2 大量微服务带来的挑战...112

8.3 微服务在好雨的解决方案...113

8.3.1 服务发现和注册113

8.3.2 弹性伸缩与负载均衡..115

8.3.3 容错处理（断路器与限流）116

8.3.4 监控与报警..116

8.3.5 数据存储与共享116

8.3.6 日志分析.117

8.4 总结....118

9 微服务与DevOps 架构实践.119

9.1 概述....119

9.2 某金融创业公司的微服务架构选型122

9.3 设计思想124

9.4 总体架构125

9.4.1 总体架构的特性125

9.4.2 具体实现.126

9.5 对微服务的支撑..128

9.6 DevOps 平台总体架构130

9.7 面向微服务的研发团队介绍....131

9.8 总结....133

10 基于云的微服务架构..134

10.1 概述..134

10.2 德比软件数据对接平台的架构..134

10.3 德比软件微服务架构基础设施..135

10.4 API 网关...136

10.5 服务框架..136

10.5.1 高可用RPC137

10.5.2 服务依赖管理.138

10.6 基础服务..140

10.6.1 配置中心....140

10.6.2 安全数据服务.141

10.6.3 数据存储服务.141

10.6.4 订单服务....142

10.7 服务降级..142

10.8 自动化..142

10.9 日志处理..143

10.10 调用链追踪.144

10.11 服务健康状态..144

10.11.1 报警....144

10.11.2 监控....145

10.12 发布管理146

10.13 总结....147

11 Service Fabric：平台架构解析...148

11.1 Service Fabric 概述148

11.1.1 Service Fabric 的特点148

11.1.2 Service Fabric 的适用场景..149

11.2 Service Fabric 编程模式.150

11.3 Service Fabric 服务通信.152

11.3.1 Service Fabric 的微服务开发工具153

11.3.2 对Service Fabric 的微服务进行监控和诊断...153

11.4 Service Fabric 可靠服务概述.154

11.4.1 Service Fabric 可靠服务——有状态服务的体系结构....154

11.4.2 Service Fabric 可靠服务——无状态服务的体系结构....156

11.4.3 Service Fabric 可靠服务——备份157

11.5 Service Fabric 可靠执行组件.157

11.6 Service Fabric 容器应用程序.159

11.7 总结..160

第3 篇 面向业务的架构

12 如何搭建高可伸缩的移动电商架构162

12.1 概述微服务的主要架构模式..162

12.2 移动端的混合架构162

12.3 服务器端的SOA 架构...164

12.4 PC 端和移动端的开发协作管理166

12.5 基于容器的虚拟化166

12.6 关于电商的私有云建设.167

12.7 如何应用弹性云来应对电商大促..169

12.8 应对电商大促峰值的“独孤九剑”...170

13 消费信贷系统“白付美”是如何持续优化的.172

13.1 “白付美”介绍..172

13.2 “白付美”从0 到1....172

13.3 大促期间的性能保证174

13.4 大促期间的稳定性保证.177

13.5 为服务多平台所做的优化.178

13.6 未来的优化方向179

13.7 总结..180

14 美丽联合集团支付系统架构演进....182

14.1 概述..182

14.2 支付系统1.0 .182

14.2.1 业务问题....183

14.2.2 系统问题....184

14.2.3 资金问题....185

14.3 支付系统2.0 .185

14.3.1 拆分系统边界.185

14.3.2 支付系统2.0 系统详解.187

14.3.3 统一平台业务上下文192

14.3.4 直面数据一致性挑战192

14.4 性能提升194

14.5 稳定性提升201

14.5.1 监控先行201

14.5.2 分离核心链路201

14.5.3 服务依赖梳理203

14.5.4 限流降级203

14.6 压测204

14.7 成效204

14.7.1 业务支撑能力204

14.7.2 系统服务能力205

14.8 总结206

15 金融撮合架构.207

15.1 概述207

15.2 系统总体设计208

15.2.1 系统核心模块208

15.2.2 撮合算法设计209

15.2.3 基于内存撮合212

15.2.4 灾备的多机设计.212

15.2.5 状态机复制213

15.2.6 系统架构215

15.3 总结218

第4 篇 面向性能的架构

16 一线架构师带你玩性能优化.220

16.1 什么是系统优化220

16.2 系统优化的方法论、思路和原则.220

16.2.1 常用方法论221

16.2.2 优化思路221

16.2.3 优化原则222

16.3 性能优化222

16.3.1 常见的性能问题.222

16.3.2 性能优化的具体工作.223

16.3.3 JVM 优化.230

16.3.4 数据库优化233

16.3.5 负载均衡优化235

16.4 总结237

17 性能优化的常见模式及趋势.238

17.1 性能优化的优缺点.238

17.2 性能优化的两种模式239

17.3 单应用优化239

17.3.1 优化的基本思路.239

17.3.2 确定性能瓶颈/热点的常见方法240

17.3.3 压测时通常观察的内容及其所使用的工具.240

17.3.4 常见的优化手段及模式.240

17.4 结构型优化241

17.5 两个结构型优化的案例245

17.5.1 处理单点/网络瓶颈的可行方式245

17.5.2 处理数据库连接池瓶颈的可行手段.245

17.6 总结247

18 性能优化之几种常见的压测模型及其优缺点248

18.1 压测模型抽象248

18.1.1 压测环境准备249

18.1.2 压测任务准备249

18.1.3 压测执行闭环249

18.2 线下压测模型250

18.3 线上引流压测模型.251

18.4 线上全链路压测模型252

18.5 总结253

19 缓存为王——无线缓存架构优化254

19.1 无线缓存的定义、限制条件及影响.254

19.2 无线缓存要从全局考虑254

19.2.1 服务器端架构对无线缓存的影响.254

19.2.2 无线缓存对服务器端架构的影响.255

19.2.3 大流量下无线缓存作用的劣化.256

19.2.4 无线缓存与本机移动端组件的关系.256

19.2.5 无线缓存存储介质的选择.257

19.3 数据、资源缓存及失效策略.257

19.3.1 架构详论257

19.3.2 实现失效策略259

19.4 总结263

本书从架构设计概念、方法、模式、实践案例等4 个方面进行阐述，内容丰富，是一本可以很好指导实践的书籍，更是各位资深专家和架构师的经验总结。 本书共分为4 部分：第一部分介绍架构设计的概念、方法论，以及架构师的核心能力；第二部分介绍微服务架构选型、架构模式与实践、数据一致性保证、微服务与DevOps 的关系以及如何设计云微服务架构；第三部分介绍移动电商、消费信贷、支付系统、金融撮合等领域的优秀实践；第四部分介绍优化系统架构性能的方法论、案例、关键技术等。本书适合即将步入架构领域的技术专家，以及致力于提升软件架构设计能力的架构师、设计人员和开发人员阅读，希望本书能够为读者的实际工作和个人成长提供帮助。

在建立虚拟基础架构时,有许多设计要素会有助于形成稳健的最终部署，确保虚拟基础架构长期稳定运行。

虚拟基础架构从底层硬件直到上层的虚拟化软件，有太多因素都需要在规划虚拟基础架构时认真考虑。探讨怎样运用虚拟基础架构逐层分析的方法实现一个新的虚拟基础架构部署，同时提出产品选型、环境规划战略。

需要作出的关键决策之一就是：选定虚拟基础架构平台。虚拟基础架构层负责协调每个运行在您的虚拟基础架构中的虚拟的工作负荷。在为您的虚拟基础架构方案选择一个虚拟基础架构平台之前，请基于您当前和未来的IT工作负载评估扩展性：这些负载如何装载到软件空间来提供软件定义的服务，虚拟基础架构是否能被管理层平台操控，是否能提供足够的计算功能，是否有足够的性能来支持您的应用在虚拟基础架构环境中运作。

由于虚拟基础架构主机需要物理硬件，您当然总会期望能在每个物理主机上尽可能合理地放置最高数量的虚拟机。

您可能会想要了解您的虚拟基础架构组织的历史增长率，以及任何虚拟基础架构扩张计划。例如，如果您的公司计划启用另一个分支机构，通过向虚拟基础架构层中新增一台虚拟化主机，您应该能轻松搞定。相反，如果您打算关闭一个业务部门，您也应该能够轻松地缩减规模。在虚拟基础架构管理程序层向上和向下扩展的灵活程度是选择虚拟基础架构管理工具时需要考虑的重要因素。

此外，这也是为虚拟基础架构方案提升工作负载可用性的好思路。当您的虚拟基础架构平台有更新发布时，当前的虚拟基础架构主机将需要进行升级。在虚拟基础架构主机升级期间，保障运行中的虚拟基础架构的工作负载的可用性至关重要。物理主机必须组成集群来实现高可用性，虚拟基础架构平台必须提供提供故障转移功能以确保工作负载可以在升级之前迁移到另一台主机。

注意不要被（供应商）锁定。市场上的虚拟基础架构供应商并不算少。虽然VMware继续维持虚拟基础架构主导地位，但许多组织计划将VMware vSphere和Microsoft HYPER-V混合部署。

但这是一个好办法吗？某些虚拟基础架构计算功能只有只有特定的虚拟化厂商能够实现。例如，VMware 和 HYPER-V 有 SR-IOV 功能，提高了虚拟基础架构资源密集型应用程序的性能。但是VMware不支持实时迁移虚拟机，而 HYPER-V 不支持为 Linux虚拟机启用SR-IOV 功能。

另一个要考虑的虚拟基础架构设计问题是应用程序的支持。您的业务流程应用程序可能会在您当前部署的虚拟基础架构主机上成功运行，但如果软件需要升级怎么办？您可能需要跟您的虚拟基础架构应用程序供应商沟通，了解他们的虚拟基础架构升级细节，虚拟基础架构升级变化是否会影响到您托管的特定的应用程序。

许多虚拟基础架构应用程序供应商开始采用新的集装箱化开发方法。因此，您可能希望虚拟基础架构部署支持应用集装箱化的虚拟化服务器/主机。

利用不同虚拟基础架构供应商的软件部署虚拟化主机的一个附带好处是，如果在未来某一时刻您的组织决定实施虚拟基础架构私有云，您将拥有更多选择余地。

并非所有虚拟基础架构公共云提供商都能支持源自每一家虚拟基础架构上的工作负载。例如，如果您在HYPER-V 虚拟机上承载您的虚拟基础架构应用程序，并打算迁移到亚马逊EC2公共云，您就需要对这些虚拟机进行转换，才能被基于 Xen 的亚马逊 EC2支持。

由虚拟基础架构主机提供的两个最重要的服务是：存储和网络。

虚拟基础架构存储服务为存储协议、存储阵列和存储网络提供必要的支持。您对虚拟基础架构的选择会直接影响到物理存储层。例如，如果虚拟基础架构部署在一个虚拟化主机上的存储服务程序对存储协议和存储阵列缺乏支持，您就无法访问和利用虚拟基础架构底层物理存储基础设施——您的整个基础架构可能需要进行升级。

您应该选择具备以下特征的虚拟基础架构主机，可以不停机在线扩展存储，整合的物理存储层同时支持数据块存储和文件的存储、更大的虚拟化负载容量。别担心虚拟基础架构空间耗尽。您可以在随时为虚拟基础架构工作负载增加存储资源，但虚拟基础架构物理主机是否支持存储扩展是个问题。如果物理主机不支持存储动态扩展，虚拟基础架构管理将会很艰难。

同时，网络服务层必须提供必要的协议才能支持对物理网络基础设施的管理，同时对虚拟基础架构主机上运行的虚拟机提供网络隔离。

融合的虚拟基础架构具有成本效益并能提供灵活的管理。传统的方法是，通过规划每个虚拟基础架构网络部件的冗余来组建一个高可用和冗余的网络。例如，许多组织使用单独的交换机、网络路径和线缆来部署专用的以太网网络。虽然这办法能有效解决当前虚拟基础架构问题，却难以有效地适应未来虚拟基础架构网络的变化。冗余控制由物理网络层完成，这就增加了在网络组件管理方面的开销。

大多数虚拟基础架构供应商支持融合网络架构，此场景下存储和网络的流量将共用相同的交换机和线路。虚拟基础架构要求您用单个网络适配器来承载各种流量，如群集、虚拟机、管理，等等。

另外，对于虚拟基础架构的场景中，不同的流量需要隔离，理解这一点很重要。这是虚拟基础架构提供某些服务质量功能的必要方法。

架构分析常见的分类有政府CIO架构分析、IT网络架构分析，下面分别对其进行介绍。

架构分析政府CIO架构分析

我国内地的信息化建设起步于20世纪80年代初期。信息技术和互联网的发展为电子政务的发展实施提供了技术条件和平台环境，同时，经济体制的变革也对行政管理提出新的要求。我国加入WTO后，在政务信息化建设上要与国际接轨，需要加快实施电子政务和推进政府职能转变。

政府信息化的各项工作离不开政府信息主管（政府CIO）的有效推进，但在我国政府现行的管理体制中，并没有“政府CIO”的说法，大多数称谓是“IT主管”、“信息中心主任”“信息处处长”、“科技处处长”、“信息公开处处长”或“信息办主任”之类。但从人们对于他们所承担的职责及其角色的描述，可以看出他们实际上是承担了“政府CIO”这么一个角色。这种不同的称谓反映了我国政府信息化制度中，对于完善的CIO组织架构所形成的不同需求。为了使政府CIO的工作得以顺利开展，就必须建立与之相适应的、行之有效的组织机构，来规划、实施信息化的战略。

经过对国内政府机构信息资源管理和电子政务相关部门调研发现，目前国内政府CIO的主要组织结构分以下几种：

（1）“信息办 信息中心”结构

这种结构下的政府信息化工作主要由信息化领导小组及“信息化办公室”组成，信息化办公室下设“信息中心”。　（2）“信息办”主导型

这种结构下的政府信息化工作主要由信息化领导小组及“信息化办公室”组成，信息化办公室下没有“信息中心”。

（3）“信息中心”主导型

这种结构下的政府信息化工作主要由信息化领导小组及“信息中心”组成，没有信息化办公室。

（4）“职能处室”主导型

这种结构下的政府信息化工作主要由信息化领导小组及相关职能处室组成，没有信

息化办公室和信息中心。具“职能处室”主导型主要包括两种：一种是以科技处为代表的职能处室主导型，一种是以办公室或秘书处为代表的职能处室主导型。

形成以科技处为代表的“职能处室主导型”的主要原因，是由于某些单位以前的业务中涉及到专业技术的应用，职能部门中有技术处这一部门，因此，在政府信息化的时候，就将与信息技术有关的管理工作全部放在科技处下。典型的单位是公检法。

以办公室或秘书处为代表的职能处室主导型则由办公室或秘书处中的某一个人来承担信息化的工作，这种类型的单位一般是信息化程度比较低，应用相对简单。不需要专门的部门和专门的人员来进行管理。

（5）“职能处室 信息中心”型结构

“职能处室 信息中心”型结构也主要包括两种：一种是以科技处为代表的职能处室 信息中心，一种是以办公室或秘书处为代表的职能处室 信息中心。

（注：虚线表示信息中心并不是直接在其下面的部门，而是在业务上服从的关系）

（6）业务部门主导型

这种结构下的政府信息化工作主要由信息化领导小组及业务部门组成。具

架构分析IT架构分析

BI(Business Intelligence)一词是由Howard Dresner在1989提出的，用来描述一种透过特定的概念与方法，让企业制定决策时能立基于事实基础之上。

为了实现这个目标，软件商各自发展出BI的解决方案，实现的技术各有擅长，但简单而言，便是从搜集数据、整理数据、分析数据的过程，最终再呈现给分析人员。每经过一个步骤，资料数据就好像经过粹练一样，更具价值。

从IT系统的角度而言，广义的BI包含了ETL工具、数据仓库(或数据超市)、在线实时分析引擎和动态报表工具。底下我们将从BI架构分析各组件的组成。

（1）ETL工具

ETL是将数据进行撷取、转换与加载的过程，数据撷取必须从不同的数据库、应用程序，甚至是非结构化的文件，取得数据来源;转换则包含了像是格式转换、数据加总、合并或是过滤有问题的数据;加载则是将转换后的数据抛转到数据仓库。

（2）数据仓库/数据超市

数据仓库从定义来说，是具有主题导向、数据整合与时间性的数据库，它和一般在线交易系统(OLTP)不同之处在于，它储存的不是目前营运交易的数据，而是经过整理、汇总后的资料，让不同来源的数据拥有一致性的格式、名称，以免造成混乱。

由于数据仓库以查询为主，修改机会不高，因此专门设计作数据仓库用途的数据库，会针对这个特性去设计加速查询的方法。

数据仓库之外，也有数据超市这个概念相似，但规模较小，应用目的更为明确的数据汇整方式。数据超市虽然有成低本、建置快的优点，然而一旦企业需要跨不同的数据超市才能查询结果时，则会形成瓶颈。

（3）在线实时分析(OLAP)

在线实时分析工具主要是提供使用者可以实时产生多维度的数据，以进行下钻(Drill down)、Slice、Dice、枢纽等种种不同分析。

在线分析工具可以让使用者从不同维度来探索资料，这种分析方式让使用者可以不用依赖IT部门，自行建立问题分析报表，信息的取得更为实时，也更能有效支持决策。

在线实时分析因为数据模型建立的方式不同，可以分为ROLAP、MOLAP。

ROLAP：针对建立在关系型数据库中的数据进行分析

ROLAP指的是关系型在线分析系统，数据仍采用传统关系型数据库的储存方式，再透过中继数据的对应，产生分析所需要的结果。 ROLAP能储存的数据量大，但是效能逊于MOLAP系统。

MOLAP：针对建立在多维度数据库中的数据进行分析

MOLAP指的是多维度在线分析系统，在储存数据时，便是以Cube(立方体)的概念储存，因此在进行多维度分析时便相当容易、快速。 MOLAP虽然速度快，但是受限于数据结构，可以储存的数据量受到限制。另外一旦需要的数据不在原有的维度中，就无法进一步查询。

HOLAP：对储存在两种数据库中的数据进行分析

面对ROLAP和MOLAP各有优、缺点的情况，因而有HOLAP这种混合两者的新在线分析系统出现。检视合计数据时可以透过MOLAP数据库，而需要明细数据时则使用ROLAP数据库，透过这种方式解决鱼与熊掌不可兼得的困境。

（4）动态分析报表

在OLAP之上，有支持实时性分析的动态报表，和过去静态报表不同之处，就在于它能实时呈现分析结构，无需再重新执行报表产生的过程。动态报表除了支持上述的一些分析方式之外，也有越来越多厂商支持灯号、仪表盘、计分卡、地图等种种图形化的接口，让分析结果能更直觉呈现。

推荐序一

如何看到一滴水的美丽

支付宝（中国）公司业务架构师

《大道至简》作者周爱民（aimingoo）

【一】

架构是一个过程，而非一个结果。

【二】

在大多数人的谈论中，架构是一个目标产物，而作为架构师的责任就是去生产它。所以无论如何，架构是可以“做”出来的，而且也应该有一些“做”的方法、技术、技巧。

有人问过我：架构的最主要产出是什么？我的答案是：图。这里面有两层含义：一层含义是如同建筑师描绘的蓝图一样，用于引导实施者；另一层含义是架构师头脑中清晰的目标系统。如果架构师头脑中没有系统清晰的图像，他是没有办法把它画出来的。

【三】

画家画的无非是物我。画物的画家，最终画的还是我见。所以，画家的笔最终描绘的是他自己心里的映像。

【四】

艺术是不可能被“生产”出来的，生产出来的，叫“艺术品”。

【五】

架构这个过程，是架构师洞见系统内在结构、规律、原则和逻辑的过程。真正的架构师是可以将自己放在系统中去的（例如作为系统中的任何一个角色），只有清晰地理解系统，才能简洁地描述它。而当架构师拿出了他所描述的“作品”的时候，架构这一过程就已经结束了。

【六】

一滴水滴落的过程中，有多少个形态的变化？

推荐序二

架构的架构

北京无限讯奇信息技术有限公司产品技术高级总监

黄冬

感谢译者和出版者为我们带来这样一本传奇的架构故事书。

推荐序三

美丽架构之道

《构建高性能Web站点》作者

Web架构实践者

郭欣

我无法给架构下一个简单的定义，因为任何定义都会束缚你对架构的无限想象。不可否认，架构师早已出现在人类几千年前的各项生产活动中，比如建筑、音乐。而在计算机软件及Web领域，架构的设计直接影响着系统的生产，比如开发过程和效率、代码和组件复用性等，同时也影响着系统的可用性、可伸缩性、性能、容量可预测性等。

在本书中，我们更加关注架构之美。美丽的架构同样无法定义，可它却一定是自然的、简单的、可复用的、人文的，甚至是外行人也可以细细品味其思想的。当我看到超市的多个收银台排满长队时，便想到服务器并发处理性能和容量；当我看到十字路口的车辆等待转弯时，便想到它通过缓存思想来提高交通吞吐率。

那么如何设计出美丽的架构呢？从代码逻辑到物理网络，从单机到分布式，无数的技术可供架构师选择，如分层、组件化、服务化、标准化、缓存、分离、队列、复制、冗余、代理等，不过它们仍然只是“术”的范畴，而何时何处如何恰到好处地使用它们才是“道”的范畴，比如顿悟变化的道理，在博弈中寻找平衡，以系统化的角度来分析问题，寻找相对与绝对的奥秘、开放的心态……

然而，这个领域实在是太年轻了，我们需要更多的例子和经验，本书将让你大开眼界！