Spring Cloud总结

先搞清一个概念，spring cloud并不是一种技术，它是一种设计思想的落地方案；

spring cloud组件

注册中心：zookeeper、eureka、nacos
服务调用/负载均衡：ribbon、nginx、feign、openFeign
服务熔断/降级：Hystrix（Netflix）、Sentinel（阿里中间件团队）
网关：zuul、gateway
配置中心：spring cloud config+spring cloud bus

怎么使用

基本所有的组件使用方法都是基于注解，开启+使用的模式，在使用组件的地方加上对应注解，如@FeignClient 注解，然后在启动类上加EnAble***注解，如EnAbleFeignClient 注解

各组件的作用

注册中心

以eureka为例，eureka分为服务端和客户端，客户端每30秒向eureka服务器发送心跳连接，以此来表明本服务还存活，若服务端连续三个心跳周期（90秒）没有收到某客户端发来的心跳链接，则会将其从服务列表剔除；客户端和服务端通过json/xml进行通讯，服务端会每30秒去服务端更新一次服务列表；底层使用restTemplate；

eureka使用：
添加依赖->增加yml配置->主启动类增加eureka注解（eureka服务器EnableEurekaServer，eureka服务EnableEurekaClient）




eureka集群：

负载均衡/服务调用

以ribbon为例，ribbon为负载均衡组件，跟nginx不同，nginx运行在服务端，将所有请求集中起来进行负载均衡；ribbon运行在消费端，算法和nginx相似但更强大，除了有nginx的轮询、加权轮询（10轮若还没结果就返回null），还支持随机策略、重试策略，默认轮询；ribbon只能做负载均衡，不能服务调用（依然得用restTemplate，先new restTemplate对象，调用postForObject方法传入请求url、入参、返回结果类型.class，postForObject只需要传入请求url+入参，和返回结果），显然ribbon太麻烦，所以有了feign和openFeign（在feign基础上增加对springMVC注解的支持），用@FeignClient 注解服务提供者的名称，在controller层即可像调用service一样调用服务；
ribbon：把注册中心的服务列表缓存到本地，discoveryClient.getInstances(“CLOUD-PAYMENT-SERVICE”);
ribbon不需要额外添加依赖也可以使用，因为eureka和ribbon有一腿，eureka客户端依赖自带了ribbon的引用，ribbon的负载均衡算法有好几种，最常用的是轮询，具体算法实现就是
当前请求次数%服务端对应服务列表数量

@Component
public class MyLB implements LoadBalancer {

private AtomicInteger atomicInteger = new AtomicInteger(0);

//坐标
private final int getAndIncrement(){
	int current;
	int next;
	do {
	current = this.atomicInteger.get();
	next = current >= 2147483647 ? 0 : current + 1;
	}while (!this.atomicInteger.compareAndSet(current,next)); //第一个参数是期望值，第二个参数是修改值是
	System.out.println("*******第几次访问，次数next: "+next);
	return next;
}

@Override
public ServiceInstance instances(List<ServiceInstance> serviceInstances) { //得到机器的列表
	int index = getAndIncrement() % serviceInstances.size(); //得到服务器的下标位置
	return serviceInstances.get(index);
	}
}

openFeign有个超时访问时间，需要在yml文件里面配置，默认为一秒，如果消费者端一秒内没得到服务提供者的响应，直接返回大白页（服务超时）
openFeign还可以做日志打印，需要新建一个类，用openFeign的logger

服务熔断/降级

比如A服务需要调用B服务，B又需要调用C，如果C在某一时刻崩了，所有请求都怼在C这儿阻塞着，B拿不到返回值，就有可能一直自旋或轮询反复请求，B也会崩，以此类推A也会崩，阻塞线程多了，服务器资源被占用完了整个系统就崩了，为了避免这种服务雪崩，就有了Hystrix，它可以做服务熔断或降级，如果某个时间段内，某请求的失败率达到某个阈值，Hystrix就会切断这种请求，直接给用户返回失败（熔断）或者友好提示（降级，通过@HystrixCommand注解指定降级服务名，如下图）；

网关

为了安全、用户体验，有时候我们需要对路由进行管理（统一前缀、策略配置、服务名屏蔽、路径屏蔽）；
或者对用户请求进行过滤，比如每两秒只接一个请求；

服务配置中心

每个服务都有自己的配置，我们不可能一个服务一个服务的去修改，而且这样会老是重启服务，spring cloud config就是把所有配置整合到一个地方进行统一管理（git或者svn），但是这样有个坏处，运行中的服务配置修改后不会立马更新，所以有了spring cloud bus消息总线，作用就是管理和广播分布式系统中的消息，有了 Spring Cloud Bus 之后，我们只需要创建一个简单的请求，并且加上 @ResfreshScope 注解就能进行配置的动态修改了；