Spring Cloud 关键知识点总结
微服务架构发展
1、单体应用架构与微服务应用架构
单体应用优缺点
优点： 项⽬前期开发节奏快，团队成员少的时候能够快速迭代
架构简单：MVC架构，只需要借助IDE开发、调试即可
易于测试：只需要通过单元测试或者浏览器完成
易于部署：打包成单⼀可执⾏的jar或者打成war包放到容器内启动
缺点： 随着不断的功能迭代，单个项⽬过⼤，代码杂乱，耦合严重，开发团队逐渐壮⼤以后，沟通 成本 变⾼， 如：代码从编译到启动耗时达到 3-5 分钟
新增业务困难：在已经乱如麻的系统中增加新业务，维护旧功能，⼀脚踩进去全是不可预测 的问 题。新⼈来了以后很难接⼿任务，学习成本⾼，需要⼤概 ⼀周时间 才能上⼿开发
核⼼业务与边缘业务混合在⼀块，出现问题互相影响，如：⼀个临时活动流量猛涨，机器负 载升 ⾼就会影响正常的业务服务
微服务应用架构优缺点
微服务架构设计的核⼼思想就是“微”，拆分的粒度相对⽐较⼩，这样的话单⼀职责、开发的耦合度就会 降低、微⼩的功能可以独⽴部署扩展、灵活性强，升级改造影响范围⼩。
优点：（1）服务独立部署：每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低
（2）服务快速启动：拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了
（3）更适合敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。
（4）职责专一，由专门的团队负责专门的服务：业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工
（5）服务可以动态按需扩容：当某个服务的访问量较大时，我们只需要将这个服务扩容即可
（6）代码的复用：每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。
缺点：（1）分布式部署，调用的复杂性高：单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。
（2）独立的数据库，分布式事务的挑战：每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理，这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。
（3）测试的难度提升：服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。
（4）运维难度的提升：在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。
微服务架构下，分布式链路跟踪难等；
2、微服务架构中的一些概念
（1）、服务注册于发现
服务注册：服务提供者将所提供服务的信息（服务器IP和端⼝、服务访问协议等）注册/登记到注册中⼼
服务发现：服务消费者能够从注册中⼼获取到较为实时的服务列表，然后根据⼀定的策略选择⼀个服务访问
（2）、负载均衡
负载均衡即将请求压⼒分配到多个服务器（应⽤服务器、数据库服务器等），以此来提⾼服务的性能、可靠性
（3）、熔断
熔断即断路保护。微服务架构中，如果下游服务因访问压⼒过⼤⽽响应变慢或失败，上游服务为了保护 系统整体可⽤性，可以暂时切断对下游服务的调⽤。这种牺牲局部，保全整体的措施就叫做熔断。
（4）、链路追踪
微服务架构越发流⾏，⼀个项⽬往往拆分成很多个服务，那么⼀次请求就需要涉及到很多个服务。不同的微服务可能是由不同的团队开发、可能使⽤不同的编程语⾔实现、整个项⽬也有可能部署在了很多服务器上（甚⾄百台、千台）横跨多个不同的数据中⼼。所谓链路追踪，就是对⼀次请求涉及的很多个服务链路进⾏⽇志记录、性能监控
（5）、API网关
微服务架构下，不同的微服务往往会有不同的访问地址，客户端可能需要调⽤多个服务的接⼝才能完成 ⼀个业务需求，如果让客户端直接与各个微服务通信可能出现：
1）客户端需要调⽤不同的url地址，增加了维护调⽤难度
2）在⼀定的场景下，也存在跨域请求的问题（前后端分离就会碰到跨域问题，原本我们在后端采⽤ Cors就能解决，现在利⽤⽹关，那么就放在⽹关这层做好了）
3）每个微服务都需要进⾏单独的身份认证
那么，API⽹关就可以较好的统⼀处理上述问题，API请求调⽤统⼀接⼊API⽹关层，由⽹关转发请求。 API⽹关更专注在安全、路由、流量等问题的处理上（微服务团队专注于处理业务逻辑即可），它的功 能⽐如
1）统⼀接⼊（路由）
2）安全防护（统⼀鉴权，负责⽹关访问身份认证验证，与“访问认证中⼼”通信，实际认证业务逻辑交移 “访问认证中⼼”处理）
3）⿊⽩名单（实现通过IP地址控制禁⽌访问⽹关功能，控制访问）
3）协议适配（实现通信协议校验、适配转换的功能）
4）流量管控（限流）
5）⻓短链接⽀持
6）容错能⼒（负载均衡）
Spring Cloud基础
1、为什么要学习Spring Cloud
不论是商业应用还是用户应用，在业务初期都很简单，我们通常会把它实现为单体结构的应用。但是，随着业务逐渐发展，产品思想会变得越来越复杂，单体结构的应用也会越来越复杂。这就会给应用带来如下的几个问题：
-
代码结构混乱：业务复杂，导致代码量很大，管理会越来越困难。同时，这也会给业务的快速迭代带来巨大挑战；
-
开发效率变低：开发人员同时开发一套代码，很难避免代码冲突。开发过程会伴随着不断解决冲突的过程，这会严重的影响开发效率；
-
排查解决问题成本高：线上业务发现 bug，修复 bug 的过程可能很简单。但是，由于只有一套代码，需要重新编译、打包、上线，成本很高。
由于单体结构的应用随着系统复杂度的增高，会暴露出各种各样的问题。近些年来，微服务架构逐渐取代了单体架构，且这种趋势将会越来越流行。Spring Cloud是目前最常用的微服务开发框架，已经在企业级开发中大量的应用。
2、什么是Spring Cloud
Spring Cloud 是一系列框架的有序集合，它利用 Spring Boot 的开发便利性简化了分布式系统的开发，比如服务发现、服务网关、服务路由、链路追踪等。Spring Cloud 并不重复造轮子，而是将市面上开发得比较好的模块集成进去，进行封装，从而减少了各模块的开发成本。换句话说：Spring Cloud 提供了构建分布式系统所需的“全家桶”。
注：Spring Cloud其实是⼀套规范，是一套用于构建微服务架构的规范。⽽不是⼀个可以拿来即⽤的框架（所谓规范就是应该有哪些功能组件，然后组件之间怎么配合，共同完成什么事情）。在这个规范之下第三⽅的Netflix公司开发了⼀些组件、Spring官⽅开发了⼀些框架/组件，包括 第三⽅的阿⾥巴巴开发了⼀套框架/组件集合Spring Cloud Alibaba，这些才是Spring Cloud规范的实现。
Netflix搞了⼀套 简称SCN Spring Cloud 吸收了Netflix公司的产品基础之上⾃⼰也搞了⼏个组件 阿⾥巴巴在之前的基础上搞出了⼀堆微服务组件,Spring Cloud Alibaba（SCA）
3、Spring Cloud架构
可以先看下面的图理解一下
上图只是Spring Cloud体系的一部分，Spring Cloud共集成了19个子项目，里面都包含一个或者多个第三方的组件或者框架！
Spring Cloud 工具框架
1、Spring Cloud Config 配置中心，利用git集中管理程序的配置。
2、Spring Cloud Netflix 集成众多Netflix的开源软件
3、Spring Cloud Bus 消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化
4、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的应用程序
5、Spring Cloud Cloud Foundry Service Broker 为建立管理云托管服务的服务代理提供了一个起点。
6、Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul实现的领导选举和平民状态模式的抽象和实现。
7、Spring Cloud Consul 基于Hashicorp Consul实现的服务发现和配置管理。
8、Spring Cloud Security 在Zuul代理中为OAuth2 rest客户端和认证头转发提供负载均衡
9、Spring Cloud Sleuth SpringCloud应用的分布式追踪系统，和Zipkin，HTrace，ELK兼容。
10、Spring Cloud Data Flow 一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。
11、Spring Cloud Stream 基于Redis,Rabbit,Kafka实现的消息微服务，简单声明模型用以在Spring Cloud应用中收发消息。
12、Spring Cloud Stream App Starters 基于Spring Boot为外部系统提供spring的集成
13、Spring Cloud Task 短生命周期的微服务，为SpringBooot应用简单声明添加功能和非功能特性。
14、Spring Cloud Task App Starters
15、Spring Cloud Zookeeper 服务发现和配置管理基于Apache Zookeeper。
16、Spring Cloud for Amazon Web Services 快速和亚马逊网络服务集成。
17、Spring Cloud Connectors 便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。
18、Spring Cloud Starters （项目已经终止并且在Angel.SR2后的版本和其他项目合并）
19、Spring Cloud CLI 插件用Groovy快速的创建Spring Cloud组件应用。
当然这个数量还在一直增加...
4、Spring Cloud综述
1、组件发展历程
Spring Cloud ⽣态圈中的组件，按照发展可以分为第⼀代 Spring Cloud组件和第⼆代 Spring Cloud组件。
| 第⼀代 Spring Cloud（Netflix， SCN） | 第⼆代 Spring Cloud（主要就是Spring Cloud Alibaba，SCA） | |
|---|---|---|
| 注册中⼼ | Netflix Eureka | 阿⾥巴巴 Nacos |
| 客户端负 载均衡 | Netflix Ribbon | 阿⾥巴巴 Dubbo LB、Spring Cloud Loadbalancer |
| 熔断器 | Netflix Hystrix | 阿⾥巴巴 Sentinel |
| ⽹关 | Netflix Zuul：性能⼀般，未来将退出 Spring Cloud ⽣态圈 | 官⽅ Spring Cloud Gateway |
| 配置中⼼ | 官⽅ Spring Cloud Config | 阿⾥巴巴 Nacos、携程 Apollo |
| 服务调⽤ | Netflix Feign | 阿⾥巴巴 Dubbo RPC |
| 消息驱动 | 官⽅ Spring Cloud Stream | |
| 链路追踪 | 官⽅ Spring Cloud Sleuth/Zipkin | |
| 阿⾥巴巴 seata 分布式事务⽅案 |
2、Spring Cloud 组件协同⼯作机制
Spring Cloud中的各组件协同⼯作，才能够⽀持⼀个完整的微服务架构。⽐如
注册中⼼负责服务的注册与发现，很好将各服务连接起来
API⽹关负责转发所有外来的请求
断路器负责监控服务之间的调⽤情况，连续多次失败进⾏熔断保护。
配置中⼼提供了统⼀的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息
5、第一代Spring Cloud核心组件介绍
说明：上⾯提到⽹关组件Zuul性能⼀般，未来将退出Spring Cloud ⽣态圈，所以我们直接就把GateWay划分到第⼀代Spring Cloud 核⼼组件这⼀部分了。
五大重要组件
服务发现——Netflix Eureka
客服端负载均衡——Netflix Ribbon/Feign
服务网关——Netflix Zuul
断路器——Netflix Hystrix
分布式配置——Spring Cloud Config
1、Eureka服务注册中⼼
（1）关于注册中心
注意：服务注册中⼼本质上是为了解耦服务提供者和服务消费者。
对于任何⼀个微服务，原则上都应存在或者⽀持多个提供者，这是由 微服务的分布式属性决定的。 更进⼀步，为了⽀持弹性扩缩容特性，⼀个微服务的提供者的数量和分布往往是动态变化的，也是⽆法 预先确定的。因此，原本在单体应⽤阶段常⽤的静态LB机制就不再适⽤了，需要引⼊额外的组件来管理 微服务提供者的注册与发现，⽽这个组件就是服务注册中⼼。
（2）注册中心原理
分布式微服务架构中，服务注册中⼼⽤于存储服务提供者地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的⽅式获取服务提供者的地址信息，⽽不再需要通过硬编码⽅式得到提供者的地址信息。消费者只需要知道当前系统发布了那些服务，⽽不需要知道服务具体存在于什么位置，这就是透明化路由。
1）服务提供者启动
2）服务提供者将相关服务信息主动注册到注册中⼼
3）服务消费者获取服务注册信息： poll模式：服务消费者可以主动拉取可⽤的服务提供者清单 push模式：服务消费者订阅服务（当服务提供者有变化时，注册中⼼也会主动推送更新后的服务清单给 消费者
4）服务消费者直接调⽤服务提供者 另外，注册中⼼也需要完成服务提供者的健康监控，当发现服务提供者失效时需要及时剔除；
（3）主流服务中⼼对⽐
| 组件名 | 语⾔ | CAP | 对外暴露接⼝ |
| Eureka | Java | AP（⾃我保护机制，保证可⽤） | HTTP |
| Consul | Go | CP | HTTP/DNS |
| Zookeeper | Java | CP | 客户端 |
| Nacos | Java | ⽀持AP/CP切换 | HTTP |
P：分区容错性（⼀定的要满⾜的） C：数据⼀致性 A：⾼可⽤ CAP不可能同时满⾜三个，要么是AP，要么是CP
（4）Eureka 基础架构
（5）Eureka 交互流程及原理
下图是官⽹描述的⼀个架构图
Eureka 包含两个组件：Eureka Server 和 Eureka Client，Eureka Client是⼀个Java客户端，⽤于简化与Eureka Server的交互；Eureka Server提供服务发现的能⼒，各个微服务启动时，会通过 Eureka Client向Eureka Server 进⾏注册⾃⼰的信息（例如⽹络信息），Eureka Server会存储该 服务的信息；
1）图中us-east-1c、us-east-1d，us-east-1e代表不同的区也就是不同的机房
2）图中每⼀个Eureka Server都是⼀个集群。
3）图中Application Service作为服务提供者向Eureka Server中注册服务，Eureka Server接受到 注册事件会在集群和分区中进⾏数据同步，Application Client作为消费端（服务消费者）可以从 Eureka Server中获取到服务注册信息，进⾏服务调⽤。
4）微服务启动后，会周期性地向Eureka Server发送⼼跳（默认周期为30秒）以续约⾃⼰的信息
5）Eureka Server在⼀定时间内没有接收到某个微服务节点的⼼跳，Eureka Server将会注销该微 服务节点（默认90秒） 6）每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的⽅式完成服务 注册列表的同步
7）Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使⽤缓存中的信息找到服务提供者
Eureka通过⼼跳检测、健康检查和客户端缓存等机制，提⾼系统的灵活性、可伸缩性和可⽤性。
EurekaServer和EurekaClient的作用分析
1. EurekaServer提供服务发现的能力，当有服务来注册时，EurekaServer会将这些服务的信息存储到起来。
2. EurekaClient是一个java客户端，可以与服务发现组件来交互。
3. 续约。微服务启动后，会默认底向EurekaServer发送心跳，默认时间为30s,这样的作用就是续约自己的租约。
4. 剔除。如果Eureka在一定时间内没有收到客户端的心跳，那么EurekaServer会剔除掉没有发生心跳客户端,默认时间为90s。
5. 缓存。EurekaClient会缓存服务器的信息，这种方式的好处是当EurekaServer宕机时，，服务消费者依然可以访问服务。
6. eureka 服务器默认是将自身注册到服务器里。可以使用如下代码不讲自身注册进去:
2、Ribbon负载均衡
（1）、关于负载均衡
负载均衡⼀般分为服务器端负载均衡和客户端负载均衡
所谓服务器端负载均衡，⽐如Nginx、F5这些，请求到达服务器之后由这些负载均衡器根据⼀定的算法 将请求路由到⽬标服务器处理。
所谓客户端负载均衡，⽐如我们要说的Ribbon，服务消费者客户端会有⼀个服务器地址列表，调⽤⽅在 请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问，负载均衡算法的执⾏是在请求客户端进⾏。 Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤，Ribbon利⽤从Eureka中读取到 服务信息，在调⽤服务提供者提供的服务时，会根据⼀定的算法进⾏负载。
（2）、Ribbon介绍
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。
简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。
（3）Ribbon负载均衡策略
Ribbon内置了多种负载均衡策略，内部负责复杂均衡的顶级接⼝为 com.netflix.loadbalancer.IRule ， 类树如下
| 负载均衡策略 | 描述 |
| RoundRobinRule：轮询策略 | 默认超过10次获取到的server都不可⽤，会返回⼀个空的server |
| RandomRule：随机策略 | 如果随机到的server为null或者不可⽤的话，会while不停的循环选 取 |
| RetryRule：重试策略 | ⼀定时限内循环重试。默认继承RoundRobinRule，也⽀持⾃定义 注⼊，RetryRule会在每次选取之后，对选举的server进⾏判断， 是否为null，是否alive，并且在500ms内会不停的选取判断。⽽ RoundRobinRule失效的策略是超过10次，RandomRule是没有失 效时间的概念，只要serverList没都挂。 |
| BestAvailableRule：最⼩ 连接数策略 | 遍历serverList，选取出可⽤的且连接数最⼩的⼀个server。该算 法⾥⾯有⼀个LoadBalancerStats的成员变量，会存储所有server 的运⾏状况和连接数。如果选取到的server为null，那么会调⽤ RoundRobinRule重新选取。1（1） 2（1） 3（1） |
| AvailabilityFilteringRule： 可⽤过滤策略 | 扩展了轮询策略，会先通过默认的轮询选取⼀个server，再去判断 该server是否超时可⽤，当前连接数是否超限，都成功再返回。 |
| ZoneAvoidanceRule：区 域权衡策略（默认策略） | 扩展了轮询策略，继承了2个过滤器：ZoneAvoidancePredicate和 AvailabilityPredicate，除了过滤超时和链接数过多的server，还会 过滤掉不符合要求的zone区域⾥⾯的所有节点，AWS --ZONE 在⼀ 个区域/机房内的服务实例中轮询 |
修改负载均衡策略
#针对的被调⽤⽅微服务名称,不加就是全局⽣效
lagou-service-resume:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #负载策略调整（4）Ribbon工作原理
待补充
3、Hystrix熔断器
（1）微服务中的雪崩效应
在微服务架构中，⼀个应⽤可能会有多个微服务组成，微服务之间的数据交互通过远程过程调⽤完成。 这就带来⼀个问题，假设微服务A调⽤微服务B和微服务C，微服务B和微服务C⼜调⽤其它的微服务，这 就是所谓的“扇出”。如果扇出的链路上某个微服务的调⽤响应时间过⻓或者不可⽤，对微服务A的调⽤就 会占⽤越来越多的系统资源，进⽽引起系统崩溃，所谓的“雪崩效应”。
注:扇⼊：代表着该微服务被调⽤的次数，扇⼊⼤，说明该模块复⽤性好 扇出：该微服务调⽤其他微服务的个数，扇出⼤，说明业务逻辑复杂 扇⼊⼤是⼀个好事，扇出⼤不⼀定是好事
（2）雪崩效应解决方案
从可⽤性可靠性着想，为防⽌系统的整体缓慢甚⾄崩溃，采⽤的技术⼿段； 下⾯，我们介绍三种技术⼿段应对微服务中的雪崩效应，这三种⼿段都是从系统可⽤性、可靠性⻆度出 发，尽量防⽌系统整体缓慢甚⾄瘫痪。
服务熔断：熔断机制是应对雪崩效应的⼀种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。⾼ 压电路中，如果某个地⽅的电压过⾼，熔断器就会熔断，对电路进⾏保护。股票交易中，如果股票指数 过⾼，也会采⽤熔断机制，暂停股票的交易。同样，在微服务架构中，熔断机制也是起着类似的作⽤。 当扇出链路的某个微服务不可⽤或者响应时间太⻓时，熔断该节点微服务的调⽤，进⾏服务的降级，快 速返回错误的响应信息。当检测到该节点微服务调⽤响应正常后，恢复调⽤链路。
注意：1）服务熔断重点在“断”，切断对下游服务的调⽤ ；2）服务熔断和服务降级往往是⼀起使⽤的，Hystrix就是这样。
服务降级：通俗讲就是整体资源不够⽤了，先将⼀些不关紧的服务停掉（调⽤我的时候，给你返回⼀个预留的值， 也叫做兜底数据），待渡过难关⾼峰过去，再把那些服务打开。 服务降级⼀般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调⽤，此刻客户端可以⾃⼰准 备⼀个本地的fallback回调，返回⼀个缺省值，这样做，虽然服务⽔平下降，但好⽍可⽤，⽐直接挂掉要强。
服务限流：服务降级是当服务出问题或者影响到核⼼流程的性能时，暂时将服务屏蔽掉，待⾼峰或者问题解决后再 打开；但是有些场景并不能⽤服务降级来解决，⽐如秒杀业务这样的核⼼功能，这个时候可以结合服务限流来限制这些场景的并发/请求量
限流措施也很多，⽐如
限制总并发数（⽐如数据库连接池、线程池）
限制瞬时并发数（如nginx限制瞬时并发连接数）
限制时间窗⼝内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速 率）
限制远程接⼝调⽤速率、限制MQ的消费速率等
（3）Hystrix简介
[来⾃官⽹]Hystrix（豪猪----->刺），宣⾔“defend your app”是由Netflix开源的⼀个延迟和容错库，⽤于隔离访问远程系统、服务或者第三⽅库，防⽌级联失败，从⽽提升系统的可⽤性与容错性。Hystrix主 要通过以下⼏点实现延迟和容错。
包裹请求：使⽤HystrixCommand包裹对依赖的调⽤逻辑。
跳闸机制：当某服务的错误率超过⼀定的阈值时，Hystrix可以跳闸，停⽌请求该服务⼀段时间。
资源隔离：Hystrix为每个依赖都维护了⼀个⼩型的线程池(舱壁模式)（或者信号量）。如果该线程 池已满， 发往该依赖的请求就被⽴即拒绝，⽽不是排队等待，从⽽加速失败判定。
监控：Hystrix可以近乎实时地监控运⾏指标和配置的变化，例如成功、失败、超时、以及被拒绝 的请求等。
回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执⾏回退逻辑。回退逻辑由开发⼈员 ⾃⾏提供，例如返回⼀个缺省值。
⾃我修复：断路器打开⼀段时间后，会⾃动进⼊“半开”状态。
（4）Hystrix工作流程
1）当调⽤出现问题时，开启⼀个时间窗（10s）
2）在这个时间窗内，统计调⽤次数是否达到最⼩请求数？ 如果没有达到，则重置统计信息，回到第1步 如果达到了，则统计失败的请求数占所有请求数的百分⽐，是否达到阈值？ 如果达到，则跳闸（不再请求对应服务） 如果没有达到，则重置统计信息，回到第1步
3）如果跳闸，则会开启⼀个活动窗⼝（默认5s），每隔5s，Hystrix会让⼀个请求通过,到达那个问题服 务，看 是否调⽤成功，如果成功，重置断路器回到第1步，如果失败，回到第3步
（5）Hystrix处理流程
Hystrix流程图如下：
图片来源Hystrix官网https://github.com/Netflix/Hystrix/wiki
Hystrix整个工作流如下：
- 构造一个 HystrixCommand或HystrixObservableCommand对象，用于封装请求，并在构造方法配置请求被执行需要的参数；
- 执行命令，Hystrix提供了4种执行命令的方法，后面详述；
- 判断是否使用缓存响应请求，若启用了缓存，且缓存可用，直接使用缓存响应请求。Hystrix支持请求缓存，但需要用户自定义启动；
- 判断熔断器是否打开，如果打开，跳到第8步；
- 判断线程池/队列/信号量是否已满，已满则跳到第8步；
- 执行HystrixObservableCommand.construct()或HystrixCommand.run()，如果执行失败或者超时，跳到第8步；否则，跳到第9步；
- 统计熔断器监控指标；
- 走Fallback备用逻辑
- 返回请求响应
从流程图上可知道，第5步线程池/队列/信号量已满时，还会执行第7步逻辑，更新熔断器统计信息，而第6步无论成功与否，都会更新熔断器统计信息。
4、Feign远程调⽤组件
服务消费者调⽤服务提供者的时候使⽤RestTemplate技术存在不便之处：拼接url，存在硬编码
（1）Feign简介
Feign是Netflix开发的⼀个轻量级RESTful的HTTP服务客户端（⽤它来发起请求，远程调⽤的），是以 Java接⼝注解的⽅式调⽤Http请求，⽽不⽤像Java中通过封装HTTP请求报⽂的⽅式直接调⽤，Feign被 ⼴泛应⽤在Spring Cloud 的解决⽅案中。
类似于Dubbo，服务消费者拿到服务提供者的接⼝，然后像调⽤本地接⼝⽅法⼀样去调⽤，实际发出的是远程的请求。
Feign可帮助我们更加便捷，优雅的调⽤HTTP API：不需要我们去拼接url然后呢调⽤ restTemplate的api，在SpringCloud中，使⽤Feign⾮常简单，创建⼀个接⼝（在消费者--服务调 ⽤⽅这⼀端），并在接⼝上添加⼀些注解，代码就完成了
SpringCloud对Feign进⾏了增强，使Feign⽀持了SpringMVC注解（OpenFeign）
本质：封装了Http调⽤流程，更符合⾯向接⼝化的编程习惯，类似于Dubbo的服务调⽤
Dubbo的调⽤⽅式其实就是很好的⾯向接⼝编程
5、GateWay⽹关组件
⽹关（翻译过来就叫做GateWay）：微服务架构中的重要组成部分 局域⽹中就有⽹关这个概念，局域⽹接收或者发送数据出去通过这个⽹关，⽐如⽤Vmware虚拟机软件 搭建虚拟机集群的时候，往往我们需要选择IP段中的⼀个IP作为⽹关地址。 我们学习的GateWay-->Spring Cloud GateWay（它只是众多⽹关解决⽅案中的⼀种）
（1）GateWay简介
Spring Cloud GateWay是Spring Cloud的⼀个全新项⽬，⽬标是取代Netflix Zuul，它基于 Spring5.0+SpringBoot2.0+WebFlux（基于⾼性能的Reactor模式响应式通信框架Netty，异步⾮阻塞模型）等技术开发，性能⾼于Zuul，官⽅测试，GateWay是Zuul的1.6倍，旨在为微服务架构提供⼀种简单有效的统⼀的API路由管理⽅式。
Spring Cloud GateWay不仅提供统⼀的路由⽅式（反向代理）并且基于 Filter(定义过滤器对请求过滤， 完成⼀些功能) 链的⽅式提供了⽹关基本的功能，例如：鉴权、流量控制、熔断、路径重写、⽇志监控 等。
6、Spring Cloud Config 分布式配置中⼼
（1）分布式配置中⼼应⽤场景
往往，我们使⽤配置⽂件管理⼀些配置信息，⽐如application.yml 单体应⽤架构，配置信息的管理、维护并不会显得特别麻烦，⼿动操作就可以，因为就⼀个⼯程； 微服务架构，因为我们的分布式集群环境中可能有很多个微服务，我们不可能⼀个⼀个去修改配置然后 重启⽣效，在⼀定场景下我们还需要在运⾏期间动态调整配置信息，⽐如：根据各个微服务的负载情 况，动态调整数据源连接池⼤⼩，我们希望配置内容发⽣变化的时候，微服务可以⾃动更新。
场景总结如下：
1）集中配置管理，⼀个微服务架构中可能有成百上千个微服务，所以集中配置管理是很重要的（⼀次修改、到处⽣效）
2）不同环境不同配置，⽐如数据源配置在不同环境（开发dev,测试test,⽣产prod）中是不同的
3）运⾏期间可动态调整。例如，可根据各个微服务的负载情况，动态调整数据源连接池⼤⼩等配置修 改后可⾃动更新
4）如配置内容发⽣变化，微服务可以⾃动更新配置 那么，我们就需要对配置⽂件进⾏集中式管理，这也是分布式配置中⼼的作⽤。
（2）Spring Cloud Config简介
Spring Cloud Config是⼀个分布式配置管理⽅案，包含了 Server端和 Client端两个部分。
Server 端：提供配置⽂件的存储、以接⼝的形式将配置⽂件的内容提供出去，通过使⽤ @EnableConfigServer注解在 Spring boot 应⽤中⾮常简单的嵌⼊
Client 端：通过接⼝获取配置数据并初始化⾃⼰的应⽤
7、Spring Cloud Stream消息驱动组件
Spring Cloud Stream 消息驱动组件帮助我们更快速，更⽅便，更友好的去构建消息驱动微服务的。 当时定时任务和消息驱动的⼀个对⽐。（消息驱动：基于消息机制做⼀些事情） MQ：消息队列/消息中间件/消息代理，产品有很多，ActiveMQ RabbitMQ RocketMQ Kafka
（1）Stream解决的痛点问题
MQ消息中间件⼴泛应⽤在应⽤解耦合、异步消息处理、流量削峰等场景中。 不同的MQ消息中间件内部机制包括使⽤⽅式都会有所不同，⽐如RabbitMQ中有Exchange（交换机/交换器）这⼀概念，kafka有Topic、Partition分区这些概念，MQ消息中间件的差异性不利于我们上层的 开发应⽤，当我们的系统希望从原有的RabbitMQ切换到Kafka时，我们会发现⽐较困难，很多要操作可 能重来（因为应⽤程序和具体的某⼀款MQ消息中间件耦合在⼀起了）。
Spring Cloud Stream进⾏了很好的上层抽象，可以让我们与具体消息中间件解耦合，屏蔽掉了底层具体MQ消息中间件的细节差异，就像Hibernate屏蔽掉了具体数据库（Mysql/Oracle⼀样）。如此⼀ 来，我们学习、开发、维护MQ都会变得轻松。⽬前Spring Cloud Stream⽀持RabbitMQ和Kafka。
本质：屏蔽掉了底层不同MQ消息中间件之间的差异，统⼀了MQ的编程模型，降低了学习、开发、维护MQ的成本
6、第二代Spring Cloud 核心组件（SCA）
待完善
参考文章
《Spring Cloud 入门总结》
《Spring Cloud》