手机网站设计规格,网站后台管理员扫描,wordpress支付回调,全球最好的域名注册公司Spring Cloud面试突击班1
1.Spring Cloud 中有哪些组件#xff0c;整个项目架构中我们的重点又有哪些#xff1f;
Spring Cloud 是一套基于Spring Boot的微服务解决方案。
Spring Cloud生态在国内主流的分为两套#xff0c;一套是以奈飞开源的Spring Cloud Netfilx 20%整个项目架构中我们的重点又有哪些
Spring Cloud 是一套基于Spring Boot的微服务解决方案。
Spring Cloud生态在国内主流的分为两套一套是以奈飞开源的Spring Cloud Netfilx 20%一套是阿里巴巴开源的Spring Cloud Alibaba 40%在国外其实Azure以及Amzong同时也有一些单独的组件特别火比如Spring Cloud Getaway以及Spring Cloud Consul等等
5大核心组件
注册中心 zk eureka nacos consul 服务治理 架构特性
配置中心 nacos config disconf
网关 Spring Cloud getaway zuul2 zuul
负载均衡 Ribbon loadbalance
声明式远程调用 OpenFegin
3大核心配件
断路器 sentinel 信号量隔离滑动时间窗口的方式 hystrix 线程池隔离
日志监控 Elastic StackBeats Promethus grafan
链路追踪 skywalking CAT pingpoint zipkin
3大常见分布式解决方案
分布式事务 tx-lcn seate 分布式锁 redis zk
2大中间件
Redis MQ
2大性能优化方案
JVM性能优化 MySQL性能优化 2.注册中心技术选型的要素有哪些
组件的服务治理特性
8大服务治理功能
服务注册
服务续约
服务获取
服务调用
服务下线
失效剔除
自我保护
服务同步
架构特性
CAP定理
定义CAP原则又称CAP定理指的是在一个分布式系统中 一致性Consistency、可用性Availability、 分区容错性Partition tolerance。CAP 原则指的是这三个要素最多只能同时实现两点不可能三者兼顾
分区容错性 分区指的是由于网络或者一些不可控因素导致集群中某些节点不连通的情况而分区容错性指的是当我们的分布式系统出现了分区的情况时还能够对外提供正常的服务叫做分区容错性
在目前看来分区容错性在一个分布式系统中基本上是必备
在一个分布式系统中由于分区容错性是一定要存在的那么我们就需要在可用性和一致性上做相关的取舍下面我们来分析为什么C与A两种状态不能同时存在
CP模式 现在我们的Nacos集群中存在三个节点一个主节点两个从节点当主节点与一个从节点出现了分区后如果我们的前提是需要保证整个系统的一致性也就是需要保证Consistency这个状态存在
整个集群会发起主节点的重新选举选举完成后同步所有的数据来保持数据的一致性那么在选主的过程中一定会导致一段时间的不可用当然这个时间会极短从而不能保证完全可用性
AP模式 在AP模式下我们的集群没有主从的概念所有的节点都是平等的并且每个节点间的数据都互通
如果两个节点中间发生了分区情况两个节点不再连通但是我们的系统又必须保证整体的可用性所以节点间会出现一段时间的数据不一致直到分区恢复
3.Nacos的Raft一致性算法
Raft算法
在学术界中分布式一致性算法的基石还是Paxos为代表Paxos算法是Lamport宗师提出的一种基于消息传递的分布式一致性算法使其获得2013年图灵奖。
由于Paxos难以理解而且很难落地到工程实践所以Paxos在工程中运用的并不多
取而代之的是易理解易实现的Raft算法号称几乎等同于Paxos但是性能肯定不及Paxos
分布式一致性算法也称为共识算法是指在大型分布式系统中在遇到请求时各个节点的数据能够保持一致并且在遇到部分机器宕机时也能保证整体服务的数据一致性
学习Raft算法最好的方式则是阅读论文https://raft.github.io/raft.pdf 关于Raft协议步骤动画http://thesecretlivesofdata.com/raft/
这里我们了解Raft算法中核心逻辑Raft算法中其实大致分为三个子问题 Leader Election 、Log Replication、Safety对应的也就是选主日志复制安全性通过安全性原则来处理一些特殊 case保证 Raft 算法的完备性
Raft的核心流程归纳
首先选出 leaderleader 节点负责接收外部的数据更新/删除请求 然后日志复制到其他 follower节点同时通过安全性的准则来保证整个日志复制的一致性 如果遇到 leader 故障followers 会重新发起选举出新的 leader Raft节点有三种状态
Leader领导者 Follower跟随者 Candidate候选人 Leader Election 领导选举 所有节点一开始都是follower状态一定时间未收到leader的心跳则进入candidate候选人状态参与选举.选出leader后leader通过向follower发送心跳来表明存活状态若leader故障则整体退回到重新选举状态 每次选举完成后会产生一个termterm本身是递增的充当了逻辑时钟的作用 具体的选举过程领导者与跟随者建立心跳心跳时间随机为了避免大多数跟随者在同一时间进行选举并等待若超时未等到准备选举 ---- current term 转变为candidate候选人状态 ---- 给自己投票然后给其他节点发送投票请求 ---- 等待选举结果
具体投票过程有三个约束
在同一任期内单个节点最多只能投一票 候选人知道的信息不能比自己的少(Log与term) first-come-first-served 先来先得
选举结果有三种情况
收到大部分超过半数的投票含自己的一票则赢得选举成为leader 被告知别人已当选那么自行切换到follower 一段时间内没有收到超过半数以上的投票则保持candidate状态重新发出选举。ps:如果是遇到平票现象则会增加系统不可用时间因此raft中引入了randomized election timeouts尽量避免出现平票现象的产生一旦选举完毕leader节点会给所有其他节点发消息避免其他节点触发新的选举
Log Replication 日志复制问题
Replicated state machine 复制状态机
分布式服务中为了保证流量不会压垮服务器会将一个server复制成很多副本同时提供相同的服务。多副本服务就会出现副本的一致性问题比如client1将replica1的X值设置为1而client2将replica2的X值设置为2这样如果另一个客户client3从不同的副本获取到的X值可能是1也可能是2这就导致了副本的一致性问题。
复制状态机就是用来解决副本的一致性问题的每个副本都是状态机的实现而且是确定状态机(Deterministic finite-state machine)。使用状态机来实现每个服务器的副本就保证了对相同的输入每个副本都会产生一致的输出。并且将每个客户端的请求汇总成一个序列每个副本都按照这个序列来执行这就解决了副本的不一致问题。
复制状态机Replicated State Machine是指多台机器具有完全相同的状态运行完全相同的确定性状态机。它让多台机器协同工作犹如一个强化的组合其中少数机器宕机不影响整体的可用性。复制状态机是实现容错的基本方法被广泛应用于数据复制和高可用等场景一直是工业界和学术界的关注热点。越来越多的系统采用复制状态机来实现高可用如ZooKeeper、ETCD、MySQL Group Replication、TiDB等各种复制协议和系统架构的研究也层出不穷。如何抽象一个复制状态机系统的架构使之更加通用和易用呢本文从复制状态机模型出发结合一些业界的前沿研究总结复制状态机系统的架构抽象在系统架构设计时具有一定参考意义。
复制状态机一般通过复制日志来实现简单地描述一下leader将写请求封装成一个个的 log entry然后将这些 entries复制到 follower从节点所有 follower都按照这个这个顺序执行其中的 command指令那么所有 server的状态一定是一致的。这就是 raft的做法 复制过程 1.客户端的请求包含了被复制状态机执行的指令并转发给leader
2.leader把指令作为新的日志并发送给其他server让他们复制。
3.假如日志被安全的复制收到超过majority的ackleader会将日志添加到状态机中并返回给客户端
4.如果follower丢失leader会不断重试直到全部follower都最终存储了所有日志条目
当然以上都是理想情况如果出现崩溃、网络中断等情况则可能出现日志不正常的现象则需要考虑数据一致性和安全性问题
4.Eureka注册表多级缓存架构有了解过吗 5.在微服务中有几种限流方式
令牌桶
令牌桶算法是网络流量整形Traffic Shaping和速率限制Rate Limiting中最常使用的一种算法。典型情况下令牌桶算法用来控制发送到网络上的数据的数目并允许突发数据的发送。
令牌桶是一个存放固定容量令牌token的桶按照固定速率往桶里添加令牌; 令牌桶算法实际上由三部分组成两个流和一个桶分别是令牌流、数据流和令牌桶
令牌流与令牌桶
系统会以一定的速度生成令牌并将其放置到令牌桶中可以将令牌桶想象成一个缓冲区可以用队列这种数据结构来实现当缓冲区填满的时候新生成的令牌会被扔掉。这里有两个变量很重要
第一个是生成令牌的速度一般称为 rate 。比如我们设定 rate 2 即每秒钟生成 2 个令牌也就是每 1/2 秒生成一个令牌
第二个是令牌桶的大小一般称为 burst 。比如我们设定 burst 10 即令牌桶最大只能容纳 10 个令牌。
数据流
数据流是真正的进入系统的流量对于http接口来说如果平均每秒钟会调用2次则认为速率为 2次/s。
漏桶
漏桶算法思路是不断的往桶里面注水无论注水的速度是大还是小水都是按固定的速率往外漏水如果桶满了水会溢出
桶本身具有一个恒定的速率往下漏水而上方时快时慢的会有水进入桶内。当桶还未满时上方的水可以加入。一旦水满上方的水就无法加入。桶满正是算法中的一个关键的触发条件即流量异常判断成立的条件。而此条件下如何处理上方流下来的水有两种方式
在桶满水之后常见的两种处理方式为
1暂时拦截住上方水的向下流动等待桶中的一部分水漏走后再放行上方水。
2溢出的上方水直接抛弃。
特点
漏水的速率是固定的
即使存在注水burst突然注水量变大的情况漏水的速率也是固定的 计数器
这个最简单比如用Redis做计数器
计数器算法是使用计数器在周期内累加访问次数当达到设定的限流值时触发限流策略。下一个周期开始时进行清零重新计数。此算法在单机还是分布式环境下实现都非常简单使用redis的incr原子自增性和线程安全即可轻松实现。 滑动窗口
滑动窗口协议是传输层进行流控的一种措施接收方通过通告发送方自己的窗口大小从而控制发送方的发送速度从而达到防止发送方发送速度过快而导致自己被淹没的目的。
简单解释下发送和接受方都会维护一个数据帧的序列这个序列被称作窗口。发送方的窗口大小由接受方确定目的在于控制发送速度以免接受方的缓存不够大而导致溢出同时控制流量也可以避免网络拥塞。下面图中的4,5,6号数据帧已经被发送出去但是未收到关联的ACK7,8,9帧则是等待发送。可以看出发送端的窗口大小为6这是由接受端告知的。此时如果发送端收到4号ACK则窗口的左边缘向右收缩窗口的右边缘则向右扩展此时窗口就向前“滑动了”即数据帧10也可以被发送。
参考如下网址提供的动态效果
https://media.pearsoncmg.com/aw/ecs_kurose_compnetwork_7/cw/content/interactiveanimations/selective-repeat-protocol/index.html
6.熔断与降级的区别
在分布式系统中限流和熔断是处理并发的两大利器。关于限流和熔断需要记住一句话客户端熔断服务端限流。
发现为什么是限流和熔断而不是限流和降级所以下面我特地讲一讲他们的区别。
相似处 1.目的一致
都是为了系统的稳定性防止因为个别微服务的不可用而拖死整个系统服务
2.表现类似
在表现上都是让用户感知该服务暂时不可用请稍后再试
3.粒度一致
粒度上都是服务级别的粒度某些情况下也有更细的粒度如数据的持久层只允许查询不允许增删改。
主要区别 1.触发条件不同
服务熔断一般是某个服务挂掉了引起的一般是下游服务而服务降级一般是从整体的负荷考虑主动降级
2.管理目标的层次不同
熔断其实是一个框架级的处理每个微服务都需要没有层次之分而降级一般需要对业务有层级之分一般是从最外围服务开始。
7.断路器的隔离方式线程池隔离以及信号量隔离有什么区别
在断路器中介绍两种处理高并发的解决方案。
首先需要理解高并发的情况下系统会出现什么样的问题。
当部署完一个服务后这个服务会向外界开放多个接口 比如 一个烂大街的商城系统可能有 订单查询接口 个人中心接口 付款接口 商品查询接口。 当服务部署好之后没有其他配置时 tomcat默认开启一个线程池 这个线程池中有200个线程供使用。 这时候 这四个接口都有对这个线程池的使用权也就是说这四个接口共享一个线程池。 当访问量小的时候系统没有问题 但是遇到突发情况比如一类爆款商品降价 导致了商品查询接口访问量激增。 商品查询接口占用了线程池中大量的线程 导致其他三个接口抢不到线程从而没有线程可用 这时候 由于四个接口共享一个线程池 当一个接口访问量激增而占用大量资源时 导致其他三个接口抢不到资源进而导致自身功能不可用。
线程池隔离
这时候提出一种解决方案–线程池隔离。
线程池隔离的思想是: 把tomcat中先一个线程池分成两个线程池. 比如tomcat线程池中初始有200个线程, 分成两个线程池A , B后, A线程池有50个线程可以用, B线程池有150个线程可以用. 将访问量较大的接口单独配置给一个线程池, 其他接口使用另一个线程池 , 使其访问量激增时不要影响其他接口的调用.
然后, 将访问量暴增的接口访问交给A线程池, 其他接口的访问交给B线程池. A , B两个线程池是相互隔离的, 互不影响. 这时候, 如果商品查询接口访问量激增 , 被挤爆的线程池也只是A线程池, A,B线程池互不影响, 所以其他接口如: 个人中心接口, 付款接口, 订单查询接口依然可用.
线程池隔离主要针对C端用户对服务的访问. 线程池隔离起到分流的作用.
信号量隔离
还有一种是新思路是采用信号量隔离方式.
可以把信号量理解成一个计数器 , 对这个计数器规定一个计数上限, 代表一个接口被访问的最大量.
假定设置 付款接口的信号量最大值为10,(这个接口最多占用线程池中10个线程) 初始值为0. 每调用一次接口信号量加一 , 接口处理完后信号量减一. 当信号量值达到最大时 , (10时) , 对后续的调用请求拒接处理.
信号量隔离主要是针对各个服务内部的调用处理, 起到限流的作用.
8.API网关的工作流程
客户端向Spring Cloud Gateway发出请求。如果网关处理程序映射Gateway Handler Mapping确定请求与路由匹配则将其发送到网关Web处理程序Gateway Web Handler。该处理程序通过特定于请求的过滤器链来运行请求。过滤器器由虚线分隔的原因是过滤器可以在发送代理请求之前和之后运行逻辑。所有“前置”过滤器逻辑均被执行。然后发出代理请求。发出代理请求后将运行“后置”过滤器逻辑。图中虚线左边的对应于前置过滤器虚线右边的对应于后置过滤器。
前置过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等后置过滤器可以做响应内容、响应头的修改、日志的输出、流量监控等。
SpringCloud Gateway的核心逻辑其实就是路由转发和执行过滤器链
过滤器执行顺序
请求进入网关会碰到三类过滤器当前路由的过滤器、DefaultFilter、GlobalFilter
请求路由后会将当前路由过滤器和DefaultFilter、GlobalFilter合并到一个过滤器链集合中排序后依次执行每个过滤器 排序的规则是什么呢
每一个过滤器都必须指定一个int类型的order值order值越小优先级越高执行顺序越靠前。
GlobalFilter通过实现Ordered接口或者添加Order注解来指定order值由我们自己指定
路由过滤器和defaultFilter的order由Spring指定默认是按照声明顺序从1递增。
当过滤器的order值一样时会按照 defaultFilter 路由过滤器 GlobalFilter的顺序执行。
