被面试官吊打(吊打面试官系列)
被面试官吊打(吊打面试官系列)集群进程热点隔离快慢隔离线程
引言当项目架构演进到微服务的时候,系统分布式部署,传统单个流程的本地 API 调用被拆分成多个微服务之间的跨网络调用,由于引入了网络通信、序列化和反序列化等操作,系统发生故障的概率提高了很多。而业界通常用多少个9来衡量系统的可用性,如99.99%表示一年中有1小时左右的不可用时间。那么如何有效确保微服务架构的可用性呢?
微服务可用性设计微服务的可用性通常可以从隔离、超时控制、过载保护、限流、熔断、降级、重试、负载均衡
隔离微服务隔离,本质上是对系统或者资源进行分割,从而实现当系统发生事故的时候可以限制传播范围和影响范围,只有发生故障的服务不可用,而其他服务依旧可以提供服务。
- 服务隔离
- 动静分离
动静分离:动静分离很好理解,现在的软件架构大部分都是前后端分离的模式,而前端的静态资源如图片、音视频等资源可以存储到oss云存储服务器,动态API则部署在ECS上来做到动静分离,静态文件访问负载全部通过CDN加速。
- 读写分离
读写分离:如数据库主从读写分离,DDD的CQRS模式 - 轻重隔离
核心隔离
核心隔离:根据业务进行资源划分,核心业务与非核心业务进行机器资源、依赖资源隔离,核心业务可以搭建多集群通过冗余资源来提升吞吐和容灾能力。
热点隔离
快慢隔离
- 物理隔离
线程
进程
集群
机房
超时控制超时控制,在微服务的调用中,我们希望组件能够快速失效,不希望等到实例连接超时而导致的页面无响应和请求挂起。这样不仅浪费资源同时也会导致用户体验感下降。
在实际业务开发中,各微服务的超时策略并不一定都清楚或者随着业务迭代超时策略发生变动,意外导致超时策略失效,就需要一个保底的机制,在基础库中设置默认超时策略来进行配置的防御保护。同时API服务的提供者需要定义好latency SLO,所有调用者都应遵守其超时策略的规定。
- 超时传递:如果一个请求有多个阶段,比如由一系列 RPC 调用组成,那么我们的服务应该在每个阶段开始前检查截止时间以避免做无用功,也就是要检查是否还有足够的剩余时间处理请求。
总而言之,超时控制是微服务可用性的第一道关,良好的超时策略可以尽可能的保证服务不堆积请求,不会挂掉,只有服务不挂掉才有能够执行后续的限流、熔断、降级、重试等策略
过载保护在微服务中由于服务间相互依赖很容易出现连锁故障,连锁故障可能是由于整个服务链路中的某一个服务出现故障,进而导致系统的其他部分也出现故障。之前讲的超时控制是为了保证服务在出现连接超时能够快速失败,消除请求积压,而过载保护则是在服务高负载的情况下的一种保护策略。
限流所谓限流是指在一段时间内,定义某个客户或者应用可以接收或者处理多少请求,通过限流,我们可以确保服务不会被高流量冲垮导致连锁故障,确保应用程序在自动扩展失效前都不会出现过载的情况。
限流算法:
- 令牌桶
令牌桶算法的核心是系统会以一定的速率往桶里添加令牌,处理请求前,则需要先从桶里获取一个令牌,当桶里没有令牌可取时,则返回失败。
所有的请求在处理之前都需要拿到一个可用的令牌才会被处理;
获取不到令牌,则请求返回失败
根据限流大小,设置按照一定的速率往桶里添加令牌;
桶设置最大的放置令牌限制,当桶满时、新添加的令牌就被丢弃或者拒绝;
- 漏斗桶
漏桶(Leaky Bucket)算法思路很简单 水(请求)先进入到漏桶里 漏桶以一定的速度出水(接口有响应速率) 当水流入速度过大会直接溢出(访问频率超过接口响应速率) 然后就拒绝请求 而当入小于出的情况下,漏桶不起任何作用。可以看出漏桶算法能强行限制数据的传输速率.示意图如下:
- 固定窗口
使用固定窗口实现限流的思路大致为,将某一个时间段当做一个窗口,在这个窗口内存在一个计数器记录这个窗口接收请求的次数,每接收一次请求便让这个计数器的值加一 如果计数器的值大于请求阈值的时候,即开始限流。当这个时间段结束后,会初始化窗口的计数器数据,相当于重新开了一个窗口重新监控请求次数。 - 滑动窗口
滑动窗口为固定窗口的改良版,解决了固定窗口在窗口切换时会受到两倍于阈值数量的请求,滑动窗口在固定窗口的基础上,将一个窗口分为若干个等份的小窗口,每个小窗口对应不同的时间点,拥有独立的计数器,当请求的时间点大于当前窗口的最大时间点时,则将窗口向前平移一个小窗口(将第一个小窗口的数据舍弃,第二个小窗口变成第一个小窗口,当前请求放在最后一个小窗口),整个窗口的所有请求数相加不能大于阀值。
- BBR
不管是漏斗桶还是令牌桶,缺点都太过明显,不能快速适应流量变化,限流的阈值需要人工设置,因此需要一种自适应的限流算法,这就是BBR动态流控算法。
通常BBR结合CoDel来实现过载保护
作者:悠悠听风
链接:https://www.cnblogs.com/zly-go/p/15545652.html