SpringCloud框架

Spring cloud是什么？

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性简化了分布式系统基础设施的开发，例如服务发现注册，配置中心，消息总线，负载均衡，断路器，数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。

其实Spring Cloud是一套规范，一套用于构建服务架构的规范。

第一代Spring Cloud核心组件

1. Eureka服务注册中心

服务注册中心本质上是为了解耦服务提供者和服务消费者。

对于任何微服务，原则上都应该存在多个提供者，这是由微服务的分布式属性决定的。

1.1 服务注册中心一般原理

服务消费者获取服务注册信息的方式由：

pull模式：服务消费者主动拉取可用的服务提供者清单

push模式：服务消费者订阅服务，当服务提供者有变化时，注册中心主动推送更新后的服务清单给消费者。

另外，注册中心也需要完成服务提供者的健康监控，当发现服务提供者失效时需要及时剔除。

1.2 注册中心组件Eureka

Eureka基础架构

Eureka交互流程及原理

默认每隔30秒续约一次，默认90秒没有续约的化，服务中心就要剔除对应的应用实例信息。

启动类上加载@EnableEurekaServer 标明当前服务时EurekaServer

Eureka Server 配置文件

server:port: 8762spring:application:name: cloud-eureka-server
eureka:instance:# hostname: eureka-server-2  # 需要在host文件中配置hostname与IP的映射prefer-ip-address: trueinstance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@client:service-url:defaultZone: http://localhost:8761/eureka # 向指定的注册中心进行注册，多个地址间用逗号隔开register-with-eureka: true  # 向上边配置的server-url注册fetch-registry: true  # 获取注册中心的数据

Eureka Client启动类上添加@EnableEurekaClient或者@EnableDiscoveryClient

Eureka Client配置文件

eureka:instance:prefer-ip-address: trueinstance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@client:service-url:defaultZone: http://localhost:8761/eureka,http://localhost:8762/eureka

1.3 Eureka细节详情

1.3.1 Eureka元数据

Eureka的元数据有两种：标准元数据和自定义元数据

标准元数据：主机名、IP地址、端口号等信息，这些信息都会再被发布再服务注册表中，用于服务间的调用。

自定义元数据：可以使用eureka.instance.metadata-map配置，符合KEY/VALUE的存储格式。这些元数据可以在远程客户端中访问。

类似：

eureka:instance:metadata-map:cluster: clsregion: rnl

可以在程序中使用DiscoveryClient获取指定微服务的所有元数据信息。

1.3.2 Eureka 客户端详情

Eureka客户端要想EurekaServer注册服务，并完成服务续约等工作。

服务注册详情（服务提供者）

1. 导入eureka-client 依赖坐标，配置Eureka服务注册中心地址

2）服务在启动时向注册中心发起注册请求，携带服务元数据

3）Eureka注册中心会把服务的信息保存到Map中。

服务续约详情（服务提供者）

服务每隔30秒会向注册中心续约（心跳）一次，如果没有续约，租约在90秒后到期，然后服务会被失效。每隔30秒的续约操作称之为心跳检测

eureka:instance: # 租约续约间隔时间，默认30秒 lease-renewal-interval-in-seconds: 30# 租约到期，服务失效时间，默认90秒，服务超时90秒没有发生心跳lease-expiration-duration-in-seconds: 90

获取服务列表详情（服务消费者）

每隔30秒服务会从注册中心拉取一次服务列表，拉取后缓存到本地。

eureka:client: # 每隔多久拉取一次服务列表registry-fetch-interval-seconds: 30

1.3.3 Eureka服务端详情

服务下线

1）服务正常关闭操作时，会发送服务下线的rest请求到EurekaServer

2）服务中心接收到请求后，将该服务设为下线状态。

失效剔除

Eureka Server 会定时进行检查（间隔值通过eureka.server.eviction-interval-timer-in-ms,默认60s）,如果发现实例在一定时间（可以通过eureka.instance.lease-expiration-duration-in-seconds进行配置）内没有收到心跳，则会注销此实例。

自我保护

服务提供者——>注册中心的定期续约，假如服务提供者和注册中心的网络有点问题，不代表服务提供者不可用，不代表服务消费者无法访问服务提供者。

如果在15分钟内超过85的客户端都没有正常的心跳，那么Eureka就任务客户端与注册中心出现了网络故障，Eureka Server自动进入自我保护机制。

当处于自我保护模式下

1. 不会剔除任何服务实例，保证大多数服务依然可用
2. Eureka Server仍然能够接收新服务的注册和查询请求，但是不会被同步到其他节点，保证当前节点依然可用，当网络稳定时，当前Eureka Server新的注册信息会被同步到其他节点上。
3. 在Eureka Server工程中通过eureka.server.enable-self-preservation配置可用关停自我保护，默认值时打开

eureka:server:enable-self-preservation: false # 关闭自我保护，缺省是打开

建议生成环境打开自我保护。

2. Ribbon负载均衡

2.1 关于负载均衡

负载均衡可分为服务器负载均衡和客户端负载均衡

服务器负载均衡：请求到达服务器之后由这些负载均衡器根据一定的算法将请求路由到目标服务器处理。例如：nginx, F5

客户端负载均衡：服务消费者客户端会有一个服务器地址列表，调用方在请求前通过一定的均衡算法选择一个服务器进行访问，负载均衡算法的执行在请求客户端进行。

Ribbon是Netflix发布的负载均衡器，使用的客户端负载均衡。

在使用eureka-client时，不需要再单独引入ribbon的依赖，因为eureka-client依赖中包含了ribbon的依赖。

ribbon的负载均衡在RestTemplate上的使用

    @Bean@LoadBalanced  // 负载均衡public RestTemplate restTemplate() {return new RestTemplate();}

2.2 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重新选取。
AvailabilityFilteringRule:可用过滤策略	扩展了轮询策略，会先通过默认的轮询选取一个server，再去判断该server是否超时可用，当前连接数是否超限，都成功在返回。
ZoneAvoidanceRule：区域权衡策略**（默认策略）**	扩展了轮询策略，继承了2个过滤器：ZoneAvoidancePredicate和AvailabilityPredicate，除了过滤器超时和连接数过多的server，还会过滤掉不符合要求的zone区域里面的所有节点，AWS–ZONE在一个区域／机房内的服务实例中轮询

修改均衡策略

# 针对被调用方微服务名称，不加就是全局生效
cloud-service-user: ribbon:NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule # 负载均衡策略

图中核心是负载均衡管理器LoadBalancer（总的协调者，相当于大脑/心脏，协调四肢），围绕它周围的多有IRule，IPing等。

• IRule：是在选择实例的时候的负载均衡策略对象
• IPing：是用来向服务发起心跳检测的，通过心跳检测来判断该服务是否可用
• ServerListFilter：根据一些规则过滤传入的服务实例列表
• ServerListUpdater：定义了一系列的对服务列表的更新操作。

3. Hystrix熔断器

3.1 微服务中的雪崩效益

什么是微服务中的雪崩效应？

微服务中，一个请求可能需要多个微服务接口才能实现，会形成复杂的调用链路。下游的一个服务不能使用可能会导致上有多个服务不可用，甚至整个系统瘫痪。

3.2 雪崩效应解决方案

3.2.1 服务熔断

熔断机制是应对雪崩效应的一种微服务链路保护机制。在微服务架构中，当扇出链路的某个微服务不可用或响应时间太长时，熔断该节点的服务调用，进行服务的降级，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

注意：

• 服务熔断重点在“断”，切断对下游服务的调用。
• 服务熔断和服务降级往往一起使用

3.2.2 服务降级

通俗讲就是整体资源不够用了，先将一些不紧要的服务停掉，待渡过难关，再把那些服务打开。

服务降级一般是从整体考虑，就是当某个服务熔断之后，服务器将不再被调用，此刻客户端可以自己准备一个本地fallback回调，返回一个缺省值，这样做，虽然服务水平下降，但好歹可用，比直接挂掉要好。

3.2.3 服务限流

服务降级是当服务出现问题或者影响到核心流程的性能时，暂时将服务屏蔽掉，待高峰或者问题解决后再打开；但是有些场景并不能用服务降级来解决，比如秒杀业务这些核心功能，这时候可以结合服务限流来限制这些场景的并发/请求量。

限流措施很多，比如：

• 限制总并发数（比如数据库连接池，线程池）
• 限制瞬时并发送（比如nginx限制瞬时并发连接数）
• 限制时间窗口内的平均速率（比如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）
• 限制远程接口调用速率，限制MQ的消息速率等。