全栈开发
Spring Boot+Spring Cloud微服务开发实战
人民邮电出版社
图书在版编目（ClP）数据
Spring Boot+Spring Cloud微服务开发实战/曹军编著.--北京：人民邮电出版社，2020.5
ISBN 978-7-115-53180-3
Ⅰ.①S… Ⅱ.①曹… Ⅲ.①互联网络—网络服务器 Ⅳ.①TP368.5
中国版本图书馆CIP数据核字（2019）第291749号
◆编著 曹军
责任编辑 张天怡
责任印制 王郁 马振武
◆人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 https://www.ptpress.com.cn
涿州市京南印刷厂印刷
◆开本：787×1092 1/16
印张：25.75
字数：465千字 2020年5月第1版
印数：1-2500册 2020年5月河北第1次印刷
定价：79.00元
读者服务热线：(010)81055410 印装质量热线：(010)81055316
反盗版热线：(010)81055315
广告经营许可证：京东工商广登字20170147号
当前互联网在Web框架上已经发展到微服务体系架构。为了帮助广大开发人员快速开展微服务开发，本书主要从Web网站开发的基础知识、Spring Boot相关知识、Spring Cloud相关知识，以及微服务开发实战4个方面，系统地介绍微服务框架中常用的知识点、常用组件，以及程序案例。本书大多章节都先通过一个入门案例引导开发人员快速了解相关组件的功能，在此基础上再对每个知识点进行理论讲解与剖析，最后对该组件进行源码分析，帮助开发人员更加深入地了解每个组件的底层原理，以便更好地进行二次开发。
本书既是初学者学习微服务开发的技术宝典，又是中级开发人员了解微服务体系底层原理的手册。
Foreword
对于企业Web开发，现在流行使用微服务框架，在微服务框架中，主要使用Spring框架。2014年Spring Boot诞生，2018年Spring Boot 2.X版本正式推出。
当前在企业Web开发中主要使用的技术有Spring Boot与Spring Cloud。其中，Spring Boot旨在简化创建产品级的Spring应用和服务，简化配置文件，使用嵌入式Web服务器，含有诸多开箱即用微服务功能。Spring Boot是Spring的一套快速配置工具，可以基于Spring Boot快速开发单个微服务；Spring Cloud是基于Spring Boot搭建的一个更高层次的大型项目，利用Spring Boot的便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，且可以利用Spring Boot做到一键启动和部署，由Spring Boot风格进行再封装，屏蔽复杂的配置和实现原理，最终做成易部署和易维护的分布式系统开发工具包。
本书特色
1.讲授符合初学者的认知规律，由浅入深
作为一本讲微服务开发实战的图书，本书内容由4个部分构成。几乎每一个章节都从入门案例帮助读者快速理解该组件的使用，在调通程序的基础上，本书加深对该组件的深入讲解，剖析知识点，并在最后，根据需要，对源码进行分析，这些知识点主要是针对对源码有兴趣，又不知道如何下手的读者。本书讲解由浅入深，可以帮助初学者快速构建知识体系。
2.以实例引导全程，特别适合初学者学习
作为一个开发人员，我也是从初学者过来的，对如何学好一门技术有着比较深刻的认识。本书建议读者按照本书的实例，慢慢熟悉知识点，然后随着理解的加深，可以书写自己的程序。
3.独有的框架截图，方便重现代码示例
在查找资料的过程中，很多读者难免遇到很多案例，但是学习过程中不能重现；很多时候，在查询的过程中，只能看到程序片段，缺少完整的框架介绍，在重现的时候更是无从下手，感觉程序应该是给有一定基础的开发人员看的。为了避免这种情况，本书在每个章节都会详细说明每段程序的包路径，然后通过每个学习模块的框架截图，直观地让读者认识实例中程序的层级关系，轻松重现书中案例，降低学习难度。
本书读者对象
• 微服务开发入门人员
• 入门编程的学员
• 中级编程的学员
• 在校学生
• 微服务框架研究人员
在当前技术迭代很快的情况下，本书从基础入门开始，然后一步步加深，希望可以把每个知识点描述清楚，希望读者可以快速上手，并加深对每个组件的理解。在本书的编写期间，我查找了很多资料，看过很多源码，使自己对技术的理解更加深刻。读者在学习的过程中可通过QQ（1098447804）获取更多项目源码。不过自己水平有限，本书难免存有疏漏和不当之处，敬请指正。若读者在学习时遇到困难或有任何建议，可发送邮件至zhangtianyi@ptpress.com.cn，希望和所有爱好技术的读者一起进步。
编者
当今大部分互联网企业都使用Java EE技术开发自己的服务，随着框架技术的不断演变，从单体框架，到传统垂直应用框架，再到远程过程调用（Remote Procedure Call, RPC）框架，最后到目前的面向服务架构（Service Oriented Architecture,SOA）框架，互联网框架发展的路已经走了很远。
在本章中，我们将讨论什么是微服务，为什么要使用微服务，以及在使用微服务的过程中将面对的挑战。在理解微服务之后，如果读者对之前的互联网框架发展过程不是很了解，就会觉得有点“晕”。所以，在本章中，会再介绍一下互联网服务框架的演变过程，通过这个过程，读者将会对微服务框架有一个更深的理解。
在介绍完概念后，本章会讲解模块的拆分，这也是开发一个微服务项目要学习的内容，最后会对当前主流的微服务框架进行介绍与总结。本书主要的着力点在于Spring的微服务框架，但是对于其他优秀的微服务框架，我们也需要有一些了解，因为技术是相通的。希望读者学完这本书，也可以做到快速使用其他框架进行业务开发。
在互联网行业，微服务框架是目前最热门的框架之一。这个概念最早是由弗雷德·乔治（Fred George）提出的，然后经过马丁·福勒（Martin Fowler）的推广，微服务才渐渐广为人知。其实，微服务没有多么神秘。本小节会从微服务的定义、特点、优点与挑战方面介绍，带领大家走进微服务的世界。
1.定义
微服务框架是将某个应用程序开发划分为对许多小型服务进行独立开发，这些服务一般围绕业务规则进行构建，可用不同的语言开发，使用不同的数据存储，最终使得每个服务运行在自己的进程中，并且，它们之间采用轻量级通信机制进行通信。
2.特点
● 所有的微服务都能运行在自己的进程中。
● 独立运行的微服务共同构建整个应用系统。
● 独立运行的微服务具备独立进行业务开发的功能。
● 微服务之间通过轻量级通信机制完成通信。
● 可以使用不同的语言编程、多样化数据存储及全自动部署机制。
3.优点与挑战
上面对微服务框架做了一个定义，我们大致可以看出微服务的优点，这里进行明确、系统的说明，优点如下。
● 易于开发和维护：一个微服务只关注一个特定的业务功能，所以它业务清晰，代码量较少，开发和维护单个微服务相对简单。
● 单个微服务启动较快：单个微服务代码量少，所以启动较快。
● 修改程序容易部署：只需要部署对应的微服务模块。
● 技术栈不受限：微服务框架中，结合业务及团队成员的特点选择合理的技术栈进行开发。
● 按需伸缩：可根据需求实现细粒度的扩展。
面临的挑战如下。
● 对多个微服务模块进行运维，复杂度高。
● 服务间的通信，网络成本高。
● 系统的集成测试不方便，没有引用依赖，不能断点调试。
● 数据一致性难保证。
● 性能监控复杂。
对于互联网的框架，我们主要按照Dubbo官网曾经给出的一张图来说明互联网的演变。对于一本讲微服务的图书来说，了解框架的演变是必要的，因为只有了解“曾经”，才能更好理解当下的框架，做到“知其然知其所以然”。
图1.1是按照规模大小进行划分的框架图，对于每一个具体的框架，后面的章节都会具体描述。
图1.1是互联网框架的演变图，目的是让我们更加方便地理解框架的变动。在对象关系映射（Object Relational Mapping,ORM）框架中，我们可以发现只有一个应用程序；模型-视图-控制器（Model View Controller,MVC）框架开始发展成垂直的应用框架；在RPC框架中，开始出现微服务；在SOA框架中，形成了应用与微服务中心交互的概念。
互联网刚诞生时，服务器成本比较高，访问流量也不多，所有的应用程序被放在一起，然后发布到一台服务器上，如图1.2所示。
在图1.2中，所有的应用程序都被放在一起，并且文件和数据库也与应用程序被放在一台服务器上。这样将所有功能都部署在一起，不仅可以减少节点部署和成本，而且可减少输入/输出（I/O）的操作，降低网络通信成本。
此时，这种框架可以满足需求。应用中用于简化“增删改查”工作，数据访问框架（ORM）是关键的一环，因此这种框架被我们称为ORM框架。
当访问量开始增加时，单一应用ORM框架已经不能满足需求，从而成为互联网发展的瓶颈。此时，开发人员想到新的方式来解决，将原本的单个应用拆成互不相干的几个应用，以提升效率，分散流量压力。
通过图1.3可以看到，每个应用都是垂直的，因此，也被称为垂直应用框架。在这种情况下，通过增加机器，我们可以把曾经的单一应用系统分解成子模块，分到各个服务器上。每个子模块都是按照MVC框架进行分层的，就是常说的展示层、控制层以及数据库访问层。
此时，用于提高前端页面开发效率的互联网框架（MVC）是关键，所以，我们常称这种框架为MVC框架。经典的MVC垂直应用框架，通常分为三层。
● 数据库访问层（M）：包含业务数据和执行逻辑。
● 展示层（V）：向用户展示进行用户交互的界面。
● 控制层（C）：用于接收前端的请求，控制后台进行业务处理。
标准的MVC框架并不包括数据库访问层，这里不单独进行说明。通常，在MVC框架中还有专门的ORM框架，这部分一般被放在数据库操作层中，用来屏蔽对底层数据源或者数据库连接池的实现，并直接提供给Service对数据库进行访问，以提升开发效率。
MVC框架可以在单台服务器进行部署，也可以在多台服务器进行部署。但通常情况下，我们会遇到更复杂的并发场景，以及更大的访问流量，这时可使用多台服务器进行集群部署，并采用Nginx等技术进行负载均衡处理。虽然这个框架很不错，但也有其缺点。
● 在应付复杂的业务场景时，开发和维护的成本大大增加。
● 在每个应用中，公共功能重复开发，重复代码多，不利于团队合作。
● 系统的可靠性差，节点的故障会使得整个系统出现雪崩效应。
● 系统开发完成后，对其维护困难，并且在定制化的时候，修改代码会影响整个系统。
那是否还有更好的框架？
在特定时期，MVC框架扮演了重要的角色。上文说过，MVC框架中有一些程序在几个垂直的应用中被重复开发，有些浪费。因此，当垂直应用越来越多时，重复的代码就会越多。所以，开发人员开始把核心业务抽取出来，作为独立的服务使用，并做成一个稳定的服务中心。同时除了核心业务之外，开发人员开始将更多的公共的应用程序接口（Application Programming Interface, API）抽取出来，作为独立的公共服务给调用者调用消费，最终实现服务的共享和重用。这样解决了垂直应用的代码重复问题，也使得前端能够更快地响应市场需求。
然后，根据上文的说法，我们可以抽象出两个重要的对象，分别是提供者和消费者。但实际上，图1.4才是常见的RPC框架，它多一个注册中心（Registry）。
在普及RPC原理之后，很快就有很多RPC框架涌现，在后面介绍的Dubbo就是RPC框架中的典型代表。
RPC这种通信方式的框架，屏蔽了底层的传输协议（TCP/UDP）、序列化技术（XML /Json / ProtoBuf）和通信细节。图1.4只是一幅抽象的原理框架图，那么底层的RPC原理是什么？
图1.5是RPC的底层原理图，学习它有利于帮助我们区分HTTP的通信方式。
在图1.5中可以看到，RP框架主要分为RPC Server与RPC Client两个部分，这里没有注册中心，说明了“直接更加纯净”的原理。
在两个终端中，服务方通过RPC Server导出export远程接口方法，而消费方通过RPC Client引入import远程接口方法。在内部，RPC框架采用接口的代理实现，具体也是两个方面，调用委托给代理RPC Proxy，然后代理封装调用信息并将调用转交给RPC Invoker去实际执行。
在这里还有一个比较重要的点，就是服务方与消费方的通信。在客户端，RPC Invoker通过连接器RPC Connector维持与服务端的通道RPC Channel，并使用RPC Protocol进行协议编码，然后把编码后的请求消息由通道RPC Channel发送到服务方。在服务端，接收器RPC Acceptor接收来自客户端的调用请求，同样使用RPC Protocol执行协议解码，然后把解码后的调用信息传递到RPC Processor控制调用过程，最后委托调用给RPC Invoker执行并返回调用结果。
本地应用通过暴露接口和远程服务的方式去调用，但是在大规模服务时，会出现以下情况。
● 大量的服务配置难以管理。
● 服务间的依赖关系错综复杂，难以分清哪个应用要在哪个应用前启动。
● 服务的调用量越来越大，服务的容量难以估计。
SOA是一个组件模型，是一种粗粒度、松耦合，以服务为中心的框架，接口之间通过定义明确的协议和接口进行通信。
通过上面的定义，我们可以看到，这个框架的重点是以服务为中心。SOA框架以服务为中心，应用直接变成分布式。大规模系统的框架设计原则就是尽可能地拆分，以达到更好的独立扩展与伸缩、更灵活的部署、更好的隔离和容错、更高的开发效率。其核心为分布式框架，拆分策略是横向拆分与纵向拆分。
为了方便说明SOA框架，这里展示其业务横向拆分的框架，如图1.6所示。
从图1.6可以看出，上层是应用系统，中层是暴露的各种接口，底层则是数据库。读者可对比图1.1进行理解，外加上文的说明，就能知道SOA框架的优点。
微服务的目的是有效地拆分应用，实现敏捷开发和部署。但在拆分中会遇到什么问题？我们需要按照什么样的原则进行拆分？本章主要说明在拆分中存在的问题，然后说明针对这些问题，我们采取什么样的原则进行处理。
从单体式结构转向微服务框架中会持续遇到服务边界划分的问题：如果服务的粒度划分过粗，会回到单体式结构的老路；如果过细，服务间调用的开销会变得无法忽视，管理难度也会指数级增加。
同时，如果业务间有太多的事务，使用微服务进行开发的难度的会增加。当然，如果迭代周期长，用户有限，则使用微服务框架没有什么意义。
到目前为止，还没有一个公认的服务边界划分的标准，我们只能根据不同的业务系统加以调节，一般来说，有一些原则可以参考。
在拆分原则中，有下面几个比较出名的原则。
1. AKF扩展立方体
AKF扩展立方体是《架构即未来：现代企业可扩展的Web架构、流程和组织（原书第2版）》一书中提出的可扩展模型，按照这个理论，我们可以将单体系统进行扩展。这个立方体有三条轴线，每条轴线描述扩展性的一个维度，如图1.7所示。
x轴——无限复制服务和数据。
y轴——关注应用中职责的划分，比如数据类型、交易执行类型的划分。
z轴——关注服务和数据的优先级划分。
2.前后端分离
这种原则有很多公司在使用，优势是，在分离模式下，前后端交互使框架更加清晰，前后端得到高效开发；后端的服务简洁明了，方便维护。
前端可以采用多种技术，可以连接多种渠道，而后端服务无须变更，继续采用统一的数据和模型，就可以支撑PC、App等访问。
3.无状态服务
在讲这个原则之前，首先介绍什么是无状态服务。如果一个数据需要被多个服务共享，才能完成一次业务，那么这个数据被称为状态数据。而依赖这个状态数据的服务被称为有状态服务，反之称为无状态服务。
无状态服务原则是要把有状态的业务服务改为无状态的服务，使状态数据也就相应地迁移到对应的有状态数据服务中。我们先看一个图，然后通过图进行说明，如图1.8所示。
在图1.8中，可以看到服务已经前后端分离。这个原则即是把在本地内存中建立的数据缓存、Session缓存数据迁移到分布式缓存中，使服务端变成无状态的节点。采用这个原则的好处是可以做到动态伸缩节点，而微服务应用动态增删节点，可避免考虑缓存数据如何同步的问题。
在认识了微服务之后，下面让我们看看当前的主流微服务框架的实现原理。下文主要介绍Dubbo与Spring Cloud，在此基础上，还会说明底层的通信协议。最后，将针对Spring Boot与Spring Cloud的关系做一个介绍。
Dubbo是比较出名的框架，但这本书不会重点介绍，只做简单说明。
1. Dubbo框架
相信很多人都听说过Dubbo框架，它是开源分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。图1.9是Dubbo官网上的一幅框架图，我们还是根据图进行说明。
从图1.9中可以看出，Dubbo主要分为四个部分（也有人说三个部分）。在框架中，提供者（Provider）提供服务，并将服务注册进注册中心（Registry），然后消费者（Consumer）可以去注册中心订阅服务。同时，监控器（Monitor）可以进行监控，监控对服务的调用次数与耗时。
2.Dubbo的特点
● 远程通信：对多种基于长连接的框架进行封装。
● 集群容错：远程过程调用透明，在集群容错中主要有软负载均衡、失败容错、地址路由、动态配置等策略。
● 自动发现：消费方能动态地查找服务提供方，地址透明。
3.优势
● 使用RPC方式调用，调用性能更高。
● 支持多种序列化协议。
● Dubbo Admin后台管理功能强大。
● 在国内影响力比较大。
先用一句话描述什么是Spring Cloud。Spring Cloud提供全套的分布式系统解决方案，是一个“全家桶”。它在Spring Boot的基础上简化了分布式系统基础设施的开发。如服务发现和服务注册、配置中心、负载均衡、断路器、消息总线、数据监控等，都可以利用Spring Boot做到一键启动和部署。
Spring Cloud并没有做重复性劳动，它只是将开发得比较成熟的服务框架“拿”过来，通过Spring Boot进行再封装，屏蔽复杂的配置和实现原理，最终做成易部署和易维护的分布式系统开发工具包。Spring Cloud具有以下特点。
● 做到了良好的开箱即用，可扩展性机制覆盖。
● 包括服务发现和服务注册。
● 服务地址路由。
● 软负载均衡。
● 断路器。
● 分布式消息传递。
介绍了Dubbo与Spring Cloud之后，我们也已经知道Dubbo使用RPC进行服务之间的调用，以及Spring Cloud使用HTTP进行服务间通信。那么它们的特点和具体的使用场景是什么？
1. RPC的特点
● RPC的核心并不在于使用什么协议。
● RPC可以在本地调用远程的方法，过程是无感的，调用是透明的，并不需要知道调用的方法是部署哪里。
● RPC可以解耦服务接口。
2. 对比
HTTP是超文本传输协议；RPC是远程过程调用，RPC包含传输协议和编码协议。RPC也可以用HTTP作为传输协议，但一般是用TCP作为传输协议，用JSON作为编码协议。
RPC主要用于系统间的服务通信。
3. 使用场景
HTTP接口的使用场景：接口不多、系统与系统交互较少，是解决信息孤岛问题初期常使用的一种通信手段，这种接口简单、直接、开发方便，而且可以利用现有的HTTP进行传输。
然而，如果是一个大型网站，内部子系统较多、服务也非常多，RPC的好处就显示出来了。RPC采用的是长连接机制，不必每次通信都进行3次握手，大大减少网络开销；其次，RPC一般都有注册中心，以及丰富的监控管理，如发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。
RPC主要针对大型企业，而HTTP主要针对小型企业，因为RPC效率更高，而HTTP开发迭代会更快。了解它们的使用场景，可以让我们在项目选型中根据需要更好地进行选择。
本书主要介绍微服务，而且是基于Spring的，这时就需要介绍Spring Cloud，并讲解Spring Cloud的每一个模块。
Spring Cloud是一个微服务开发工具包，提供分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等功能，可降低分布式开发的成本。
首先看Spring Boot是什么。Spring Boot旨在简化创建产品级的Spring应用和服务，可简化配置文件，使用嵌入式Web服务器，含有诸多开箱即用微服务功能。Spring Boot是Spring提供的一套快速配置，可以基于Spring Boot快速开发单个微服务。同时，Spring Boot也是Spring的引导，用于启动Spring，使我们能够快速学习和使用Spring。
Spring Boot与Spring Cloud看起来似乎没有联系，其实不然。Spring Cloud基于Spring Boot，为微服务体系开发中的框架问题，提供了一整套的解决方案。
所以，Spring Cloud是一个基于Spring Boot实现的云应用开发工具。Spring Boot专注于快速、方便集成的个体，Spring Cloud关注全局的服务治理框架；Spring Boot使用默认大于配置的理念，集成方案已经默认选择，不配置也没问题，Spring Cloud大部分是基于Spring Boot来实现的。
因此，微服务离不开Spring Boot，也离不开Spring Cloud。
