Spring Cloud是分布式微服务架构的一站式解决方案,也可以理解为Spring Cloud是帮我们管理这些微服务的,那么在学习Spring Cloud之前,我们需要具备一些微服务.
Spring Cloud的学习是基于JDK17+进行的
开发环境安装
1.JDK
oracle从JDK9开始每半年发布一个新版本,新版本发布之后,老版本就不进行维护了.但是有几个长期维护的版本 目前,长期维护的版本有:JDK8,11,17,21
在JDK版本的选择上,我们尽量选择长期维护的版本
我们为什么选择JDK17?
Spring Cloud 是基于SpringBoot 进行开发的,SpringBoot3.X以下的版本,Spring官方已经不再维护(还可以继续使用) SpringBoot3.X的版本,使用的JDK版本基线为JDK17
JDK安装和mysql在云服务器上的安装,我们在这里不再过多讲述
简单入门
服务拆分原则
1.单一职责(理想化的形式)
2.服务自治 自己独立治理,每一个服务都可以独立开发,构建,部署,运行测试
3.单向依赖 不能存在循环依赖/双向依赖
循环依赖:A->B->C>A 双向依赖:A->B B->A
如果一些业务场景,存在循环依赖或者双向依赖.采用其他方式解决,比如分布式消息等
微服务架构并无标准架构,合适的才是最好的.在架构设计的过程中,合适的就是最好的,坚持"合适优于业界领先",避免过度设计(为了设计而设计)
工程搭建
方式1:采用ee中讲的方式
方式2:采用父子工程的方式创建
这里我们采用父子工程的方式进行学习
创建父工程
1.创建一个空的Maven项目,删除所有的代码,只保留pom.xml
2.完善pom文件
使用properties来进行版本号的统一管理,使用dependencyMangement来管理依赖,声明父工程的打包方式为pom
这里我们区分dependencies和dependencyManagement
1.dependencies:将所依赖的jar直接加到项目中,子项目也会继承该依赖
2.dependencyManagement:只是声明依赖,并不实现jar包引入,如果子项目需要用到相关依赖,需要显式声明,如果子项目没有指定具体版本,会从父项目中读取version.如果子项目中指定了版本号,就会使用子项目中指定的jar版本,此外父工程的打包方式应该是pom,不是jar,这里需要手动使用packaging来声明
RestTemplate
restTemplate是从spring3.0开始支持的一个HTTP请求,他是一个同步的REST API客户端,提供了场景的REST请求方案的模版
什么是REST?
REST(Representational State Transfer) 表现层资源状态转移
REST是HTTP主要设计者Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格
资源:网络上的数据,比如图片,视频文本等都是资源 URI
表现层:资源的表现形式(文件的表现形式是txt,图片的表现形式是jpg)
还有一些是以json/xml/二进制等表现形式
状态转移:我们通过网络访问资源对资源进行修改(增加/删除等)都会引起资源状态的变化
Rest是一种设计风格,指资源在网络中以某种表现形式进行状态转移
简单来说:REST描述的是在网络中的Client和Server的一种交互形式,REST本身并不实用,实用的是如何设计RESTful API(REST风格的网络接口)
什么是RESTful?
REST是一种设计风格,并没有一个明确的标准.满足这种设计风格的程序或接口(从单词字面来看就是一个形容词)/所以Restful API就是满足REST架构风格的接口
RESTful风格大致有以下几个主要特征:
1.资源:资源可以是一个图片,音频,视频或者JSON格式等网络上的一个实体,除了一些二进制的资源以外普通文本资源更多以JSON为载体,面相用户的一组数据(通常从数据库中查询而得到)
2.统一接口:对资源的操作,比如获取,创建,修改,和删除,这些操作正好对应HTTP协议提供的GET,POST,PUT和DELETE方法,换言之,如果使用RESTful风格的接口,从接口上你可能只能定位其资源,但无法知晓他具体进行了什么操作,需要具体了解其发生了什么操作动作要从其HTTP请求方法类型上进行判断
RestTemplate是Spring提供的,封装HTTP调用,并强制使用RESTful风格,他会处理HTTP连接和关闭,只需要使用者提供资源的地址和参数即可
RESTful实践:
REST风格的API固然很好规范,但大多数的互联网公司并没有按照其规则来进行设计,因为REST是一种风格,而不是一种约束或者规则,过于理想的RESTful API会付出太多的成本
RESTful API 缺点:
1.操作方式繁琐
2.一些浏览器对GET,POST以外的请求不太友好,需要额外处理
3.过分强调资源,而实际业务需求可能比较复杂,并不能单纯使用增删改查就能满足需求,强行使用RESTful API可能会增加开发难度和成本
所以,在实际开发中,如果业务需求和RESTful API 不太匹配或者很麻烦时,也可以不用RESTfulAPI.如果使用场景和REST风格比较匹配,就可以采用RESTfulAPI