springCloud组件以及相应原理

springcloud是微服务架构的集大成者，将一系列优秀的组件进行了整合。基于springboot构建，对我们熟悉spring的程序员来说，上手比较容易。

通过一些简单的注解，我们就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。

SpringCloud的组件相当繁杂，拥有诸多子项目。重点关注Netflix

springcloud项目是由多个独立项目集合而成的，每个项目都是独立的，各自进行自己的迭代和版本发布。所以springcloud不方便使用版本号来管理，而是使用版本名。以避免和子项目版本号的冲突。

SpringCloud分布式开发五大组件详解

• 服务发现——Netflix Eureka（星图（系统名）中有使用，可以在界面上看到相关服务是否启动）
• 客服端负载均衡——Netflix Ribbon （项目中只配置了ribbon.ServerListRefreshInterval可以调整刷新server list的时间间隔参数）
• 断路器——Netflix Hystrix（星图中有使用，在对接数据中心接口中封装成切面，实现熔断）
• 服务网关——Netflix Zuul（部门内部没用网关，因为项目之间没有请求，公司层面后来统一封装了api gateway 。网关服务很多，比如：Zuul、Kong、spring cloud gateway ……，公司封装的Kong，Kong是一个基于Apache License 2.0的开源项目，是一个云原生的快速可扩的分布式微服务抽象层，应用场景为微服务的API网关，类似于spring cloud的zuul。）
• 分布式配置——Spring Cloud Config（星图中有使用，将几个项目的配置都统一起来,公司封装了一个配置中心使用的是TARS， TARS 是由腾讯捐赠给 Linux 基金会的开源微服务治理框架）
• 服务间的通信——spring cloud feign:Feign 的初衷是：feign makes writing java http clients easier ，可以理解为一个Http Client。只不过这个http client 对http 请求进行了一个封装。到了Spring Cloud 2.XX 系列版本后，feign 才成为Spring Cloud 下的一级项目

Spring Cloud 中的微服务都是以Http 接口的形式向外提供服务。

提供Http 服务的形式有多种：

• JDK 原生的URLConnction
• Apache 的HttpClient
• Spring 的RestTemplate

Spring Cloud 对Feign 也进行了增强，直接支持Hystrix 和 Ribbon，也支持SpringMVC 的注解。这样使得Feign 的使用非常方便。

所以综上，真正用到的springcloud组件并不多，而是用了公司封装的其他组件进行了代替。关于替代组件的研究放在以后，我们看一下springcloud给我们提供的组件

上边各个组件的原理：

Feign的原理步骤可以理解为：

a.通过主类上的EnableFeignClients 注解开启FeignClient；

b.根据Feign 的规则实现接口，并加上FeignClient注解，供调用的地方注入调用；

c.程序启动后，会扫描所有FeignClient 注解的类，并将这些信息注入到IOC 容器中；

d.当b中接口被调用时，通过jdk代理，以及反射（Spring处理注解的方式），来生成具体的RequestTemplate

e.RequestTemplate 生成Reqest

f.Request 交给httpclient处理，这里的httpclient 可以是OkHttp，也可以是HttpUrlConnection 或者HttpClient

g.最后Client被封装到LoadBalanceClient类，这个类结合Ribbon 实现负载均衡

spring cloud config 分布式配置中心组件：

它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。
在spring cloud config 组件中，分两个角色，一是config server，二是config client。
Config Server是一个可横向扩展、集中式的配置服务器，它用于集中管理应用程序各个环境下的配置，默认使用Git存储配置文件内容，也可以使用SVN存储，或者是本地文件存储。
Config Client是Config Server的客户端，用于操作存储在Config Server中的配置内容。
微服务在启动时会请求Config Server获取配置文件的内容，请求到后再启动容器。

SpringCloud Bus自动刷新配置
Spring Cloud Bus集成了市面上常见的RabbitMQ和Kafka等消息代理。
其会连接微服务系统中所有拥有Bus总线机制的节点，当有数据变更的时候，
会通过消息中间件使用消息广播的方式通知所有的微服务节点同步更新数据。（如：微服务配置更新等）
基于client端实现全局刷新

基于server和client端实现全局刷新 将热刷新逻辑和具体的服务应用解耦

spring cloud hystrix实际开发有哪些作用？它能不能限流？

在星图项目中会调用数据中心接口获取数据来生成报表，但是数据中心不稳定，所以引入了熔断机制，将其定义为切面，在请求数据中心方法上添加相应的注解就可以完成熔断机制，如果数据中心报错太多就不再请求。实现如下：关于@HystrixCommand的配置方法可以网上搜一下

//业务类代码的方法上
    @Override
    @HystrixCommand(
            commandProperties = {
                    @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "60000"),//指定多久超时，单位毫秒。超时进fallback
                    @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),//判断熔断的最少请求数，默认是10；只有在一个统计窗口内处理的请求数量达到这个阈值，才会进行熔断与否的判断
                    @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"),//判断熔断的阈值，默认值50，表示在一个统计窗口内有50%的请求处理失败，会触发熔断
                    @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000") //熔断多少毫秒后开始尝试请求 默认5000ms
            })
    public BaseSearchResultDTO getPerspectiveData(ReqGetTransPerspectiveDataDTO reqGetTransPerspectiveDataDTO) throws Exception {...}

熔断器原理：

Hystrix的Metrics中保存了当前服务的健康状况, 包括服务调用总次数和服务调用失败次数等. 根据Metrics的计数, 熔断器从而
能计算出当前服务的调用失败率, 用来和设定的阈值比较从而决定熔断器的状态切换逻辑. 因此Metrics的实现非常重要.
1.5之后的滑动窗口实现
Hystrix在这些版本中开始使用RxJava的Observable.window()实现滑动窗口.
RxJava的window使用后台线程创建新桶, 避免了并发创建桶的问题.
同时RxJava的单线程无锁特性也保证了计数变更时的线程安全. 从而使代码更加简洁. 

原理流程：

构造一个HystrixCommand或者HystrixObserverCommand对象，把需要调用的依赖放在run()中

执行execute/queue做同步或者异步执行

是否做了缓存

熔断是否打开

线程池/队列/信号量是否满了

调用run（）或者construct（）

计算熔断健康度（成功，失败，拒绝，超时）的数据，上报给熔断器，用于统计从而判断熔断器状态，可以根据这些数据来决定是否进行熔断，例如：错误率在80%以上，接口等待超过预定的时间等。

获取Fallback，如果fallback失败，系统报错，所以要尽量防止fallback报错，当然也可以在fallback上加上一层fallback

返回执行结果

spring cloud ribbon有什么作用？

一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。当然我们也可以直接使用负载均衡组件，Ribbon。
Ribbon是Netiflix发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为。为Ribbon配置服务提供者地址列表后，Ribbon就可以基于某种负载均衡算法，自动的帮助服务消费者去请求。
Ribbon的负载均衡算法有：轮询、随机等，默认是轮询。

eureka原理：

Applecation-server :服务提供者
Application-cliene:服务消费者
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用。

Eureka与Zookeeper的区别

CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。
Zookeeper保证CP
Zookeeper 为主从结构，有leader节点和follow节点。当leader节点down掉之后，剩余节点会重新进行选举。选举过程中会导致服务不可用，丢掉了可用行。
Eureka保证AP
Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。

如果 Eureka Server 在一定的 90s 内没有接收到某个微服务实例的心跳，会注销该实例。但是在微服务架构下服务之间通常都是跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，网络分区故障，导致此实例被注销。固定时间内大量实例被注销，可能会严重威胁整个微服务架构的可用性。为了解决这个问题，Eureka 开发了自我保护机制，那么什么是自我保护机制呢？Eureka Server 在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 即会进入自我保护机制。

Eureka Server 进入自我保护机制，会出现以下几种情况：
(1 Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
(2 Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
(3 当网络稳定时，当前实例新的注册信息会被同步到其它节点中