通过API网关实现微服务管控-限流，熔断和降级( 三 ) _微服务

对于内部的类似Hystrix熔断配置主要是针对内部的API接口访问和调用，重点是包含微服务模块本身可靠性；而对于API网关本身限流主要是针对外部访问，一方面是对大并发访问进行第一次拦截，一方面是保证API网关本身的稳定性不超负荷。
但是实际你会看到，在这种混合架构下如下一个新问题，即没有一个地方对所有的流量进行汇集而实现总的限流控制。
那么在这种情况下，采用熔断则是最好的方式。
因为熔断本身不是基于并发量，而是基于服务响应时间，报文量等进行熔断控制。但是在混合架构下如何形成统一的规则计算？这个时候就需要两个限流熔断控制点都访问统一个日志中心和规则计算中心。具体参考下图：

文章插图

在这种模式下基本就可以实现一个整体的熔断管理。
服务降级

文章插图

在这里先谈下微服务架构里面谈到的服务降级，在微服务架构下的降级一般会谈两种形式的降级，一种是屏蔽降级，一种是熔断降级。
对于屏蔽降级，简单来说就是在微服务多节点集群部署的情况下，当发往某一个集群节点，比如C节点的服务访问调用出现大量异常错误的时候，我们需要对C节点进行屏蔽。
对于熔断降级，则实际和熔断类似了，即当对于微服务的大并发访问导致服务性能下降的时候，我们需要对服务进行熔断。这和前面谈到的熔断基本一致。但是这里的熔断往往更加灵活，比如可以将熔断器全部打开，半打开或全部关闭等。

文章插图

即在熔断后设置一个时间窗口恢复，在恢复的时候仅仅放入少量服务调用进行验证，如果服务已经恢复正常则将熔断器关闭，如果仍然访问失败则继续打开熔断器并顺延一个时间窗口。

而对于API网关来谈服务降级，即在API网关本身能力有限的情况下，如何确保高SLA的服务都能够得到需求满足，在出现大并发访问等场景的时候优先牺牲低SLA服务。
拿上面的场景来举例。
即不存在对于查询订单API接口并发量上来响应时间无法满足需求情况下对该接口降级的说法，这种情况只能叫对该接口限流。而实际场景说法应该是当查询订单API接口响应无法满足需求的时候，由于该接口是高SLA接口，因此需要对查询用户接口进行限流或熔断。以确保更多的资源能够分配给查询订单接口使用。
拿去银行办理业务的窗口来举例：

最初是4个普通窗口，一个VIP贵宾窗口。但是当天VIP用户来办理业务的人相对多，这个时候不能降低VIP用户的服务水平，因此需要将普通窗口减少到3个，而VIP窗口增加为2个。

我们可以再回顾下SLA服务等级协议，即：

SLA：Service-Level Agreement的缩写，意思是服务等级协议du 。zhiSLA是关于网络服务供dao应商和客户间的一专份合同，其书中定义了服务类型、服务质量和客户付款等术语。按照 SLA 要求，服务供应商采用多种技术和解决方案去监控和管理网络性能及流量，以满足 SLP 中的相关需求，并产生对应的客户结果报告。

那么对于微服务下的API接口服务，同样存在SLA等级要求。我们在进行微服务接口定义和设计的时候需要对里面的关键要求进行定义。比如：

服务响应时间要求：<2S
服务高可用性要求：99.99%

这些就是关键的KPI指标，可以基于这些指标来进行服务SLA等级的划分。
基于监控预警来进行手工降级
在整个服务运行中，一般还有服务运行监控预警功能，即设置相关的服务KPI指标或组合指标，当这些指标阈值满足的时候就发出监控预警信息。
比如服务响应环境，JVM内存使用率居高不下等都可以进行预警，在出现预警后运维人员可以基于当前服务运行的真实情况来判断具体是哪个服务或哪个消费方导致的服务运行性能问题，并对相应的服务进行熔断操作。
如果是高SLA服务本身性能出现问题而整个集群资源负荷大的情况下，那么就需要对非核心业务涉及到的微服务或微服务API进行手工关闭或限流熔断。
智能化的服务限流和熔断处理在这里从API网关进行接口服务集成和暴露的角度出发，是否需要对网关接入的每一个服务都进行相应的服务限流和熔断配置？