1.如何应对高峰流量

• 流量高峰可能会出现的问题

  • 依赖的资源和服务不可用，导致服务整体宕机（一损俱损）

    • 降级+熔断

  • 系统承载能力，出现拒绝服务的情况（500）

    • 使用限流

• 解决方案

  • 采取降级、熔断以及限流的方案

2.雪崩是如何发生的

• 系统运行时需要消耗资源的，

  • CPU、内存等系统资源

  • 执行业务逻辑的时候，需要的线程资源

    • 定义了线程池处理HTTP请求
    • RPC线程池（保证客户端与服务端长连接线程）

• 可以看出往往是由于一个小服务的阻塞，导致整体链路响应时间变长->导致资源不释放→线程池堆积的未处理请求增加

• 这种由于一个小节点的宕机导致的整体宕机（雪崩）

• 分布式系统中最怕不是一个服务或者组件宕机（监控宕机），响应缓慢（监控服务响应时长 95分位 99分位... 过滤掉敏感数据）

  • 使用熔断和降级
  • 监测一个服务的响应时间异常时，切断调用服务联系，让服务快速返回失败，释放本次请求持有的资源

• 慢比宕机更可怕（监测服务时长，观察用户体验，也观察服务情况）

3.熔断机制是如何做的

• 类似电路中保护机制，当电路超负荷运转的时候，保险丝会自动断开，保证整体电路不受影响

• 当调用失败次数超过一定的阈值后，后续请求直接返回错误

• 具体实现

  • 维护一个熔断有限状态机

    • 关闭调用远程调用
    • 半打开
    • 打开

  • 当调用失败的次数累积到一定的阈值时，熔断状态从关闭态切换到打开态

  • 当熔断处于打开状态时，启动一个超时计时器，当计时器超时后，状态切换到半打开态（定时探活）\

  • 累计一定的成功次数后，状态切换到关闭态\

• 不仅是微服务需要熔断机制，redis客户端等都需要（避免单个节点异常）

\

4.降级机制要如何做

• 降级是比熔断更大的概念

• 站在整体系统负载的角度上，放弃部分非核心功能和服务

• 实现方式（只针对非核心）

  • 开关限流（apollo），存储在配置中心中，不重启服务快速降级远程服务
  • 降级限流

• 场景

  • 数据库压力大的时候，返回静态数据
  • 增大轮训时间
  • 将同步写操作转换成异步写操作

• 需要对降级开关进行演练，保证开关的可用性

5.总结

• 每一个请求就会占用系统资源（内存（对象，redis连接）、磁盘（磁盘读写，mysql连接）、网络带宽.....）,针对每个请求（API，内存RPC）统计时间，超时就是释放资源

• 将服务分级：主流程核心服务，主流程非核心服务，分批次的熔断和降级

• 池的作用

  • 预加载资源，避免资源的频繁创建和销毁
  • （漏斗）有限流的作用，避免无限的使用计算机资源（将超出计算机处理能力的请求搁置或放弃）

• 熔断是在糟糕的情况下保证不再恶化的手段（微博榜单崩了，直接返回网络开小差）