springcloud面试题
分布式理论
均衡负载
在计算机中,负载平衡可以改善跨计算机,计算机集群,网络连接,中央处理器单元或磁盘驱动器等多种计算资源的工作负载分布.负载平衡旨在均衡可以优化资源使用,最大化吞吐量,最小化响应时间,避免单一资源的过载.使用多个组件进行负载均衡而不是单个组件可能会通过冗余来提高可用性.
单体架构,分布式与集群
一个系统也无聊很小的时候将所有代码都放在一个项目中就好了,然后找个项目部署在一台服务器中.整个项目所有的服务都由这台服务器提供.这就是单机结构
优点在于,单一架构模式在项目初期很小的时候方便开发,测试方便,部署方便.缺点也很明显
随着时间的推进,假如的功能越来越多,最终会变得巨大,一个项目汇总有可能数百万行的代码,互相之前繁琐的jar包,久而久之,开发效率低,代码维护困难,任意模块的漏洞或者错误都会影响整个应用,降低系统的可靠性
由于整个系统运行需要使用到Tomcat和MySQL，单台服务器处理的能力有限,2G的内存需要分配给Tomcat和MySQL使用，随着业务越来越复杂，请求越来越多.。内存越来越不够用了，所以这时候我们就需要进行分布式的部署。
我们进行一个评论的请求，这个请求是需要依赖分布在两台不同的服务器的组件[Tomat和MySQL],才能完成的.。所以叫做分布式的系统。
但是分布式也是存在问题的,比如tomcat单点问题故障,一旦tomcat所在的服务器宕机不可用了,我们就无法提供服务了,所以针对单点故障的问题,我们会使用集群来解决.
单机处理到达瓶颈的时候,就把单点复制几分,这样就构成了一个集群。及群众的每台服务器都叫做集群中的一个节点。每个节点都提供相同的服务，这样系统的处理能力就提升了好几倍
但是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。
SOA架构(面向服务架构)
在分布式架构的下，当服务越来越多，容量的评估，小服务资源的浪费问题主键显现，此时需要增加一个调度中心对集群实现实时管理。此时用于资源调度和治理中心（SOA Service Oriented Architecture，面向服务架构）是关键
springcloud使用注册中心解决了服务之间服务之间调用关系的自动调节
缺点
- 服务之间会有依赖关系，一旦某个环节出错影响较大
- 服务复杂，运维测试，部署困难
CAP定理
CAP理论是分布式系统，特别是分布式存储领域中杯讨论最多的理论，C（Consistency）代表一致性A（Availability）代表可用性，p代表分区容错性（Partition tolerance）。CAP理论告诉我们，C,A,P三者不能同时满足，最多只能满足其中俩个
- 一致性（Consistency）：一个操作返回成功，那么只会的读请求都必须读到这个新数据；如果返回失败，那么所有读操作都不能读到这个数据。所有节点访问一份最新的数据
- 可用性（Availability）：对数据更新具备高可用性，请求能够及时处理，不会一直等待，即使节点失效
- 分区容错性（Partition tolerance）：系统中任意信息的丢失或失败不会影响系统的继续运作
理解CAP理论最简单的方式是想象俩个副本处于分区的俩侧，即俩个副本之间的网络断开，不能通信
- 如果允许其中一个副本更新，则会导致数据不一致，丧失了C的性质
- 如果为了保证一致性，将分区某一侧 的副本设置为不可用，那么又丧失了A性质
- 除非俩个副本可以互相通信，才能保证C又保证A，这又会导致丧失P的性质
BASE
basically Available(基本可用)分布式系统在出现不可预知的故障的时候,允许损失部分的可用性
Soft state(软状态)软状态也称为弱状态,和硬状态相对的,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同检点的数据副本之间进行数据监听的过程存在延时
Eventually consistent(最终一致性)最终一致性强调的是系统中所有的数据副本,在经过一段时间同步后,最终能到达到一个一致的状态.因此最终一致性的本职是需要系统保证最终数据能够达到一致,而不需要同保证数据的强一致性
分布式session
在传统糕点单体应用下，我们可以通过session去存储一些数据，但是在分布式和微服务的结构下，如果需要使用session就需要一些手段去维护
tomcat+redis
由于传统的应用都是基于tomcat去部署的，呜可以利用tomcat的redisSessionManager来讲session的数据存储在redis中
现在这种方案不怎么使用了，因为移植性很差,如果要换web容器就尴尬了
spring session+reids
给spring session配置基于redis来存储session数据,然后配置一个spring session的过滤器,这样的话,session相关操作都会给spring session来保管了.接着在代码中用原生session的操作,就是直接基于spring session从redis中获取数据了
现在这个方案还是比较主流的,因为主流的开发框架基本都是基于spring的开源框架.
springcloud
什么是springcloud
springcloud流应用程序启动器是基于springboot的spring集成应用程序,提供与外部系统的集成.他利用springboot的开发便捷性简化了分布式系统基础设施的开发,如服务发现注册,配置中心,路由,消息总线,均衡负载,断路器,数据监控等,都可以用到springboot的开发风格做到一键启动和部署.
设计目标,协调各个微服务,简化系统开发
优点
- 产出与spring家族,组件丰富给你齐全 ,为微服务提供了非常完整的支持
- 服务拆分粒度更细,耦合度更低,有利于资源利用,提高开发效率
- 减轻团队的成本,可以并行开发,不用再关注其他人怎么开发,关注自己的开发
- 可以跨平台,可以用任何一种语言调用或者开发
- 适用于互联网时代,产品周期更短
缺点
- 微服务过多,治理成本搞,维护系统麻烦
- 分布式系统开发的成本搞,对团队挑战大
springcloud和dubbo的区别
- 服务调用方式dubbo是RPC,springcloud是RestAPI
- 注册中心,dubbo是zoopkeeper,springcloud是eureka,也可以是zookeeper或者nacos
- 服务网关,dubbo本身没有实现,只能通过第三方技术整合,springcloud有zuul路由网关,作为路由服务器,进行消费者的请求转发,或getway
- springcloud 是阿帕奇旗下spring体系下的微服务解决方案Dubbo是阿里系的分布式服务治理框架
组件以及对比
zuul和getway
springcloudgetway是springcloud官方退出的第二代网关框架,取代zuul网关.
网关作为流量入口 ,在服务器中有着非常的作用,比如,路由转发,权限校验,限流控制等作用.
getway性能较高,是第一代zuul网关的1.6倍,内置了更多功能
nacos和eureka
eureka
eureka在设计是就精准AP原则,已停止更新
Eureka Server也可以运行多个实例来构建集群解决单点问题,但是不同于zookeeper的选举leader的过程,EurekaServer采用的是Peer to Peer对等通讯.这是一种去中心化的架构,唔master/slave之分,每一个peer都是对等的.在这种架构风格中,节点通过彼此互相注册来提高可用性,每个节点需要添加一个或多个有效的serviceURI指向其他节点.每个节点都可被视为其他节点的副本
在及群众如果某台eureka宕机clent的请求会自动切换到新的eureka Server节点上,当宕机的服务创新恢复后,eureka会再次将其纳入服务器管理之中.当一个新的Eureka Server节点启动后,会尝试从邻近节点获取所有注册列表信息,并完成初始化.默认情况下,如果Eureka Server在一定时间内没有接收到某个服务实例的心跳(默认周期为30秒)Eureka将会出校实例(90秒就会注销)
当Eureka Server节点在短时间内丢失过多心跳时,那么这个节点就会进入自我保护模式
Eureka的集群中,只要有一台Eureka还在,就能保证注册服务可用(保证可用性,)只不过查到的信息可能不是最新的(不保证强一致性)除此之外Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,Eureka就认为客户端与注册中心出现了网络故障,此时可能会出现以下几种情况
- Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务
- Eureka仍然能接受新服务注册和查询请求,但是不会被同步到其他节点是哪个(既保证当前节点依然可用)
- 当网络稳定是,当前实例新注册的信息会被同步到其他节点中
因此Eureka可用很好的应对网络故障导致部分节点失去联系的情况
Nacos
Nacos是阿里开源的,Nacos支持基于DNS和基于RCP的发现,在springCloud中使用Nacos,只需要下载并启动,Nacos只需要简单的配置就可以完成服务的注册发现
NAcos除了服务的注册发现之外,还支持动态的配置服务.动态配置服务开源让服务一中心化,外部化和动态化的方式管理所有环节的应用配置和服务配置.动态消除了配置变更时重新部署应用服务的需要.
Nacos = Spring Cloud注册中心 + Spring Cloud配置中心。(Nacos 天生负载均衡 集成了netflix-ribbon)
Hystrix和Sentinel
Hystrix的关注点在于以隔离熔断为主的容错机制,超时或被熔断的调用将会快速失败,并可以提供Fallback机制
而Sentinel的侧重点在于
- 多样的流量控制
- 熔断降级
- 系统负载保护
- 实时监控和控制台
资源模型和执行模型上的对比
| | sentinel | Hystrix |
| - | - | - |
| 隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
| 熔断降级策略 | 基于响应时间或失败比率 | 基于失败比率 |
| 实时指标实现 | 滑动窗口 | 滑动窗口(RxJava) |
| 扩展性 | 多个扩展点 | 插件的形式 |
| 基于注解的支持 | 支持 | 支持 |
| 限流 | 基于QPS,基于调用关系的限流 | 不支持 |
| 流量整形 | 支持慢启动,匀速器模式 | 不支持 |
| 系统负载保护 | 支持 | 不支持 |
| 控制台 | 开箱即用,可配置规则,查看秒级监控,机器发现等 | 不完善 |
| 常见框架搭配 | servlet,Springcloud Dubbo,gRPC | Servlet、Spring Cloud Netflix |
Sentinel框架相对于Hystrix功能更加完善
Nginx与Ribbon区别
nginx是反向代理
- 正向代理是客户端带里,代理客户端,服务端不知道实际发起的请求的客户端
- 反向代理是服务端代理,代理服务端,客户端不知道实际提供的服务端
nginx是服务器负载均衡,1客户端所有请求都会交给nginx,然后由nginx实现转发请求.即负载均衡是由服务端实现的。
ribbon本地负载均衡，在调用微服务接口的时候，会在注册中心上获取注册信息服务列表之后缓存到jvm本地，从而在本地实现RPC远程服务调用技术
集中式LB
即在服务端消费放和提供方之间使用独立的LB设施，有该设施复杂把访问过程通过某种策略转发至服务的提供方（nginx）
进程内LB
讲LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。
Ribbon就属于进程内LB，它只是一个类库，集成与消费方进程，消费方通过它来获取到服务提供方的地址
nginx和ribbon的负载均衡策略
Ribbon
- 随机策略：随机选择Server
- 轮询策略：轮询选择，我轮询index，选择index对应位置的server
- 重试策略：对选定的负载均衡策略上的重试机制，选择index对应位置的server
- 最低并发策略：逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server
- 可用过滤策略：过滤掉一直失败并被标记为circuit tripped的server，过滤掉哪些高并发链接的server或者使用一个AvailabilityPredicate来报过过滤server的逻辑，其实就是检查status里记录的各个运行状态
- 响应时间加权重策略：根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间短，权重搞，被选中的概率高。
- 区域权重策略：使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。
Nginx
- 轮询：默认，每个请求按时间顺序逐一分配到不同的后端服务器
- 权重（weight）：在轮询策略基础上指定轮询的几率
- ip_hash：指定负载均衡器按照基于客户ip的方式，确保相同客户的请求会被发送到相同的服务器
- least_conn：吧请求发给连接数较少的服务器
- 第三方策略，如fair：按照废弃物的响应时间来分配请求，响应时间短的优先分配，url_hash：访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，配合缓存命中来使用
熔断降级和限流
降级
当某个微服务的响应时间过程，或者不可用了，要把错误信息返回回来，或是一直卡在那，所以在服务端需要对调用不了的服务做降级。
熔断
熔断机制是应对雪崩小莹的一种微服务链路保护机制
当某个微服务不可用或者响应太长时间时，会进行服务降级，进而熔断该节点的微服务调用，返回错误的响应信息。
限流
顾名思义就是限制某个微服务的使用流量