重庆最好的网站建设公司,花钱想贷款结果成了做网站,暖色系网站模板,全域seoSpring Cloud 组件 Spring Cloud五大组件有哪些#xff1f; Eureka#xff1a;注册中心 Ribbon#xff1a;负载均衡 Feign#xff1a;远程调用 Hystrix#xff1a;服务熔断 Zuul/Gateway#xff1a;服务网关 随着SpringCloud Alibaba在国内兴起#xff0c;我们项目中…Spring Cloud 组件 Spring Cloud五大组件有哪些 Eureka注册中心 Ribbon负载均衡 Feign远程调用 Hystrix服务熔断 Zuul/Gateway服务网关 随着SpringCloud Alibaba在国内兴起我们项目中使用了阿里巴巴的组件 注册中心/配置中心 Nacos 负载均衡 Ribbon 服务调用 Feign 服务保护 Sentinel 服务网关 Gateway
注册中心Eurake和注册中心Nacos Eurake工作原理
首先Eurake中会对所有的服务进行注册在Eurake中保存服务提供者的基本信息服务消费者在需要调用的时候就从Eurake中拉取服务然后在服务的消费者内部使用负载均衡的方式选取对应的服务然后直接去请求对应的服务Eurake与服务提供者通过心跳的方式保持监测Eurake会定期监测服务的心跳是否存在默认是30秒一次。一旦一个服务没有心跳那么在Eurake中会将这些服务剔除掉。
服务注册和服务发现是什么意思Spring Cloud如何实现服务注册发现的
我们当时采用的是Eurake作为注册中心这个是Spring Cloud体系中的一个核心的组件服务注册服务提供者需要把自己的信息注册在Eurake由Eurake来保存这些信息比如服务的名称ip端口等等。服务发现消费者向Eurake拉取服务列表信息如果服务提供者有集群则消费者利用负载均衡的算法选择一个进行调用服务监控服务提供者每隔30秒向Eurake发生心跳报告健康状态如果Eurake服务90秒没收到心跳从Eurake剔除当前服务。
Nacos工作原理 Nacos和Eurake的区别
Nacos和Eurake的共同点注册中心 都支持服务的注册和服务的拉取都支持服务提供者心跳的方式做健康检测 Nacos和Eurake的区别 Nacos支持服务端主动监测提供者的状态临时实例采用心跳模式非临时实例采用主动检测模式临时实例心跳不正常会被剔除非临时实例则不会剔除Nacos支持服务列表变更的消息推送模式服务列表更新更及时Nacos集群默认采用AP方式当集群中存在非临时实例时采用CP模式Eurake采用AP模式 Nacos还支持配置中Eurake则只是注册中心也是选择使用Nacos的一个重要的原因
Ribbon负载均衡
负载均衡Ribbon发起远程调用Feign就会使用RibbonRibbon的负载均衡策略有哪些如果自定义负载均衡如何实现 负载均衡流程 当一个服务需要调用另一个服务的时候发起请求进入RibbonRibbon再去注册中心区获取调用服务列表然后使用负载均衡的策略选取一个服务然后调用对应的服务。
负载均衡的策略有哪些
RoundRobinRule简单轮询服务列表选择服务器WeightedResponseTimeRule按照权重来选择服务器响应时间越长权重越小RandomRule随机选择一个可用服务器RestAvailableRule忽略哪些短路的服务器并选择并发数较低的服务器RetryRule重试机制的选择逻辑AvailabilityFilteringRule可用性敏感策略先过滤非健康的再选择连接数较小的实例ZoneAvoidanceRule以区域可用服务器为基础进行服务器的选择使用Zone对服务器进行分类这个Zone可以理解为一个机房一个机架而后再对Zone内的多个服务器做轮询。
如何自定义负载均衡策略 可以自己创建Rule接口然后通过配置类或者配置文件即可通过自定义IRule可以实现修改负载均衡规则有两种方式 负载均衡如何实现的 微服务中的负载均衡使用一个组件叫做Ribbon比如我们在使用Feign远程调用的过程底层的负载均衡使用了Ribbon
Ribbon负载均衡的策略有哪些
RoundRobbinRule简单轮询服务器列表选择服务器WeightedResponseTimeRule按照权重服务器响应时间越长权重越小RandomRule随机选择一个可用的服务器ZoneAvoidanceRule区域敏感策略以区域可用的服务器为基础进行服务器的选择使用Zone对服务进行分类这个Zone可以理解为一个机房一个机架等等而后对Zone内的多个服务器做轮询默认
Spring Cloud 服务雪崩 熔断降级 服务雪崩效应是一种因“服务提供者的不可用”原因导致“服务调用者不可用”结果并将不可用逐渐放大的现象。
通俗的来说就是在微服务中一个服务提供方挂了之后那么服务的调用者就会请求就会一直等待响应然后与此同时别的消费者也同样的来请求这个服务会导致服务的上游直接全部挂掉进而去影响服务的上上游造成雪崩的问题。
服务降级
服务降级是服务自我保护的一种方式或者保护下游服务器的一种方式用于确保服务不能受请求突增影响变得不可用确保服务不会崩溃。 降级的逻辑当前如果服务正常那么就走服务接口去请求数据如果服务不同的话直接去对服务进行降级访问自顶替的接口提示“获取数据失败”。
服务熔断 Hystrix熔断机制用于监控微服务调用的情况默认是关闭的如果开启需要再引导类上添加注解 EnableCircuitBreaker如果检测到10秒内请求失败率超过50%就会触发熔断机制之后每隔5秒重新尝试请求微服务如果微服务不能响应继续走熔断机制如果微服务可达则关闭熔断机制恢复正常请求。 什么是服务雪崩怎么解决这个问题
服务雪崩一个服务失败导致整条链路的服务都失败的情形服务降级服务自我保护的一种方式或者保护下游服务器的一种方式用于确保服务不会受请求突增影响变得不可用确保服务不会崩溃一般实际开发中与Feign接口整合编写降级逻辑。服务熔断默认关闭需要手动打开如果监测到10秒之内请求失败率超过百分之50%就触发熔断机制之后间隔每5秒重新尝试请求微服务如果微服务不能响应继续走熔断机制如果微服务可达关闭熔断机制恢复正常请求。 服务降级是针对某一个接口并不是某一个服务而服务熔断针对的是整个服务。 Spring Cloud微服务监控 第一个问题问题定位当spring cloud中某一个微服务挂了之后我们如何才能快速的定位到是哪一个微服务出现了问题 第二个问题性能分析假如某一条请求响应的异常的慢那么我们如何可以快速的定位到时那一条服务出现了问题呢 第三个问题服务的关系如果微服务中的服务量过小的话我们可能可以快速的梳理清楚服务之间的关系但是一旦服务量过大几百上千个微服务那么关系式很难梳理的 第四个问题服务告警假如当前一个服务出现了问题那么我们如何才能快速的知道哪一个服务出现了问题呢 性能监控工具
Spring-AdminprometheusGrafanazipkinskywalking 后两者是链路追踪工具 Skywalking 一个分布式系统的应用程序性能检测工具Applicatio Performance Managment提供了完善的链路追踪能力apache的顶级项目前华为产品经理吴晟主导开源的
服务service业务资源应用服务器微服务端点endpoint应用系统对外暴露的功能接口接口实例instance物理机 界面展示
仪表盘主要是展示当前注册的微服务的情况会按微服务的性能进行排序
服务追踪主要是可以展示每个微服务中的接口在响应的过程中每个步骤请求响应的耗时可以快速的定位服务的错误 拓扑图可以直观的展示出服务与服务之间的关联关系红色的服务表示不健康的服务 服务的告警会根据预先定义好的告警规则进行告警
规则如下
在过去的10分钟的3分钟内服务的平均响应时间超过1秒3次在过去的10分钟呢服务成功率低于80%达到2次在过去的10分钟内服务90%响应时间低于1秒达到3次在过去10分钟内服务的响应时间超过1秒达2次在过去10分钟内断点的响应时间超过1秒达2次
你们的微服务是怎么监控的
我们项目中采用skywalking进行监控的
skywalking主要可以监控接口服务物理实例的一些状态特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢我们可以针对性的分析和优化。我们还在skywalking设置了告警规则特别是在项目上线之后如果报错我们分别设置了可以给相关负责人发送短信和邮件通知第一时间知道项目的bug情况第一时间修复。
微服务限流
你们的项目中有没有做过限流怎么做的
为什么需要限流
并发量太大突发流量抢券业务
防止用户恶意刷接口
限流的实现方式
Tomcat可以设置最大连接数Nginx漏铜算法网关令牌桶算法自定义拦截器 Nginx限流
控制速率针对突发流量
语法limit_req_zone key zone ratekey: 定义限流对象binary_remote_addr 就是一种key基于客户端ip限流Zone定义共享存储区来存储访问信息10m可以存储16wip地址访问信息Rate最大访问速率。rate10r/s 表示每秒最多请求10个请求burst20相当于桶的大小Nodelay快速处理 算法解释个人
当大批量的请求突然过来的时候那么进入桶中算法就快速的进行执行响应
没有进入桶中的算法直接进行异常抛出处理
控制并发连接数
limit_conn perip 20对应的key是$binary_remote_addr,表示限制单个IP同时最多能持有20个连接limit_conn perserver 100对应的key是 $server_name, 表示虚拟主机server同时能处理并发连接的总数
网关限流
yml配置文件中微服务路由设置添加局部过滤器RequestRateLimiter 令牌桶算法 key-resolver定义限流对象ip路径参数需代码实现使用spel表达式获取
replenishRate令牌桶每秒填充平均速率
urstCapacity令牌桶总容量
你们的项目中有没有做过限流怎么做的
首先当时有一个活动到了假期抢购物券优惠券QPS最高可以达到2000平时10-50之间为了应对突发流量需要做限流常规的限流手段为了防止恶意攻击保证系统的正常运行我们当时系统能承受的最大的QPS是多少压测结果nginx限流控制速率突发流量使用的漏桶算法来实现过滤让请求以固定的速率处理请求可以应对突发流量控制并发数限制单个ip的链接数和并发链接的总数网关限流在Spring cloud gateway中支持局部过滤器RequestRateLimiter来做限流使用的是令牌桶算法可以根据ip或路径进行限流可以设置每秒填充的平均速率和令牌桶总容量
分布式系统理论
解释下CAP和BASE
CAP定理
1998年加州大学计算机科学家Eric Brewer提出分布式系统的三个指标
Consistency一致性Availability可用性Partiton tolerance分区容错性
Eric Brewer 说分布式系统无法同时满足这三个指标
这个结论叫做CAP定理
CAP定理–Consistency
Consistency一致性用户访问分布式系统中的任意节点得到的数据必须一致
CAP定理–Availability
Availability可用性用户访问集群中的任意健康节点必须能够得到响应而不是超时或者拒绝 CAP定理–Partition tolerance
Partition分区因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接形成独立的分区
Tolerance容错在集群出现分区时整个系统也要持续对外提供服务
结论
分布式系统节点之间肯定需要网络连接的分区P是必然存在的如果保证高可用性行A可以持续对外提供服务但是不能保证数据的强一致性 —AP如果保证数据强一致性C就要放弃高可用性 —CP
例如zookeeper就是AP模式的nacos做了cp和ap模式的切换
BASE理论
BASE理论是对CAP的一种解决思路主要包含了3个思想
Basically Available基本可用分布式系统出现故障时允许损失部分可用性即保证核心可用Soft State软状态在一定时间内允许出现中间状态比如临时不一致状态。Eventually Consistent最终一致性索然无法保留强一致性但是在软状态结束后最终达到数据一致。 当三个事务执行完成之后将三个事务提交到事务协调者中如果三个事务都成功那么就直接通过如果其中一个失败那么就逆向恢复剩下的两个事务。
解释一下CAP和BASE
CAP定理一致性可用性分区容错性 分布式系统节点通过网络连接一定会出现分区问题P当分区问题出现时系统的一致性C和可用性A就无法同时满足 BASE理论 基本可用软状态最终一致 解决分布式事务的思想和模型 最终一致思想各分支事务分别执行并提交如果有不一致的情况再想办法恢复数据AP强一致思想各个分支事务执行完业务不要提交等待彼此的结果而后统一提交或回滚CP
分布式事务解决方案
Seata架构
Seata事务管理中分为说那个重要的角色
TCTransaction Coordinator- 事务协调者维护全局和分支事务状态协调全局事务提交或回滚TMTransaction Manager - 事务管理器定义全局事务范围开始全局事务、提交或回滚全局事务RMResource Manager - 资源管理器管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或者回滚 seata的XA模式
RM一阶段的工作
注册分支事务到TC执行分支业务sql但不提交报告执行状态到TC
TC二阶段的工作
TC检测各分支事务执行状态如果事务成功通知所有RM提交事务如果有事务失败通知所有RM回滚事务
RM二阶段的工作
接收TC指令提交或者回滚事务 性能相对比较差因为各个事务需要相互等待保证数据的一致性
AT模式
AT模式同样是分阶段提交的事务类型不过缺弥补了XA模型中资源锁定周期过长的缺陷
阶段一RM的工作
注册分支事务记录undo-log数据快照执行业务sql并提交报告事务的状态
阶段二提交RM的工作
删除undo-log即可
阶段二回滚RM的工作
根据undo-log恢复数据到更新前 在事务开始之前会将数据缓存在undo-log文件中去然后开始执行事务如果事务都成功那么TC就告诉TM删除之前备份的undo-log文件如果有一个事务失败那么就根据undo-log文件恢复数据
TCC模式原理
try资源的检测和预留Confirm完成资源的业务操作要求Try成功Confirm一定要成功Cancel预留资源释放可以理解为try的方向操作。 AP模式它的性能是比较高的但是有一个问题就是try和confirm和cancel的阶段的业务必须去使用代码去实现而前两种是框架中自带的。
MQ分布式事务 你们采用那种分布式事务解决方案呢
描述项目中采用那种方案seata|mqseata的XA模式CP需要互相等待各个分支事务提交可以保证强一致性性能差 银行业务seata的AT模式AP需要底层使用undo-log实现性能好 互联网业务seata的TCC模式AP性能较好不过需要人工编码实现 银行业务MQ模式实现分布式事务在A服务写数据的时候需要在同一个事务内发送消息到另一个事务异步性能最好 互联网业务
分布式服务的接口幂等性
什么是接口幂等性
幂等多次调用方法或者接口不会改变业务状态可以保证重复调用的结果和单次调用的结果一致
需要幂等性场景
用户重复点击网络波动MQ消息重复应用使用失败或超时重试机制
接口幂等性
基于RESTFUL API的角度对常见类型请求的幂等性特点进行分析
请求方式说明GET查询操作天然幂等POST新增操作请求一次或请求多次造成的结果不同不是幂等性PUT更新操作如果一绝对值更新则是幂等的如果是通过增量的方式更新则不是幂等的DELETE删除操作根据唯一值删除是幂等的 保证接口幂等性的方式 tokenredis 描述在访问第一个页面的时候去生成一个token然后存储在redis中并且返回给前端等到了第二个支付页面的时候携带token进行请求如果成功删除token如果没有token就默认访问不成功
redis分布式锁 先拿到锁判断是否响应成功如果成功说明获取到了锁快速请求如果失败就快速失败
控制锁的粒度
分布式服务的接口幂等性如何设计
幂等多次调用方法或者接口不会改变业务状态可以保证重复调用的结果和单次调用结果一致如果是新增数据可以使用数据库的唯一索引如果新增或修改数据 分布式锁性能较低使用tokenredis来实现性能较好 第一次请求生成唯一的token存在redis返回给前端第二次请求过来业务处理携带之前的token到redis进行验证如果存在可以执行业务删除token如果不存在则返回不处理业务。
分布式任务调度
项目中使用的分布式任务调度工具
xxl-job解决的问题
解决集群任务的重复执行的问题cron表达式定义灵活定时任务失败了重试和统计任务量过大分片执行
xxl-job常见的问题
xxl-job路由策略有哪些xxl-job任务执行失败怎么解决如果有大数据量的任务同时需要执行怎么解决
xxl-job的路由策略有哪些
FIRST第一个固定选择第一个机器LAST最后一个固定的选择最后一台机器ROUND轮询RANDOM随机随机选择在线的机器CONSISTENT_HASH一致性HASH每个任务按照Hash算法固定选择某一台机器且所有任务均匀的散列在不同的机器上。LEAST_FREQUENTLY_USED最不经常使用使用频率最低的机器优先被选举LEAST_RECENTLY_USED最近最久未使用最近最久未使用的机器优先被选举FAILOVER故障转移按照顺序依次进行心跳检测第一个心跳检测成功的机器被选定为目标执行机器并发起调度BUSYOVER忙碌转移按照顺序依次进行空闲检测第一个空闲检测成功的机器被选定为目标执行器并发起调度SHARDING_BROADCAST分片广播广播触发对应集群中所有机器执行一次任务同时系统自动传递分片参数可根据分片参数开发分片任务。
xxl-job任务执行失败怎么解决
首先将任务执行策略修改为故障转移添加事务失败重试次数查看日志进行分析 ------ 最后使用邮箱进行警告 如果大数据量的任务同时需要执行怎么解决
执行器集群部署时任务路由策略选择分片广播的情况下一次任务调度将会广播触发对应的集群中所有执行器执行一次任务。 xxl-job路由策略有哪些
xxl-job提供了很多的路由策略我们平时用的较多的就是轮询故障转移分片广播
xxl-job任务执行失败怎么解决
路由策略选择故障转移使用健康的实例来执行任务设置重试次数查看日志邮件告警来通知相关负责人解决
如果大数据量的任务同时需要执行怎么解决
让多个实例一块去执行部署集群路由策略分片广播在任务执行的代码中可以获取分片总数和当前分片按照取模的方式分摊到各个实例执行。 笔记是对黑马课程中的知识进行的个人总结图片借鉴了课程视频中的资料感谢黑马程序员的开源精神哈哈如有问题联系我删除
