浙江省住房城乡建设厅官方网站,做新的网站seo,国外企业网络安全,网站如何备案 流程图文章目录 Spring Cloud1.Spring Cloud 5大组件有哪些#xff1f;2.服务注册和发现是什么意思#xff1f;Spring Cloud 如何实现服务注册发现#xff1f;3.负载均衡如何实现的 ?4.什么是服务雪崩#xff0c;怎么解决这个问题#xff1f;5.微服务是怎么监控的 业务相关6.项… 文章目录 Spring Cloud1.Spring Cloud 5大组件有哪些2.服务注册和发现是什么意思Spring Cloud 如何实现服务注册发现3.负载均衡如何实现的 ?4.什么是服务雪崩怎么解决这个问题5.微服务是怎么监控的 业务相关6.项目中有没有做过限流 ? 怎么做的 ?7.解释一下CAP和BASE8.分布式事务解决方案9.分布式服务的接口幂等性如何设计10.分布式任务调度 Spring Cloud
1.Spring Cloud 5大组件有哪些
以下面这幅图为例 通常情况下可以分为
Eureka : 注册中心Ribbon : 负载均衡Feign : 远程调用Hystrix : 服务熔断Zuul/Gateway : 网关
一般现在使用SpringCloudAlibba比较多
注册中心/配置中心 Nacos负载均衡 Ribbon服务调用 Feign服务保护 sentinel服务网关 Gateway 2.服务注册和发现是什么意思Spring Cloud 如何实现服务注册发现 注册中心的核心作用是服务注册和发现 而现在常用的注册中心可以分为两种
Eureka(被动型 具体流程
服务注册服务提供者需要把自己的信息注册到eureka由eureka来保存这些信息比如服务名称、ip、端口等等服务发现消费者向eureka拉取服务列表信息如果服务提供者有集群则消费者会利用负载均衡算法选择一个发起调用服务监控服务提供者会每隔30秒向eureka发送心跳报告健康状态如果eureka服务90秒没接收到心跳从eureka中剔除
nacos(主动型 具体流程
具体流程与Eureka类似
Nacos与eureka的共同点注册中心
都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别注册中心
Nacos支持服务端主动检测提供者状态 临时实例采用心跳模式非临时实例采用主动检测模式 临时实例心跳不正常会被剔除非临时实例则不会被剔除Nacos支持服务列表变更的消息推送模式服务列表更新更及时Nacos集群默认采用AP高可用方式当集群中存在非临时实例时采用CP强一致模式Eureka采用AP方式Nacos还支持了配置中心eureka则只有注册中心也是选择使用nacos的一个重要原因 3.负载均衡如何实现的 ?
微服务的负载均衡主要使用了一个组件Ribbon比如我们在使用feign远程调用的过程中底层的负载均衡就是使用了ribbon Ribbon负载均衡策略有哪些 ?
RoundRobinRule简单轮询服务列表来选择服务器WeightedResponseTimeRule按照权重来选择服务器响应时间越长权重越小RandomRule随机随机选择一个可用的服务器ZoneAvoidanceRule(就近原则区域敏感策略以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询(默认)(如果没有区域的概念就默认轮询
自定义负载均衡策略
有两种方式
创建类配置创建类实现IRule接口可以指定负载均衡策略全局 配置文件配置单个服务在客户端的配置文件中可以配置某一个服务调用的负载均衡策略局部 4.什么是服务雪崩怎么解决这个问题
服务与服务之间是存在互相调用的情况
服务雪崩就是一个服务失败导致整条链路的服务都失败的情形。 解决办法有两种
1. 服务降级(服务部分接口 服务降级是服务自我保护的一种方式或者保护下游服务的一种方式用于确保服务不会受请求突增影响变得不可用确保服务不会崩溃 一般在实际开发中与feign接口整合编写降级逻辑 例如上图update方法可以正常访问但是save方法不能访问这个时候就会走一个服务降级的方案也就是走另一个方案给用户一些提示消息 上图通过在服务接口上加上FeignClient注解指定服务的名字和出现异常后要降级的执行类
如果降级的接口达到一定数量就会触发熔断机制
2. 熔断机制整个服务 默认关闭需要手动打开如果检测到 10 秒内请求的失败率超过 50%就触发熔断机制。之后每隔 5 秒重新尝试请求微服务如果微服务不能响应继续走熔断机制。如果微服务可达则关闭熔断机制恢复正常请求 5.微服务是怎么监控的
1skywalking主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢我们可以针对性的分析和优化。2我们还在skywalking设置了告警规则特别是在项目上线以后如果报错我们分别设置了可以给相关负责人发短信和发邮件第一时间知道项目的bug情况第一时间修复 业务相关
6.项目中有没有做过限流 ? 怎么做的 ?
为什么要限流 1并发的确大突发流量 2防止用户恶意刷接口 限流的实现方式
Tomcat可以设置最大连接数
每一个服务都有一台tomcat服务器可以在通过Tomcat设置最大连接数但是这种只适合与单体项目 Nginx限流包括两种限流方式
控制速率突发流量 核心就是采用了漏桶算法做限流 使用的漏桶算法来实现过滤让请求以固定的速率处理请求可以应对突发流量 控制并发连接数 限制单个ip的链接数和并发链接的总数 3. 网关限流 在spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流使用的是令牌桶算法 可以根据ip或路径进行限流可以设置每秒令牌填充平均速率和令牌桶总容量 漏桶和令牌桶的区别 漏桶固定速率放行请求 令牌桶固定速率生成令牌请求拿到令牌则放行多余令牌则存储 令牌桶处理的速度可能会超过生成令牌的速度
7.解释一下CAP和BASE
CAP理论
Consistency一致性 用户访问分布式系统中的任意节点得到的数据必须一致 Availability可用性 用户访问集群中的任意健康节点必须能得到响应而不是超时或拒绝 Partition tolerance 分区容错性 因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接形成独立分区。在集群出现分区时整个系统也要持续对外提供服务 结论
分布式系统节点之间肯定是需要网络连接的分区P是必然存在的如果保证访问的高可用性A,可以持续对外提供服务但不能保证数据的强一致性– AP如果保证访问的数据强一致性C,就要放弃高可用性 -- CP
BASE理论 BASE理论是对CAP的一种解决思路包含三个思想
Basically Available 基本可用分布式系统在出现故障时允许损失部分可用性即保证核心可用。Soft State软状态在一定时间内允许出现中间状态比如临时的不一致状态。Eventually Consistent最终一致性虽然无法保证强一致性但是在软状态结束后最终达到数据一致。 核心在于事务协调器 解决分布式事务的思想和模型
最终一致思想各分支事务分别执行并提交如果有不一致的情况再想办法恢复数据AP强一致思想各分支事务执行完业务不要提交等待彼此结果。而后统一提交或回滚CP
8.分布式事务解决方案
Seata框架(XA、AT、TCC)
Seata事务管理中有三个重要的角色
TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态协调全局事务提交或回滚。TM (Transaction Manager) - 事务管理器定义全局事务的范围、开始全局事务、提交或回滚全局事务。RM (Resource Manager) -资源管理器管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。 XA模式(CP)
AT模式(AP) TCC模式(AP)
1、Try资源的检测和预留 2、Confirm完成资源操作业务要求 Try 成功 Confirm 一定要能成功。 3、Cancel预留资源释放可以理解为try的反向操作。
MQ 总结 只要是发生了多个服务之间的写操作都需要进行分布式事务控制
描述项目中采用的哪种方案seata | MQ 像银行业务就不需要高可用性只要达到最终一致就可以了 互联网业务就要高可用 seata的XA模式CP需要互相等待各个分支事务提交可以保证强一致性性能差银行业务seata的AT模式AP底层使用undo log 实现性能好互联网业务seata的TCC模式AP性能较好不过需要人工编码实现银行业务MQ模式实现分布式事务在A服务写数据的时候需要在同一个事务内发送消息到另外一个事务异步性能最好互联网业务
9.分布式服务的接口幂等性如何设计
幂等:多次调用方法或者接口不会改变业务状态可以保证重复调用的结果和单次调用的结果一致。
基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析 所以只有在请求方式是POST或者PUT情况下会出现接口不幂等的情况。
有三种解决方案
数据库唯一索引可解决新增带来的不幂等
如果数据库表没有唯一索引就不能保证新增操作的幂等性新增数据时会受唯一索引影响不能添加索引重复的数据
tokenredis新增、修改----性能好
创建商品、提交订单、转账、支付等操作
举例提交订单的例子 第一次请求生成一个唯一token存入redis返回给前端 第二次请求业务处理携带之前的token到redis进行验证如果存在可以执行业务删除token如果不存在则直接返回不处理业务 这样就解决了因为网络故障页面重复下单的问题因为token在进行第一次下单创建订单之后就会把redis中的token删除就算再次点击下单发现redis没有token导致验证失败自然不能完成下单动作 分布式锁新增、修改----性能差 原理就是保证下单动作不受影响直到完成下单才释放锁其他线程拿不到锁就马上显示失败操作就行而且使用分布式锁要保证锁的细粒度要精确枷锁不要锁住一些与原需要枷锁业务无关的业务枷锁导致整体性能变差 10.分布式任务调度
xxl-job路由策略有哪些 xxl-job提供了很多的路由策略平时用的较多就是轮询、故障转移、分片广播… xxl-job任务执行失败怎么解决 路由策略选择故障转移使用健康的实例来执行任务 设置重试次数 查看日志邮件告警来通知相关负责人解决
如果有大数据量的任务同时都需要执行怎么解决 让多个实例一块去执行部署集群路由策略分片广播 在任务执行的代码中可以获取分片总数和当前分片按照取模的方式分摊到各个实例执行 更新中------------- 素材来自----黑马程序员
