下面我们分享 接口级别高可用设计的架构模式和技巧。
接口高可用整体框架
雪崩效应：请求量超过系统处理能力后导致系统性能螺旋快速下降。
链式效应：某个故障引起后续一连串的故障。
接口高可用架构本质上是“丢车保帅”策略，业务或者用户体验会部分有损！
限流
用户请求全流程各个环节都可以限流：
请求端限流：发起请求的时候就进行限流，被限流的请求实际上并没有发给后端服务器。比如APP端、PC端。
接入端限流：接到业务请求的时候进行限流，避免业务请求进入实际的业务处理流程。比如Nginx、Api网关。
微服务限流：单个服务的自我保护措施，处理能力不够的时候丢弃新的请求。比如具体的业务服务。
限流具体实现方式
限流算法
时间窗
漏桶
java限流示例
漏桶算法变种 - 写缓冲(Buffer)
令牌桶
排队
基本原理：收到请求后并不同步处理，而是将请求放入队列，系统根据能力异步处理。
技术本质：请求缓存 + 同步改异步 + 请求端轮询。
应用场景：秒杀、抢购。
排队的架构示意图
【设计关键】
如何设计异步处理流程；
如何保证用户体验（前端、客户端交互）。
排队具体实现方案示例
1号店双十一秒杀排队
排队模块
负责接收用户的抢购请求，将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。
调度模块
负责排队模块到服务模块的动态调度，不断检查服务模块，一旦处理能力有空闲，就从排队队列头上把用户访问请求调入服务模块。
服务模块
是负责调用真正业务处理服务，并返回处理结果，并调用排队模块的接口回写业务处理结果。
降级
基本原理
直接停用某个接口或者 URL，收到请求后直接返回错误（例如 HTTP 503）。
应用场景
故障应急，通常将非核心业务降级，保住核心业务，例如降级日志服务、升级服务等。
降级架构实现
设计要点：
独立系统操作降级，可以是独立的降级系统，也可以是嵌入到其它系统的降级功能。
人工判断，人工执行
熔断
基本原理
下游接口故障的时候，一定时期内不再调用。
应用场景
服务自我保护，防止故障链式效应。
熔断架构实现
【实现细节】
可以通过配置中心，也可以通过配置文件来配置熔断策略；
熔断处理一般由框架或者 SDK 提供，例如 Dubbo + Hystrix；
熔断策略一般按照失败次数、失败比例、响应时长等来确定。