SpringCloud

SpringCloud的基础功能：

服务治理：Spring Cloud Eureka
客户端负载均衡：Spring Cloud Ribbon
服务容错保护：Spring Cloud Hystrix
声明式服务调用：Spring Cloud Feign
API网关服务：Spring Cloud Zuul
分布式配置中心：Spring Cloud Config

SpringCloud的高级功能：
消息总线：Spring Cloud Bus
消息驱动的微服务：Spring Cloud Stream
分布式服务跟踪：Spring Cloud Sleuth

Spring Cloud Eureka

为了解决微服务架构中的服务实例维护问题(ip地址)， 产生了大量的服务治理框架和产品。这些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。

在SpringCloud中我们的服务治理框架一般使用的就是Eureka也可以换成zookeeper
为了解决微服务架构中的服务实例维护问题(ip地址)， 产生了大量的服务治理框架和产品。这些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。

Eureka Server用于给其他服务注册，注册到Eureka Server的服务称为Eureka Client。

Eureka Server一般会这样配置：
register-with-eureka: false #false表示不向注册中心注册自己。
fetch-registry: false #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务

---

Eureka Client分为服务提供者和服务消费者。

可能某服务既是服务提供者又是服务消费者。

如果在网上看到SpringCloud的某个服务配置没有"注册"到Eureka-Server也不用过于惊讶(但是它是可以获取Eureka服务清单的)

很可能只是作者把该服务认作为单纯的服务消费者，单纯的服务消费者无需对外提供服务，也就无须注册到Eureka中了

eureka: client:
register-with-eureka: false # 当前微服务不注册到eureka中(消费端)
service-url:
defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eu

如果Eureka服务注册表发生变化，客户端会定时去刷新最新注册表

Eureka的治理机制
服务提供者

服务注册：启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。

服务续约：在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” （30秒客户端会续约）

服务下线：当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了 ”。

服务消费者

获取服务：当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单

服务调用：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。

Eureka Server(服务注册中心)：

失效剔除：默认每隔一段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔除出去。

自我保护：。EurekaServer 在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。Eureka Server会将当前的实例注册信息保护起来， 让这些实例不会过期，尽可能保护这些注册信息，当网络故障恢复后，该服务就会退出自我保护模式，重新分配请求

Eureka 高可用
　　springCloud的eureka高可用配置方案思路是：几个服务中心之间相互注册，比如两个注册中心，A注册到B上，B注册到A上，如果是三个注册中心则是：A注册到BC上，B注册到AC上，C注册到AB上，这样就会在几个注册中心间进行同步，同时服务提供方向三个注册中心均注册，这样就会保证当一个服务注册中心宕机的时候，不影响整个系统的正常运行，从而保证了eureka的高可用。
Client：在每个client的配置文件中，添加所有server的地址，多节点间使用"，"分开

Spring Cloud Ribbon

SpringCloud支持的负载均衡功能，它是客户端的负载均衡，这个功能实现就是Ribbon

负载均衡又区分了两种类型：

客户端负载均衡(Ribbon)
服务实例的清单在客户端，客户端进行负载均衡算法分配。

服务端负载均衡(Nginx)
服务实例的清单在服务端，服务器进行负载均衡算法分配

Robbon负载均衡算法👇

自定义负载均衡策略
实现起来也很简单：继承AbstractLoadBalancerRule类，重写public Server choose(ILoadBalancer lb, Object key)即可。
SpringCloud 在CAP理论是选择了AP的，在Ribbon中还可以配置重试机制的(有兴趣的同学可以去搜搜)~

Spring Cloud Hystrix 熔断器

在高并发的情况下，由于单个服务的延迟，可能导致所有的请求都处于延迟状态，甚至在几秒钟就使服务处于负载饱和的状态，资源耗尽，直到不可用，最终导致这个分布式系统都不可用，这就是“雪崩”。

断路器、线程隔离等一系列服务保护功能。

1、Fallback(失败快速返回)：当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝）， 向调用方返回一个错误响应， 而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

2、资源/依赖隔离(两种依赖隔离方式线程池隔离(默认)、信号量隔离)：它会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响， 而不会拖慢其他的依赖服务，默认隔离粒度是服务

Hystrix提供几个熔断关键参数：滑动窗口大小（10s）、 熔断器开关间隔（断路器保持在开路状态一段时间后5s(默认)自动切换到半开路状态）、错误率（50%）

注：基于滑动窗口判定服务失败占比选择性熔断

1、每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。

2、直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

总结一下：Hystrix断路器触发的默认策略为在10秒内，发生20次以上的请求时，假如错误率达到50%以上，两个条件要都有，则断路器将被打开。（当一个窗口期过去的时候，断路器将变成半开（HALF-OPEN）状态，如果这时候发生的请求正常，则关闭，否则又打开）

Hystrix还有请求合并、请求缓存这样强大的功能

Hystrix仪表盘
Hystrix仪表盘：它主要用来实时监控Hystrix的各项指标信息。通过Hystrix Dashboard反馈的实时信息，可以帮助我们快速发现系统中存在的问题，从而及时地采取应对措施。

Spring Cloud Feign

上面已经介绍了Ribbon和Hystrix了，可以发现的是：他俩作为基础工具类框架广泛地应用在各个微服务的实现中。我们会发现对这两个框架的使用几乎是同时出现的。

为了简化我们的开发，Spring Cloud Feign出现了！它基于 Netflix Feign 实现，整合了 Spring Cloud Ribbon 与 Spring Cloud Hystrix, 除了整合这两者的强大功能之外，它还提
供了声明式的服务调用(不再通过RestTemplate)。

Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。

Feign使用熔断器，接口注解上加fallbackFactory 指定熔断器类

Feign
#全局配置
请求连接的超时时间 默认的时间为 1 秒
ribbon.ConnectTimeout=5000
请求处理的超时时间
ribbon.ReadTimeout=5000

Spring Cloud Zuul

Zuul支持Ribbon和Hystrix，也能够实现客户端的负载均衡。我们的Feign不也是实现客户端的负载均衡和Hystrix的吗？既然Zuul已经能够实现了，那我们的Feign还有必要吗？
1、zuul是对外暴露的唯一接口相当于路由的是controller的请求，而Ribbonhe和Fegin路由了service的请求
2、zuul做最外层请求的负载均衡 ，而Ribbon和Fegin做的是系统内部各个微服务的service的调用的负载均衡

Zuul可以暴漏给异构系统，php或nodejs调用，也可以给前端调用。

---

SpringCloud Zuul通过与SpringCloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息。外层调用都必须通过API网关，使得将维护服务实例的工作交给了服务治理框架自动完成。

在API网关服务上进行统一调用来对微服务接口做前置过滤，以实现对微服务接口的拦截和校验。

Zuul和Nginx是可以一起使用的