SpringCloud面试题
一.什么是springcloud
是微服务系统架构解决方案
包括:
注册中心
eureka nacos consul
硬编码服务提供者地址的方式有不少问题。要想解决这些问题,服务消费者需要一个强大的服务发现机制,服务消费者使用这种机制获取服务提供者的网络信息。不仅如此,即使服务提供者的网络地址发生变化,服务消费者也无须修改配置文件。
配置中心
springcloudconfig nacos
远程调用
feign dubbo
以优雅的方式完成服务之间的通信
客户端负载均衡
ribbon
Ribbon 的作用是负载均衡,服务进行远程调用的时候,如果服务提供方搭建了集群,Ribbon通过负载均衡算法选择其中一个。
网关
springcloudgateway zuul
负责网络路由,可以做统一的认证、限流、认证授权、安全,等等。
服务监控和保护
hystrix sentinel
服务链上,因为某个微服务的异常,而导致雪崩效应,整条服务链宕机的问题。
二.微服务架构的优点
降低了业务之间的耦合度
每个服务中只包含一种业务
便于服务的拓展
如果用户服务访问压力很大;我们就可以针对用户这个服务搭建集群,其他服务不能动;
三.微服务监控用的是什么技术
微服务架构监控通常使用的就是链路追踪
目前主流的链路追踪技术
SkyWalking
Zipkin+Sleuth
这些链路追踪技术都实现opentrace标准
四.CAP理论,BASE理论
CAP理论
作为分布式系统架构应该遵守三个指标
Consistency (一致性)
即更新操作成功并返回客户端后,所有节点在同一时间的数据完全一致。
对于客户端来说,一致性指的是并发访问时更新过的数据如何获取的问题。
从服务端来看,则是更新如何复制分布到整个系统,以保证数据最终一致
Availability (可用性)
即服务一直可用,而且是正常响应时间。系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况
Partition Tolerance (分区容错性)
即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统,而
CP和AP:分区容错是必须保证的,当发生网络分区的时候,如果要继续服务,那么强一致性和可用性只能 2 选 1
BASE理论
BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)
BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于CAP定理逐步演化而来的。BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。
基本可用
响应时间上的损失: 正常情况下,处理用户请求需要 0.5s 返回结果,但是由于系统出现故障,处理用户请求的时间变为 3 s。
系统功能上的损失:正常情况下,用户可以使用系统的全部功能,但是由于系统访问量突然剧增,
系统的部分非核心功能无法使用。
软状态
数据同步允许一定的延迟
最终一致性
系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态,不要求实时一致
五.Ribbon负载均衡算法、类型,如何配置
Ribbon负载均衡算法的类型
RoundRobinRule:轮询;
RandomRule:随机;
AvailabilityFilteringRule:会先过滤掉由于多次访问故障而处于断路器状态的服务,还有并发的连接数量超过阈值的服务,然后对剩余的服务列表按照轮询策略进行访问;
WeightedResponseTimeRule:根据平均响应时间计算所有服务的权重,响应时间越快的服务权重越大被选中的概率越大。刚启动时如果统计信息不足,则使用RoundRobinRule(轮询)策略,等统计信息足够,会切换到WeightedResponseTimeRule;
RetryRule:先按照RoundRobinRule(轮询)策略获取服务,如果获取服务失败则在指定时间内进行重试,获取可用的服务;
BestAvailableRule:会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务;
ZoneAvoidanceRule:复合判断Server所在区域的性能和Server的可用性选择服务器;
如何配置
@Bean
public IRule xx() {
return new …
}
六.分布式架构下,Session 共享有什么方案
1.使用cookie来完成
用户登录成功后,将用户信息存储到cookie中
下次客户端访问服务器,通过判断是否有cookie从而判断是否登录
2.使用数据库同步session(效率不高)
用户登录成功后,将用户信息存储到session,然将session存储到数据库。
下次客户端访问服务器,从数据库中获取用户session;判断用户是否登录
3.使用token代替session(推荐)
七.分布式id生成方案
uuid
UUID长度过长,不适用于存储,耗费数据库性能。 ID无一定业务含义,可读性差。
基于redis、mongodb、zk等中间件生成
雪花算法
八.分布式锁解决方案
需要这个锁独立于每一个服务之外,而不是在服务里面,找一个公证人,这个人可以是:
数据库:利用主键冲突控制一次只有一个线程能获取锁,非阻塞、不可重入、单点、失效时间
Zookeeper分布式锁
Redis分布式锁
九.高并发场景下如何实现系统限流
Nginx限流
Redis+Lua限流
Spring Cloud Gateway限流
OpenResty限流
Sentinel限流