榆林网站建设熊掌号,淘宝网页设计尺寸,昌吉哪个公司做网站,做分子生物实验常用网站微服务篇
springcloud
常见组件有哪些
面试官#xff1a; Spring Cloud 5大组件有哪些#xff1f;
候选人#xff1a;
早期我们一般认为的Spring Cloud五大组件是
Eureka#xff1a;注册中心Ribbon#xff1a;负载均衡Feign#xff1a;远程调用Hystrix#xff1a;…微服务篇
springcloud
常见组件有哪些
面试官 Spring Cloud 5大组件有哪些
候选人
早期我们一般认为的Spring Cloud五大组件是
Eureka注册中心Ribbon负载均衡Feign远程调用Hystrix服务熔断Zuul/Gateway网关
随着SpringCloudAlibba在国内兴起我们项目中使用了一些阿里巴巴的组件
Nacos注册中心/配置中心Ribbon负载均衡Feign服务调用sentinel服务保护Gateway网关
注册中心eureka、nacos
面试官 服务注册和发现是什么意思Spring Cloud 如何实现服务注册发现
候选人
我理解的是主要三大块功能分别是服务注册、服务发现、服务状态监控
我们当时项目采用的eureka作为注册中心这个也是spring cloud体系中的一个核心组件
服务注册服务提供者需要把自己的信息注册到eureka由eureka来保存这些信息比如服务名称、ip、端口等等
服务发现消费者向eureka拉取服务列表信息如果服务提供者有集群则消费者会利用负载均衡算法选择一个发起调用
服务监控服务提供者会每隔30秒向eureka发送心跳报告健康状态如果eureka服务90秒没接收到心跳从eureka中剔除
面试官 我看你之前也用过nacos你能说下nacos与eureka的区别
候选人
我们当时xx项目就是采用的nacos作为注册中心选择nacos还有一个重要原因就是它支持配置中心不过nacos作为注册中心也比eureka要方便好用一些主要相同不同点在于几点
共同点
Nacos与eureka都支持服务注册和服务拉取都支持服务提供者心跳方式做健康监测
Nacos与Eureka的区别
①Nacos支持服务端主动检测提供者状态临时实例采用心跳模式
②临时实例心跳不正常会被剔除非临时实例则不会被剔除
③Nacos支持服务列表变更的消息推送模式服务列表更新更及时
④Nacos集群默认采用AP方式当集群中存在非临时实例时采用CP模式Eureka采用AP模式
ribbon负载均衡
面试官 你们项目负载均衡如何实现的
候选人
是这样~~
在服务调用过程中的负载均衡一般使用SpringCloud的Ribbon组件实现Feign的底层已经自动集成了Ribbon使用起来非常简单
当发起远程调用时ribbon先从注册中心拉取服务地址列表然后按照一定的路由策略选择一个发起远程调用一般的调用策略是轮询
面试官 Ribbon负载均衡策略有哪些
候选人
我想想啊有很多种我记得几个
RoundRobinRule简单轮询服务列表来选择服务器WeightedResponseTimeRule按照权重来选择服务器响应时间越长权重越小RandomRule随机选择一个可用的服务器ZoneAvoidanceRule区域敏感策略以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务器做轮询默认
面试官 如果想自定义负载均衡策略如何实现
候选人
提供了两种方式
创建类实现IRule接口可以指定负载均衡策略这个是全局的对所有的远程调用都起作用在客户端的配置文件中可以配置某一个服务调用的负载均衡策略只是对配置的这个服务生效远程调用
服务雪崩、熔断降级
面试官 什么是服务雪崩怎么解决这个问题
候选人
服务雪崩是指一个服务失败导致整条链路的服务都失败的情形一般我们在项目解决的话就是两种方案第一个是服务降级第二个是服务熔断如果流量太大的话可以考虑限流
服务降级服务自我保护的一种方式或者保护下游服务的一种方式用于确保服务不会受请求突增影响变得不可用确保服务不会崩溃一般在实际开发中与feign接口整合编写降级逻辑
服务熔断默认关闭需要手动打开如果检测到 10 秒内请求的失败率超过 50%就触发熔断机制。之后每隔 5 秒重新尝试请求微服务如果微服务不能响应继续走熔断机制。如果微服务可达则关闭熔断机制恢复正常请求
微服务的监控
面试官 你们的微服务是怎么监控的
候选人
我们项目中采用的skywalking进行监控的
1、skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢我们可以针对性的分析和优化。
2、我们还在skywalking设置了告警规则特别是在项目上线以后如果报错我们分别设置了可以给相关负责人发短信和邮件第一时间知道项目的bug情况第一时间修复
分布式系统理论
CAP和BASE
面试官 什么是CAP理论
候选人
CAP主要是在分布式项目下的一个理论。包含了三项一致性、可用性、分区容错性
一致性(Consistency)是指更新操作成功并返回客户端完成后所有节点在同一时间的数据完全一致(强一致性)不能存在中间状态。可用性(Availability)是指系统提供的服务必须一直处于可用的状态对于用户的每一个操作请求总是能够在有限的时间内返回结果。分区容错性(Partition tolerance)是指分布式系统在遇到任何网络分区故障时仍然需要能够保证对外提供满足一致性和可用性的服务除非是整个网络环境都发生了故障。
面试官 为什么分布式系统中无法同时保证一致性和可用性
候选人
嗯是这样的~~
首先一个前提对于分布式系统而言分区容错性是一个最基本的要求因此基本上我们在设计分布式系统的时候只能从一致性C和可用性A之间进行取舍。
如果保证了一致性C对于节点N1和N2当往N1里写数据时N2上的操作必须被暂停只有当N1同步数据到N2时才能对N2进行读写请求在N被暂停操作期间客户端提交的请求会受到失败或超时。显然这与可用性是相悖的。
如果保证了可用性A那就不能暂停N2的读写操作但同时N1在写数据的话这就违背了一致性的要求。
面试官 什么是BASE理论
候选人
嗯这个也是CAP分布式系统设计理论
BASE是CAP理论中AP方案的延申核心思想是即使无法做到强一致性StrongConsistencyCAP的一致性就是强一致性但应用可以采用适合的方式达到最终一致性Eventual Consitency。它的思想包含三方面
1、Basically Available基本可用基本可用是指分布式系统在出现不可预知故障的时候允许损失部分可用性但不等于系统不可用。
2、Soft state软状态即是指允许系统中的数据存在中间状态并认为该中间状态的存在不会影响系统的整体可用性即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
3、Eventually consistent最终一致性强调系统中所有的数据副本在经过一段时间的同步后最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致而不需要实时保证系统数据的强一致性。
业务问题
微服务限流
面试官 你们项目中有没有做过限流怎么做的
候选人
我们当时做的xx项目采用的就是微服务的架构因为xx因为应该会有突发流量最大QPS可以达到2000但是服务支撑不住我们项目都通过压测最多可以支撑1200QPS。因为我们平时的QPS也就不到100为了解决这些突发流量所以采用了限流。
【版本1】
我们当时采用的nginx限流nginx使用的漏桶算法来实现过滤让请求以固定的速率处理请求可以应对突发流量我们控制的速率是按照ip进行限流限制的流量是每秒20
【版本2】
我们当时采用的是spring cloud gateway中支持局部过滤器的RequestRateLimiter来做限流使用的是令牌桶算法可以根据ip或路径进行限流可以设置每秒填充平均速率和令牌桶总容量
面试官 限流常见的算法有哪些呢
候选人
比较常见的限流算法有漏桶算法和令牌桶算法
漏桶算法是把请求存入桶中以固定速率从桶中流出可以让我们的服务做到绝对的平均起到很好的限流效果
令牌桶算法在桶中存储的是令牌按照一定的速率生成令牌每个请求都要先申请令牌申请到令牌以后才能正常请求也可以起到很好的限流作用
它们的区别是漏桶和令牌桶都可以处理突发流量其中漏桶可以做到绝对的平滑令牌桶有可能会突然产生突发大量请求的情况一般nginx限流采用的漏桶spring cloud gateway中可以支持令牌桶算法
分布式事务解决方案
面试官 你们采用哪种分布式事务解决方案
候选人
我们当时是xx项目主要使用到的seata的at模式解决的分布式事务
seata的AT模型分为两个阶段
1、阶段一RM的工作①注册分支事务 ②记录undo-log数据快照③执行业务sql并提交 ④报告事务状态
2、阶段二提交时RM的工作删除undo-log即可
3、阶段二回滚时RM的工作根据undo-log恢复数据到更新前
at模式牺牲了一致性保证了可用性不过它保证的是最终一致性
分布式服务的接口幂等性
面试官 分布式服务的接口幂等性如何设计
候选人
嗯我们当时有一个xx项目的下单操作采用的tokenredis实现的流程是这样的
第一次请求也就是用户打开了商品详情页面我们会发起一个请求在后台生成一个唯一token存入rediskey就是用户的idvalue就是这个token同时把这个token返回给前端
第二次请求当用户点击了下单操作后会携带之前的token后台先到redis进行验证如果存在token可以执行业务同时删除token如果不存在则直接返回不处理业务就保证了同一个token只处理一次业务就保证了幂等性
分布式任务调度
面试官 xxl-job路由策略有哪些
候选人
xxl-job提供了很多的路由策略我们平时用的较多就是轮询、故障转移、分片广播…
面试官 xxl-job任务执行失败怎么解决
候选人
有这么几个操作
第一路由策略选择故障转移优先使用健康的实例来执行任务
第二如果还有失败的我们在创建任务时们可以设置重试次数
第三如果还有失败的就可以查看日志或者配置邮件告警来通知相关负责人解决
面试官 如果有大数据量的任务同时都需要执行怎么解决
候选人
我们会部署多个实例共同去执行这批量的任务其中任务的路由策略是分片广播
在任务执行的代码中可以获取分片总数和当前分片按照取模的方式分摊到各个实例执行就可以了
