springcloud的组件有哪些
注册中心：euraka、nacos、zookeeper
注册中心及配置中心：nacos
远程调用：feign、dubbo
负载均衡：ribbon
服务熔断：hystrix、sentinel
网关：zuul、gateway
eureka注册中心的作用
△面试题：服务注册和发现是什么意思？springcloud是如何实现服务注册和发现的？
我们当时项目采用的eureka作为注册中心，这个也是spring cloud体系中的一个核心组件。
服务注册：服务提供者需要把自己的信息注册到eureka，由eureka来保存这些信息，比如服务名称、ip、端口等等。
服务发现：消费者向eureka拉取服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个发起调用。
服务监控：服务提供者会每隔30秒向eureka发送心跳，报告健康状态，如果eureka服务90秒没接收到心跳，从eureka中剔除
△面试题：nacos和eureka的区别
nacos和eureka的共同点
- 都支持服务注册和服务拉取
- 都是注册中心
- 都支持服务提供者心跳方式做健康方式
如果是临时实例，那么nacos和eureka的工作流程基本一致
nacos和eureka的不同点
- nacos支持服务端主动检测提供者状态，临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例心跳不正常不会被剔除
- nacos支持服务列表变更的消息推送模式，服务列表能够及时更新
- nacos集群默认采用AP模式，当集群中存在非临时实例时，才采用CP模式；eureka采用AP模式
- nacos还支持配置中心；eureka仅仅是注册中心
nacos默认是临时实例，ephemeral配置默认为true
CAP理论
CAP即
- Consistency（一致性）
- Availability（可用性）
- Partition tolerance（分区容忍性）
轻松理解CAP理论
ribbon负载均衡是如何实现的？
微服务的负载均衡主要使用了一个组件Ribbon，比如，我们在使用feign远程调用的过程中，底层的负载均衡就是使用了ribbon。
ribbon执行流程
ribbon负载均衡策略有哪些？
- RoundRobinRule:简单轮询服务列表来选择服务器
- WeightedResponseTimeRule:按照权重来选择服务器，响应时间越长，权重越小
- RandomRule:随机选择一个可用的服务器
- BestAvailableRule:忽略那些短路的服务器，并选择并发数较低的服务器
- RetryRule:重试机制的选择逻辑
- AvailabilityFilteringRule:可用性敏感策略，先过滤非健康的，再选择连接数较小的实例
- ZoneAvoidanceRule: ribbon默认策略，以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。再对Zone内的多个服务做轮询
如何指定负载均衡策略？
通过实现IRule接口，然后再通过配置类或配置文件配置即可，有两种方式
什么是服务雪崩？怎么解决这个问题？
服务雪崩是指一个服务失败导致整条链路的服务都出现问题的情形。
服务降级
服务降级是服务自我保护或者保护下游服务的一种方式。用于确保服务不会受请求突增从而影响导致不可用。一般在实际开发中调用feign组件整合，实现服务降级逻辑。
feign示例
Hystrix熔断机制
Hystrix熔断机制，用于监控微服务调用情况，默认是关闭的。
开启需要在引导类上添加注解:@EnableCircuitBreaker，若默认检测到10秒内请求的失败率超过50%，就触发熔断机制。之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求。
