最近大家经常被熔断洗脑，股市的动荡，让熔断再次出现在大家眼前。微服务中的熔断即服务提供方在一定时间内，因为访问压力太大或依赖异常等原因，而出现异常返回或慢响应，熔断即停止该服务的访问，防止发生雪崩效应。轻舟网关基于Envoy实现，在社区熔断思路上进行扩展。本文从Istio中熔断说起，拨云见日，漫谈轻舟网关熔断。
从熔断说起
最近大家经常被熔断洗脑，股市的动荡，有幸两周内见证了美股的四次熔断。那究竟什么是熔断呢，在股票界熔断实际上就是自动停盘，股市在跌到一定的程度后，暂停股票交易。对比股市，微服务中的熔断即服务提供方在一定时间内，因为访问压力太大或依赖异常等原因，而出现异常返回或响应变慢等。熔断即停止对该服务的调用，防止发生“雪崩效应”。从服务网关的角度看，熔断即是在网关侧阻止对服务提供方（upstream）的调用。本文从服务网关的角度窥探ISTIO中如何进行熔断，保护后端业务。
Istio熔断
Istio提供了丰富的熔断手段，通过异常点检测以及连接池配置起到保护后端的效果。异常点检测动态确定上游集群中的健康状态，如果出现连续访问异常，则将异常后端从负载均衡实例中驱逐，在一段时间内不向其中打流量。过一段时间，加入到负载均衡集群中，继续提供服务，若还是不正常，加大隔离时间。ISTIO提供了主动和被动健康检查，异常检测可以认为是被动的的健康检查，数据面Envoy提供了主动健康检查，在上游集群上配置健康检查接口，主动和被动一起使用，作为一个整体的健康检查方案，保障上游集群高可用。
异常点检测在控制面配置在DestionRule CRD中，对应到数据面Envoy中体现在Cluster上的配置。主要的配置项包括：
1、consecuitiveErrors:连续错误次数。对于HTTP服务，502、503、504会被认为异常，TPC服务，连接超时即异常 2、intervals：驱逐的时间间隔，默认是10秒 3、baseEjectionTime:最小驱逐时间。驱逐时间会随着错误次数增加而增加。即错误次数*最小驱逐时间 4、maxEjectionPercent:负载均衡池中可以被驱逐的实例的最大比例。以免某个接口瞬时不可用，导致太多实例被驱逐，进而导致服务整体全部不可用。
同时Istio还提供了连接池配置，通过针对四层TCP以及七层HTTP连接的配置，进行客户端访问的限流。具体的配置主要包括：TCP连接池配置以及HTTP连接池配置。配置项主要包括：
HTTP连接池配置和TCP连接设置配合使用。对应到数据面Envoy上根据业务属性进行划分，一部分划分为cluster.circuit_breakers，另一部分属于cluster的配置。
|
Istio配置 | Envoy配置 |
含义 |
备注 |
|---|---|---|---|
| maxConnection | cluster.circuit_breakers.max_connections | Envoy为上游集群建立的最大连接数 | |
| http1MaxPendingRequests | cluster.circuit_breakers.max_pending_requests | 最大等待HTTP请求数，默认1024 |
如果超过，cluster的upstream_rq_pending_overflow计数器增加 |
| http2MaxRequests | cluster.circuit_breaker.maxRequests | HTTP2最大连接数 | 仅适用HTTP2, HTTP1由maxConnection控制。如果超出，cluster的upstream_rq_pending_overflow计数器增加，可以由stat查看 |
| maxRetries | cluster.circuit_breaker.max_retries | 最大重试次数 | 在指定时间内，集群所有主机能够执行的最大重试次水。如果超出，cluster的upstream_rq_retry_overflow计数器增加 |
| connectionTimeOut | cluster.connection_timeout_ms | cluster.connection_timeout_ms | |
| maxRequestsPerConnection | cluster.max_request_per_connection | 每个连接最大请求数 |
Istio熔断与Hystrix熔断
Hystrix是微服务领域成熟的熔断框架，是Netflix开源的熔断框架。不过从18年底已经不在积极维护了。Hystrix对请求进行封装，相关的逻辑在独立的线程中运行，通过线程池达到资源隔离的效果。Hystrix提供了熔断能力，具备自动检测与恢复，断路开关在Open,Half-Open以及Closed状态间进行自动切换；同时提供了FallBack方法，便于用户在后端服务熔断情况下进行降级。
任何架构都有不同的使用场景，正如没有完美的架构只有合适的架构一样。灵活的配置以及可扩展性使得Hystrix融合在SpringCloud体系下，为SpringCloud微服务框架提供熔断功能。但是与之带来的是在使用Hystrix过程中，必须引入Hystrix依赖包。可以把Hystrix认为是一个白盒，开发人员可以针对业务进行相关的定制，包括降级方法的编写等。虽然，可以通过SDK模式从代码上解耦业务和相关熔断治理，但是业务和SDK还是需要一起编译。同时，Hystrix仅适用于java语言。
而Istio的熔断对业务完全是透明的，无需对业务有任何依赖；在sidecar模式下，做到和业务集群无缝连接。不过Istio的熔断更多是基于集群进行配置，熔断力度相较于某些业务场景还有一定的薄弱。
熔断示例
轻舟网关提供了丰富的熔断配置页面，通过轻舟网关的控制台，可以配置连接池配置。具体配置如下：TCP最大连接数配置为1，HTTP最大pending请求数配置为1。
通过控制台的配置，可以将具体的配置转换成Istio中VirtualService的trafficPolicy的配置。具体如下
串行请求5次服务接口，查看数据面envoy stat的状态，可以看到5次请求均返回200。
并发5次请求服务接口，客户端收到三个503，2个200状态返回，查看数据面envoy stat可以看到对应的2xx为2次，5xx为三次。5xx产生的原因为upstream_rq_pending_overflow。即因为max_pending数配置为1 ，请求被熔断。
轻舟网关熔断
轻舟网关基于Istio的熔断实现了服务级别的熔断限流。提供了服务维度的主动健康检查、被动健康检查以及连接池配置。同时，轻舟网关在服务的基础上，扩展了路由级别的熔断，结合hystrix的思路，使用滑动窗口来统计错误率和RT。实现了熔断插件，作用于路由和virtualhost级别。具体的流程如下：
轻舟网关同时提供了丰富的限流策略起到对后端业务的保护，基于rate-limit-server实现。提供基于百分比请求的流控，基于条件的频控，包括Header等维度的限流，具体的配置页面如下：这是一个最简单的配置，配置为请求Header中带有IP:127.0.0.1的请求，每分钟请求100次，超过100次触发限流，返回429。
轻舟网关目前提供了丰富的网关10几种插件，扩展envoy原生路由功能。包括缓存，cors，jsonp，限流，动态降级，静态降级，熔断，鉴权等插件。有兴趣的同学可以了解下轻舟网关。