你对 Spring Cloud 的理解

Spring Cloud 是一套分布式微服务的技术解决方案，简单来说是个构建分布式系统的开发工具包，它提供了快速构建分布式系统的常用的一些组件。

• 注册中心（Nacos、Eureka、zookeeper）
• 负载均衡（Ribbon）
• 远程调用（Dubbo、OpenFeign）
• 服务熔断（Hystrix、sentinel）
• 网关（Zuul、Gateway）
• 配置中心（Nacos、zookeeper）

有了 Spring Cloud 这样的技术生态，使得我们在落地微服务架构时。不用去考虑第三方技术集成带来额外成本，只要通过配置组件来完成架构下的技术问题，从而可以让我们更加侧重性能方面

Eureka VS Nacos

• 服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等
• 服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用
• 服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除

Eureka

eureka每30s提交一次健康状况，在此期间，如果消费者已经进行了拉取，提供者失效了，那么消费者就会访问报错

Nacos

 

nacos 的实例细分为临时实例和非临时实例，临时实例在一个时间段需要向 nacos 投递自身健康状态，如果在该时间区域中没有投递，那么nacos 则会将该实例从注册列表剔除； 非临时实例在一个 时间段内被 nacos 主动询问是否健康，如果不健康就会将其属性改为不健康，不会剔除，并主动 push 变更信息到其他节点

二者区别

Nacos 与 eureka 的共同点（注册中心）

• 都支持服务注册和服务拉取
• 都支持服务提供者心跳方式做健康检测

Nacos 与 Eureka 的区别（注册中心）

• Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
• 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
• Nacos支持服务列表变更的消息推送模式，服务列表更新更及时，Eureka遇到数据变更会访问报错
• Nacos集群默认采用AP方式【可用性为主】，当集群中存在非临时实例时，采用CP模式【一致性为主】；Eureka只采用AP方式

Nacos 还支持了配置中心， eureka 则只有注册中心，也是选择使用 nacos 的一个重要原因

Ribbon 负载均衡

微服务的负载均衡主要使用了一个组件 Ribbon ，比如，我们在使用 feign 远程调用的过程中，底层的负载均衡就是使用了ribbon

Ribbon负载均衡流程

Ribbon 负载均衡策略

• 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询（默认采用这个，如果服务器没有Zone的概念，那就是采用普通轮询的方式）
• 简单轮询
• 按照权重来选择服务器，响应时间越长，权重越小
• 随机选择
• 忽略那些短路的服务器，并选择并发数较低的服务器
• 重试机制的选择逻辑
• 可用性敏感策略，先过滤非健康的，再选择连接数较小的实例

自定义负载均衡策略

可以自己创建类实现 IRule 接口 , 然后再通过配置类或者配置文件配置即可 ，通过定义 IRule 实现可以修改负载均衡规则，有两种方式：

全局生效

@Bean
public IRule randomRule(){
return new RandomRule(); ## 负载均衡策略（可以用Ribbon自带的，也可以继承IRule接口自
己实现个）
}

局部生效

userservice: # 指定一个服务名，将该服务应用下面指定的负载均衡规则
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡
规则

饥饿加载

Ribbon 默认是采用 懒加载 ，即第一次访问时才会去创建 LoadBalanceClient （ Ribbon 客户端），请求时间会很长。

而饥饿加载则会在项目启动时创建，降低第一次访问的耗时，通过下面配置开启饥饿加载：