接口高可用设计

接口高可用

　　雪崩效应 请求超过系统处理能力后，性能螺旋快速下降。

　　　　限流

　　　　排队

　　链式效应 一个故障引起的一系列故障

　　　　熔断

　　　　降级

限流 各个环节都可以限流

　　请求端限流：发起请求时 不将请求发给后端

　　　　限制请求次数（变灰）

　　　　嵌入简单逻辑限流，比如随机数限流（秒杀中常见）

　　　　实现简单，流量本地控制，但是没法限制前端脚本。

　　接入端限流：接到业务请求时进行限流，避免进入实际业务流程

　　　　限制同一个用户请求频率

　　　　随机抛弃无状态请求

　　　　实现复杂，可以防刷，限流阈值需要人工处理

　　微服务限流：每个服务进行限流--自我保护

　　　　实现简单，处理能力不能精确配置。

 　　时间窗算法

　　　　固定时间窗： 统计固定时间窗内请求量，超过阈值则限流

　　　　　　存在临界点问题

　　　　滑动时间窗：统计滑动时间范围内请求量，超过则限流

　　　　　　实现复杂

　　漏桶算法：流出比较固定，流入不固定；总量控制，关键是桶大小。

　　　　桶大小比较难以调整，无法精确控制流出速度，突发流量时丢弃请求少

　　　　漏桶算法变种：写缓冲。

　　令牌桶：  请求获取令牌，拿不到则抛弃。 速率控制，令牌产生速度是关键

　　　　可以动态调整处理速度 突发流量时可能丢弃很多请求 实现相对复杂

排队： 请求放入队列异步处理

　　设计异步处理流程

　　保证用户体验

降级： 直接停用url或者某个接口

　　　最好人工判断，人工降级，谨慎aiops

熔断：  下游接口故障时，定期不再调用，防止链式效应

　　一般由框架或者SDK提供：dubbo+hystrix

　　一般按照失败次数，响应时间之类的进行判断