原因:
- 服务提供者不可用
- 重试加大流量
- 服务调用者不可用
- 服务提供者不可用原因
- 1.1 服务雪崩的每个阶段都可能由不同的原因造成, 比如造成 服务不可用 的原因有:
- 1.2 硬件故障: 硬件故障可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问.
- 1.3 程序Bug
- 1.4 缓存击穿: 缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用.
- 1.5 用户大量请求: 在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用.
- 重试加大流量
- 2.1 用户重试：在服务提供者不可用后, 用户由于忍受不了界面上长时间的等待,而不断刷新页面甚至提交表单.
- 2.2 代码逻辑重试：服务调用端的会存在大量服务异常后的重试逻辑.
- 服务调用者不可用
- 3.1 同步调用： 当服务调用者使用 同步调用 时, 会产生大量的等待线程占用系统资源. 一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了.
应对策略
- 熔断：通过 超时机制使得不可用服务的调用快速失败
- 限流：网关限流、用户交互限流、关闭重试、接口限流。在JAVA中实现接口限流可以用guava的RateLimiter，它实现了令牌桶算法和漏桶算法。
- 降级：调用服务线程池隔离、依赖服务分类(终止弱依赖服务)
- 服务自动扩容
服务降级方式：
- 服务接口拒绝服务：无用户特定信息，页面能访问，但是添加删除提示服务器繁忙。页面内容也可在Varnish或CDN内获取。
- 页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到varnish或nginx的一个静态页面。
- 延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
- 随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。
服务降级埋点的地方：
- 消息中间件：所有API调用可以使用消息中间件进行控制
- 前端页面：指定网址不可访问（NGINX+LUA）
- 底层数据驱动：拒绝所有增删改动作，只允许查询