1系统可用性常见策略及实现01
学习目标
- 系统可用性产生的原因和类型
- 常见系统可用性应对策略及实现方法
目录
- 服务不可用问题和基本对策
- 请求限流思想和设计方法
服务不可用问题和基本对策
分类
- 分布式环境的固有原因
- 服务自身失败
- 服务依赖失败（所依赖的服务失败导致自己失败）
应对服务失败的策略
- 服务提供者：快速失败，一旦自身服务发生错误，那么应该快速返回合理的处理结果
- 服务消费者：超时设置/重试，不要被服务提供者影响自身可用性
- 异步解耦，把服务依赖失败的影响分摊到消息中间件从而减低服务失败的概率
专项策略 - 集群容错
模块四-7讲 - 服务隔离
线程隔离（线程池隔离）、进程隔离、集群隔离、机房隔离、读写隔离、 - 请求限流
- 服务降级
请求限流思想和设计方法
概念
在流量高峰期或突增时，把流量速率限制在合理范围之内，不让系统被高流量击垮。
限流类型
- 流量控制：单位时间内调用量限流，并发调用限流
- 流量整形：漏桶算法限流、令牌桶算法限流
流量控制
单位时间内调用量限流
计数器，单位时间超过限制阈值，则把请求放入队列下一个时间段访问
临街问题：瞬间请求可能超过阈值
问题举例：10s限制10个请求，9.99s来了10个请求，10.01s来了10个请求，此时超出限制。
并发调用限流
滑动窗口解决临界问题
把单位时间设置为时间窗口，然后把时间窗口进行划分。
比方说我们可以把10秒这个单位时间划分成10个时间格，这样每格代表1秒钟。每过1秒钟，时间窗口往右滑动一格。每一个格子都有自己独立的计数器。
窗口的格子划分的越多越平滑，限流统计越精确
流量整形
漏桶算法
无论流量突发多大，漏铜保证流量常速率流出
令牌桶算法
系统以恒定的速度往桶里放入令牌，请求处理过程需先从桶里获取令牌，当桶里没有令牌可取时拒绝服务。如果某时间点桶存放很多令牌，可以在这一时间点响应很多的请求，因此请求的输入和输出都可以变速。
SpringCloud gateway 的实现？
漏桶算法和令牌桶算法的区别
漏桶算法强行限制数据的传输速率
令牌桶算法限制数据平均传输速率的同时还允许某种程度的突发传输
服务降级思想和设计方法
服务降级概念
服务器压力大时，将一些服务进行有策略得快速失败处理，避免影响核心服务。（前提服务分级）
降级可以有计划的执行，也可以被动触发。
如电商网站双十一期间对部分非核心业务手工降级
后者则包括系统运行时为了控制异常的影响范围在程序级别实现自动服务降级。
服务熔断
服务降级的常见实现方式
具体的技术组件就是熔断器（Circuit Breaker）
服务B先请求熔断器获取服务A状态，若可用则请求转发到服务A，若服务A不可用则直接返回不可用。
熔断器维护服务A的状态
熔断器组成结构
- Closed
熔断器关闭状态，不对服务调用进行限制，但会对调用失败次数进行积累，到了阈值或一定比例时则启动熔断机制 - Open
熔断器打开状态，此时对服务的调用将直接返回错误，不执行真正的网络调用。同时，熔兴断器设计了一个时钟选项，时钟达到了一定时间时会进入半熔断状态 - Half-0pen
半熔断状态，允许一定量的服务请求，如果调用都成功或达到一定比例则认为调用链路已恢复，关闭熔断器;否则认为调用链路仍然存在问题，又回到熔断器打开状态
服务回退
当远程调用发生异常时，服务回退(Fallback)并不是直接抛出该异常，而是产生一个另外的处理机制来应对该异常，相当于执行了另一条路径上的代码或返回一个默认处理结果，而这条路径上的代码或这个默认处理结果并一定满足业务逻辑的实现需求，而只是告知服务的消费者当前调用中所存在的问题。熔断器在执行熔断时通过调用回退方法为客户端请求提供反馈信息。
主流框架
思考题
熔断器的组合结构是怎么样的?它的内部状态又是如何流转的?