springboot与springcloud微服务相关组件的详细介绍（详细总结）
一 SpringBoot
1.1 springboot简介
Spring Boot 是由 Pivotal 团队提供的全新框架，其设计目的是用来简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。
Spring Boot 简化了基于Spring的应用开发，只需要**“run”就能创建一个独立的、生产级别的Spring应用。Spring Boot为Spring平台及第三方库提供开箱即用的设置（提供默认设置），这样我们就可以简单的开始。多数Spring Boot应用只需要很少**（额外）的Spring配置。我们可以使用SpringBoot创建java应用，并使用java –jar 启动它，或者采用传统的war部署方式。
我的理解，就是 Spring Boot 其实不是什么新的框架，它默认配置了很多框架的使用方式，就像 Maven 整合了所有的 Jar 包，Spring Boot 整合了所有的框架。SpringBoot不是对Spring功能的增强，而是提供一种快速使用Spring的开发方式（全新的开发方式）。
1.2 springboot常用注解
springboot注解：
@Service: 注解在类上，表示这是一个业务层bean
@Controller：注解在类上，表示这是一个控制层bean
@Repository: 注解在类上，表示这是一个数据访问层bean
@Component： 注解在类上，表示通用bean ，value不写默认就是类名首字母小写
@Autowired：按类型注入.默认属性required= true;当不能确定 Spring 容器中一定拥有某个类的Bean 时， 可以在需要自动注入该类 Bean 的地方可以使用 @Autowired(required = false)， 这等于告诉Spring：在找不到匹配Bean时也不抛出BeanCreationException 异常。@Autowired 和 @Qualifier 结合使用时，自动注入的策略就从 byType 转变byName 了。@Autowired可以对成员变量、方法以及构造函数进行注释，而 @Qualifier 的标注对象是成员变量、方法入参、构造函数入参。正是由于注释对象的不同，所以 Spring 不将 @Autowired 和 @Qualifier 统一成一个注释类。
@Resource： 按名称装配
区别：
@Resource默认按照名称方式进行bean匹配，@Autowired默认按照类型方式进行bean匹配
@Resource(importjavax.annotation.Resource;)是J2EE的注解，@Autowired(importorg.springframework.beans.factory.annotation.Autowired;)是Spring的注解
@Configuration：注解在类上，表示这是一个IOC容器，相当于spring的配置文件，java配置的方式。 IOC容器的配置类一般与 @Bean 注解配合使用，用 @Configuration 注解类等价与 XML 中配置 beans，用@Bean 注解方法等价于 XML 中配置 bean。
@Bean： 注解在方法上，声明当前方法返回一个Bean
@Scope：注解在类上，描述spring容器如何创建Bean实例。
（1）singleton： 表示在spring容器中的单例，通过spring容器获得该bean时总是返回唯一的实例
（2）prototype：表示每次获得bean都会生成一个新的对象
（3）request：表示在一次http请求内有效（只适用于web应用）
（4）session：表示在一个用户会话内有效（只适用于web应用）
（5）globalSession：表示在全局会话内有效（只适用于web应用）
在多数情况，我们只会使用singleton和prototype两种scope，如果未指定scope属性，默认为singleton
@Value：注解在变量上，从配置文件中读取。
例如：@Value(value = “#{message}”)
@ConfigurationProperties 赋值，将注解转换成对象。给对象赋值。车险项目：HttpClientSetting类
@SpringBootApplication：@SpringBootApplication=@ComponentScan+@Configuration+@EnableAutoConfiguration：约定优于配置
@EnableAutoConfiguration启用 Spring 应用程序上下文的自动配置，试图猜测和配置您可能需要的bean。自动配置类通常采用基于你的classpath 和已经定义的 beans 对象进行应用。被 @EnableAutoConfiguration 注解的类所在的包有特定的意义，并且作为默认配置使用。通常推荐将 @EnableAutoConfiguration 配置在 root 包下，这样所有的子包、类都可以被查找到。
@ComponentScan：注解在类上，扫描标注了@Controller等注解的类，注册为bean 。@ComponentScan 为 @Configuration注解的类配置组件扫描指令。@ComponentScan 注解会自动扫描指定包下的全部标有 @Component注解的类，并注册成bean，当然包括 @Component下的子注解@Service、@Repository、@Controller。
@RestController @RestController 是一个结合了 @ResponseBody 和 @Controller 的注解
@Responsebody 注解表示该方法的返回的结果直接写入 HTTP 响应正文（ResponseBody）中，一般在异步获取数据时使用，通常是在使用 @RequestMapping 后，返回值通常解析为跳转路径，加上@Responsebody 后返回结果不会被解析为跳转路径，而是直接写入HTTP 响应正文中。
@RequestBody
@PathVariable
@RequestParam
两者的作用都是将request里的参数的值绑定到contorl里的方法参数里的，区别在于，URL写法不同。
当请求参数username不存在时会有异常发生,可以通过设置属性required=false解决,例如:
@RequestParam(value=“username”,required=false)
使用@RequestParam时，URL是这样的：http://host:port/path?参数名=参数值
使用@PathVariable时，URL是这样的：http://host:port/path/参数值
不写的时候也可以获取到参数值，但是必须名称对应。参数可以省略不写
@RequestMapping 和请求报文是做对应的
a：value，指定请求的地址
b：method 请求方法类型 这个不写的话，自适应：get或者post
c：consumes 请求的提交内容类型
d：produces 指定返回的内容类型 仅当request请求头中的(Accept)类型中包含该指定类型才返回
e: params 指定request中必须包含某些参数值
f： headers 指定request中必须包含指定的header值
g: name 指定映射的名称
@RequestMapping(method = RequestMethod.GET)
@RequestMapping(method = RequestMethod.POST)
@RequestMapping(method = RequestMethod.PUT)
@RequestMapping(method = RequestMethod.DELETE)
当然也可以使用
@GetMapping
@PostMapping
@PutMapping
@DeleteMapping 这与上面的是一样的效果
@EnablCaching @EnableCaching注解是spring framework中的注解驱动的缓存管理功能。自spring版本3.1起加入了该注解。如果你使用了这个注解，那么你就不需要在XML文件中配置cache manager了。
@suppresswarnings 抑制警告
@Modifying 如果是增，改，删加上此注解
1：方法的返回值应该是int，表示更新语句所影响的行数。
2：在调用的地方必须加事务，没有事务不能正常执行。@Transactional 事务注解
@Query 自定义查询语句 JPQL
JPA注解
@Entity：
@Table(name=“”)：注解在类上表明这是一个实体类。一般用于jpa，这两个注解一般一块使用，但是如果表名和实体类名相同的话，@Table可以省略
@Column：通过@Column注解设置，包含的设置如下
name：数据库表字段名
unique：是否唯一
nullable：是否可以为空
Length:长度
inserttable：是否可以插入
updateable：是否可以更新
columnDefinition: 定义建表时创建此列的DDL
secondaryTable: 从表名。如果此列不建在主表上（默认建在主表），该属性定义该列所在从表的名字。
@Column(name = “user_code”, nullable = false, length=32)//设置属性userCode对应的字段为user_code，长度为32，非空
private String userCode;
@Column(name = “user_wages”, nullable = true, precision=12,scale=2)//设置属性wages对应的字段为user_wages，12位数字可保留两位小数，可以为空
private double wages;
@Id：表示该属性为主键。
@Temporal(TemporalType.DATE)//设置为时间类型
private Date joinDate;
@Transient：表示该属性并非一个到数据库表的字段的映射,ORM框架将忽略该属性。如果一个属性并非数据库表的字段映射,就务必将其标示为@Transient,否则,ORM框架默认其注解为@Basic。@Basic(fetch=FetchType.LAZY)：标记可以指定实体属性的加载方式
@JsonIgnore：作用是json序列化时将Java bean中的一些属性忽略掉,序列化和反序列化都受影响。
@JoinColumn（name=”loginId”）:一对一：本表中指向另一个表的外键。一对多：另一个表指向本表的外键。
@OneToOne、@OneToMany、@ManyToOne：对应hibernate配置文件中的一对一，一对多，多对一。
@GeneratedValue 用于标注主键的生成策略，通过 strategy 属性指定。默认情况下，JPA 自动选择一个最适合底层数据库的主键生成策略：SqlServer 对应 identity，MySQL 对应 auto increment。 在 javax.persistence.GenerationType 中定义了以下几种可供选择的策略：
IDENTITY：采用数据库 ID自增长的方式来自增主键字段，Oracle 不支持这种方式；
AUTO： JPA自动选择合适的策略，是默认选项；
SEQUENCE：通过序列产生主键，通过 @SequenceGenerator 注解指定序列名，MySql 不支持这种方式
1.3 springboot与spring框架的区别
SpringBoot不是Spring官方的框架模式，而是一个团队在Spring4.0版本上二次开发并开源公布出来的。简而言之，SpringBoot就是一个轻量级，简化配置和开发流程的web整合框架。SpringBoot是最近这几年才火起来的，那么它到底与Spring有啥区别呢？想了解区别，其实就是SpringBoot提供了哪些特性：
1.Spring Boot可以建立独立的Spring应用程序；
2.内嵌了如Tomcat，Jetty和Undertow这样的容器，也就是说可以直接跑起来，用不着再做部署工作了；
3.无需再像Spring那样搞一堆繁琐的xml文件的配置；
4.可以自动配置Spring。SpringBoot将原有的XML配置改为Java配置，将bean注入改为使用注解注入的方式(@Autowire)，并将多个xml、properties配置浓缩在一个appliaction.yml配置文件中。
5.提供了一些现有的功能，如量度工具，表单数据验证以及一些外部配置这样的一些第三方功能；
6.整合常用依赖（开发库，例如spring-webmvc、jackson-json、validation-api和tomcat等），提供的POM可以简化Maven的配置。当我们引入核心依赖时，SpringBoot会自引入其他依赖。
二 SpringCloud
(1) SpringCloud介绍
Spring Boot擅长的是集成，把世界上最好的框架集成到自己项目中
Spring Cloud本身也是基于SpringBoot开发而来，SpringCloud是一系列框架的有序集合,也是把非常流行的微服务的技术整合到一起，是属于微服务架构的一站式技术解决方案。
Spring Cloud包含了：
注册中心：Eureka、consul、Zookeeper
负载均衡：Ribbon
熔断器：Hystrix
服务通信：Feign
网关：Gateway zuul
配置中心 ：config
消息总线：Bus
集群状态等等…功能。
2.1 Eureka与zookeeper的区别
2.1.1 了解Eureka
Eureka是Netflix出品的用于实现服务注册和发现的工具。SpringCloud集成了Eureka,并提供了开箱即用的支持。
1.基本原理
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存到本地，下次再调用的时候，直接从本地缓存中读取，完成一次调用。
当服务注册中心Eureka Server监测到服务器提供者因为宕机，网络原因等不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。
服务提供者在启动后，周期性(默认30秒)向Eureka Server发送心跳，以证明当前服务时可用状态。Eureka Server在一定时间(默认90秒)未收到客户端的心跳，则认为服务宕机，注销该实例。
- Eureka工作原理图
2.1.2 Eureka的自我保护机制
在默认的配置中，Eureka Server在默认90秒没有得到客户端的心跳，则注销该实例，但是往往因为微服务跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，但是因为网络分区故障，Eureka Server注销服务实例，则会让大部分微服务不可用，这很危险，因为微服务本身是没有问题的。
为了解决这一问题，Eureka有自我保护机制，Eureka Server通过配置如下参数，可启动自我保护机制
-
eureka.server.enable-self-preservation=true它的原理是，当Eureka Server节点在短时间内丢失过多的客户端时(可能发生了网络故障)，那么这个节点将进入自我保护模式，注册中心不会莽撞注销任何微服务，当网络故障恢复后，该节点会自动退出自我保护模式。
2.1.3 了解Zookeeper
Zookeeper是一个分布式的应用程序协调服务，是集群的管理者，监视着集群中各个节点的状态，根据节点状态的反馈进行下一步合理操作，最终，将简单易用的和性能高效，功能稳定的系统提供给用户。
zookeeper也可以作为注册中心，用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等）每启动一个微服务，就会去zk中注册一个临时子节点，例如：5台订单服务（5台订单服务在zk中的订单目录下创建的5个临时节点），4台商品服务（4台商品服务在zk中的商品目录下创建的4个临时接点）。每当有一个服务down机，由于是临时接点，此节点会立即被删除，并通知订阅该服务的微服务更新服务列表（zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表）每当有一个新的微服务注册进来，就会在对应的目录下创建临时子节点，并通知订阅该服务的微服务更新服务列表（zk上有watch，每当有节点更新，都会通知订阅该服务的微服务更新服务列表，每个微服务30s向zk获取新的服务列表。
2.1.4 Eureka和zookeeper区别
以上两个都是服务注册中心角色，Eureka比Zookeeper好在哪里？
著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)、P（分区容错性）。由于分区容错性是在分布式系统中必须要保证的，因此我们需要在A和C之间进行权衡。Zookeeper保证的是CP，而Eureka保证的是AP.
1.Zookeeper保证CP
当注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但是不能接受服务直接DOWN掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余的节点要重新进行leader选举。问题在于，选举的时间太长，30-120s,并且选举期间整个zk集群式不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，由于网络问题使得zk集群失去master节点式较大概率发生的事情，虽然服务能够最终恢复，但是漫长的选举时间导致注册长期不可用是不能接受的。
2.Eureka保证AP
Eureka正好解决了zk的这一问题，因此在设计时候就优先保证高可用。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka Server注册时如果发现连接失败，则会自动切换到其他节点，只要有一台Eureka Server在，就能保证注册服务可用，只不过查到的信息可能不是最新的。除此之外，Eureka还有一种自我保护的机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现网络故障，此时会出现以下几种情况:
1.Eureka不再从注册列表中移除因为长时间没接收到心跳而应该过期的服务。
2.Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步在其他节点上
3.当网络稳定时，当前实例新的注册信息会被同步到其他节点上。
因此，Eureka可以很好的应对因网络故障倒是部分节点失去联系的情况，而不像zk那样整个注册服务瘫痪。
4.总结
Eureka作为单纯的服务注册中心来说要比zookeeper更加“专业”。因为注册服务更重要的时可用性，我们可以 接受短时间达不到一致性的状况。
2.2 Feign的作用
（1） Feign简介
Feign [feɪn] 译文 伪装。Feign是一个声明式WebService客户端.使用Feign能让编写WebService客户端更加简单,它的使用方法是定义一个接口，然后在上面添加注解。不再需要拼接URL，参数等操作。项目主页：https://github.com/OpenFeign/feign 。
- 集成Ribbon的负载均衡功能
- 集成了Hystrix的熔断器功能
- 支持请求压缩
- 大大简化了远程调用的代码，同时功能还增强啦
- Feign以更加优雅的方式编写远程调用代码，并简化重复代码
（2）实现步骤
1.引入Feign依赖包
2.创建Feign接口,feign接口中需要指定调用的服务名字
3.使用@EnabledFeignClients启用Feign功能
（3）注意点：
@GetMapping注解不支持；
@PathVariable注解需要设置value值；
@RequestParam注解需要设置value值；
接口参数是复杂的JAVA对象的时候，需要采用POST方式请求，且参数名前需要添加@RequestBody注解，且需要保证接口提供者的接口访问方式是POST；
客户端的调用接口的FeignClient接口中，方法名、参数名及参数类型必须和接口方法保持一致；参数名前必须添加@PathVariable或者@RequestParam注解。
FeignClient注解中没有写其他值，则name值只得是服务提供者的服务名称；如果定义了url，则feignClient会查找对应url上的微服务， name此时的值是指feignClient的名称。name值必须填写，还可以设置其他的值，如configuration(feignClient配置：默认是SpringMvcContract)的值；
多个feignCLient类中@FeignClient注解中的name值不能重复，url可以重复；
服务提供者的接口参数可以写在请求路径中，也可不写在请求路径中。
（3）Feign的作用:
不再使用拼接URL的方式实现远程调用，以接口调用的方式实现远程调用，简化了远程调用的实现方式，增强了远程调用的功能，例如：增加了负载均衡、熔断、压缩、日志启用。
2.4 Netflix hystrix作用
（1）雪崩效应：
1.微服务中，一个请求可能需要多个微服务接口才能实现，会形成复杂的调用链路。
2.如果某服务出现异常，请求阻塞，用户得不到响应，容器中线程不会释放，于是越来越多用户请求堆积，越来越多线程阻塞。
3.单服务器支持线程和并发数有限，请求如果一直阻塞，会导致服务器资源耗尽，从而导致所有其他服务都不可用，从而形成雪崩效应；
（2）Hystrix解决雪崩问题的手段，主要是服务降级**(兜底)**，线程隔离；
1.线程隔离：是指Hystrix为每个依赖服务调用一个小的线程池，如果线程池用尽，调用立即被拒绝，默认不采用排队。
2.服务降级(兜底方法)：优先保证核心服务，而非核心服务不可用或弱可用。触发Hystrix服务降级的情况：线程池已满、请求超时。
（3）熔断原理
1.Closed：关闭状态，所有请求正常访问
2.Open：打开状态，所有请求都会被降级。
Hystrix会对请求情况计数，当一定时间失败请求百分比达到阈(yu：四声)值(极限值)，则触发熔断，断路器完全打开
默认失败比例的阈值是50%，请求次数最低不少于20次
3.Half Open：半开状态
Open状态不是永久的，打开一会后会进入休眠时间(默认5秒)。休眠时间过后会进入半开状态。
半开状态：熔断器会判断下一次请求的返回状况，如果成功，熔断器切回closed状态。如果失败，熔断器切回 open状态。
threshold reached 到达阈(yu：四声)值
under threshold 阈值以下
（4）Hystrix的作用:
用于隔离访问远程服务、第三方库、防止出现级联失败也就是雪崩效应。
2.5 zuul
Zuul是Netflix开源的微服务网关，他可以和Eureka,Ribbon,Hystrix等组件配合使用。Zuul组件的核心是一系列的过滤器，这些过滤器可以完成以下功能：
# 身份认证和安全: 识别每一个资源的验证要求，并拒绝那些不符的请求
# 审查与监控：
# 动态路由：动态将请求路由到不同后端集群
# 压力测试：逐渐增加指向集群的流量，以了解性能
# 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求
# 静态响应处理：边缘位置进行响应，避免转发到内部集群
# 多区域弹性：跨域AWS Region进行请求路由，旨在实现ELB(ElasticLoad Balancing)使用多样化
Spring Cloud对Zuul进行了整合和增强。目前，Zuul使用的默认是Apache的HTTP Client，也可以使用Rest Client，可以设置ribbon.restclient.enabled=true.
不同的微服务有不同的网络地址，而外部的客户端可能要调用多个服务的接口才能完成一个业务需求。比如一个电影购票可能调用用户微服务，电影微服务等，如果客户端直接和微服务通信，会存在如下常见问题：
客户端多次请求不同微服务，增加客户端的复杂性
跨域问题，一定场景下处理相对复杂
认证复杂，每个服务都要独立认证
难重构，随着项目迭代，可能需重新划分微服务，重构难以实施
某些微服务可能使用了其他协议，直接访问会有问题
以上问题可以借助微服务网关API Gateway来解决，微服务网关介于客户端和服务器端之间，所有的外部请求都会先经过微服务网关：
这样客户端只需和网关交互，无需直接调用特定微服务的接口，方便监控，易于认证，减少客户端和各微服务间的交互。
Zuul
Zuul作用：
提供统一服务入口，微服务对前台透明
聚合后台服务，节省流量，提升性能
安全，过滤，流控等API管理功能
提供统一服务出口，解耦
过滤器类型：
PRE：这种过滤器在请求被路由之前调用。可利用其实现身份验证等 。
ROUTING： 这种过滤器将请求路由到微服务，用于构建发送给微服务的请求，并使用Apache Http Client或者Netflix Ribbon请求微服务 。
POST：这种过滤器在路由到微服务以后执行，比如为响应添加标准的HTTP Header，收集统计信息和指标，将响应从微服务发送到客户端等 。
ERROR：在其他阶段发生错误时执行该过滤器 。
除了默认的过滤器类型，Zuul还允许创建自定义的过滤器类型。
Zuul高可用
通过将多个zuul节点注册到Eureka Server实现高可用。存在以下两种情况：
Zuul客户端注册到了Eureka Server
Zuul客户端自动从Eureka Server查询Zuul Server列表，并用Ribbon负载均衡请求Zuul集群。
未注册到Eureka Server
微服务可能被其他微服务调用，也可能直接被终端app调用，这种情况，我们需要借助额外的负载均衡器来实现Zuul的高可用，比如Nginx等。
本文参考：https://blog.csdn.net/zhanglh046/article/details/78651993/
2.6 SpringCloudConfig
分布式系统中，由于服务数量非常多，配置文件分散在不同微服务项目中，管理极其不方便。为了方便配置文件集中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Config，它支持配置文件放在配置服务的本地，也支持配置文件放在远程仓库Git(GitHub、码云)。配置中心本质上是一个微服务，同样需要注册到Eureka服务中心！将各个微服务的配置文件集中到一起进行统一管理。
的高可用，比如Nginx等。
[外链图片转存中…(img-ew2YrZaF-1571678846437)]
本文参考：https://blog.csdn.net/zhanglh046/article/details/78651993/
2.6 SpringCloudConfig
分布式系统中，由于服务数量非常多，配置文件分散在不同微服务项目中，管理极其不方便。为了方便配置文件集中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Config，它支持配置文件放在配置服务的本地，也支持配置文件放在远程仓库Git(GitHub、码云)。配置中心本质上是一个微服务，同样需要注册到Eureka服务中心！将各个微服务的配置文件集中到一起进行统一管理。
[外链图片转存中…(img-0fQXfRvK-1571678846438)]