服务容错

容错性设计不能妥协源于分布式系统的本质是不可靠的

容错：在错误发生时，系统依然可以提供正确的功能的能力，直接关系到可用性、可靠性

错误带来的一些问题

雪崩效应

基础服务的故障可能会导致级联故障， 进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程

请求堆积

在大量请求到来时，处理器有一个线程池来处理请求，当请求到达量远远大于处理量，请求就会在线程池中堆积，从而导致大量请求被阻塞

容错策略

面对故障，我们该做些什么（空间冗余（副本机制）、时间冗余（重试机制））

• 故障转移（Failover）：当对某些服务的调用失败 转而调用该服务的其他副本
  • 这种重试策略应该要有一定的阈值 过度的重试反而可能让系统处于更加不利的状况
• 快速失败（Failfast）：对于非幂等的服务调用失败 就应该直接使用失败而非重试来解决
• 安全失败（Failsafe）：对于不在链路主线的服务调用 如日志 扩展点等 这些服务的结果不参与最终运算 即使失败了 也可以当做正确来返回
• 沉默失败（Failsilent）：如果对于某个服务的调用大量超时失败 此时就很容易请求堆积而消耗资源 可以在一段时间内不再向它分配流量 类似于熔断
• 故障恢复（Failback）：指当服务调用出错了以后，将该次调用失败的信息存入一个消息队列中，然后由系统自动开始异步重试调用
  • 这种类型适合幂等调用的且没有返回值的链路主线服务调用
• 并行调用（Forking）：一开始就同时向多个服务副本发起调用，只要有其中任何一个返回成功，那调用便宣告成功
• 广播调用（Broadcast）：要求所有的请求全部都成功，这次调用才算是成功

容错设计模式

断路器模式

通过代理（断路器对象）来一对一地（一个远程服务对应一个断路器对象）地接管服务调用者的远程请求。断路器会持续监控并统计服务返回的成功、失败、超时、拒绝等各种结果，当出现故障（失败、超时、拒绝）的次数达到断路器的阈值时，它状态就自动变为“OPEN”，后续此断路器代理的远程访问都将直接返回调用失败，而不会发出真正的远程服务请求

现实中，当以下两个条件同时满足 断路器就会打开：

1. 一段时间内请求达到某个阈值
2. 一段时间内请求的故障率达到某个阈值

舱壁隔离模式

当有故障发生时，能将问题和影响隔离在某个模块内部，而不扩散风险，不波及其它模块，不影响整体的系统服务

无论是使用线程池或者信号量来隔离 本质上都是为了将故障隔离到最小的粒度 防止扩散

服务分组

对于拥有许多节点的服务提供者，可以进行打标签给不同的调用者使用，进行分组隔离，避免公用相同的提供者降低雪崩的风险，不过这一般在容器调度里才比较常用

基于动态分组的隔离，可以在某个分组流量激增时，快速借用留有富余的分组的节点从而度过流量高峰，相比动态扩缩容，见效更快

重试模式

重试时 应该同时满足以下几个条件：

• 仅对链路主线的关键服务进行同步重试
• 进队瞬时故障进行重试 像类似403 404这种错误重试没有意义
• 仅对幂等调用进行重试
• 重试要有终止条件
  • 重试次数
  • 超时终止

优雅上下线

下线

当进入关闭流程时，已经进来的请求可以慢慢处理完，对于新来的请求，直接提示本服务正在关闭拒绝掉，当所有请求处理完，则可以进行关闭

上线

1. 启动预热：对于刚启动的服务，给其的调用权重不要那么高，这样可以避免一启动就有大流量打进来
2. 延迟暴露：只有服务提供方完全追备好了，才向注册中心注册

Hystrix

当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN).

这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN)

统计器（Metrics）：滑动窗口（metrics.rollingStats.timeInMilliseconds）以及桶（metrics.rollingStats.numBuckets）

Hystrix 并不是只要有一条请求经过就去统计，而是将整个滑动窗口均分为 numBuckets 份，时间每经过一份就去统计一次。在经过一个时间窗口后，才会判断断路器状态要不要开启

在Hystrix中, 主要通过线程池来实现资源隔离. 添加 @HystrixCommand 这个注解之后，hystrix会开启服务隔离，访问这个接口的线程独属于某一个线程池。通常在使用的时候我们会根据调用的远程服务划分出多个线程池每个外部依赖用一个单独的线程池，这样的话，如果对那个外部依赖调用延迟很严重，最多就是耗尽那个依赖自己的线程池而已，不会影响其他的依赖调用

线程池机制的缺点：多了一些管理线程，增加了CPU的开销

一些概念：

1. command key 代表了一类 command，一般来说，代表了下游依赖服务的某个接口
2. command group 默认情况下，就是通过 command group 来定义一个线程池的，而且还会通过 command group 来聚合一些监控和报警信息，同一个 command group 中的请求，都会进入同一个线程池中

Sentinel

基本概念

• 资源：可以是 Java 应用程序中的任何内容
• 规则：包括流量控制规则、熔断降级规则以及系统保护规则

流量控制：Sentinel 作为一个调配器，可以根据需要把随机的请求调整成合适的形状

流量控制可以从以下角度切入：

• 资源的调用关系，例如资源的调用链路，资源和资源之间的关系
• 运行指标，例如 QPS、线程池、系统负载等
• 控制的效果，例如直接限流、冷启动、排队等

sentinel 通过使用以下方式熔断降级：

• 并发线程数 同计数器 当线程数达到一定数量 新的请求就会被拒绝
• 响应时间 当资源响应时间超过阈值 对该资源的访问会直接拒绝

基本原理

所有的资源都对应一个资源名称以及一个 Entry。Entry 可以通过对主流框架的适配自动创建，也可以通过注解的方式或调用 API 显式创建

通过一系列的Slot来实现相对应的功能

vs hystrix