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

文章插图

今天准备谈下基于API网关来实现微服务治理管控中的服务限流，熔断和降级方面的内容。在前面谈微服务架构的时候也谈到过类似通过Hystrix，Sentinel来是服务限流熔断。包括也不断地在谈去中心化架构和服务网格化。
但是通过API网关来实现微服务治理，短期仍然是一个必要选择。
其原因主要体现在以下几个方面：
其一是场景需求，即面对一个大集成项目，或多个开发商进行协同集成的场景，采用API网关是必须的。一个开发商内部可以去中心化，但是多个开发商间想要去中心化不容易。
其二是在微服务架构开发里面，单个微服务应该尽量简单，就是实现业务规则逻辑和暴露API接口服务能力。但是当前的微服务开发框架，在实现类似限流熔断等的时候，基本都需要对已经开发完成的微服务进行相关的配置修改或增加注解等。
其三对于ServiceMesh服务网格当前还没有大足够成熟和大面积应用的阶段，但是API网关本身已经足够成熟并得到大量项目实践验证。
基于API网关进行服务接入和管控

文章插图

对于API网关我前面已经写过很多文章说明，在这里不再重复描述。对于今天要说明的微服务治理管控我们假设如上图的场景，即：

有订单，用户和产品三个微服务暴露6个接口，其中3个属于内部使用走注册中心接入。另外三个接口注入接入到API网关，网关代理封装后暴露Http Rest接口提供外部小程序，App和CRM三个独立的应用访问。

在这个场景下三个微服务仅仅提供API接口注册，对于具体的API限流熔断都在API网关上面进行灵活的配置和管理，而这些配置和管控对微服务本身无任何侵入。
对于API网关本身也集群部署确保可靠性和性能，因此后续的限流熔断实际是基于整个集群入口总流量进行。其次，API网关的限流熔断，不仅仅是访问雪崩，包含后端的微服务模块，另外一个重要作用是保护API网关本身的性能和可靠性。
为了方便叙述，假设API网关接入并暴露了查询订单，查询用户，查询产品三个API接口服务。
对于限流熔断的基本实现思路可以先参考我前面文章：
微服务和API网关限流熔断实现关键逻辑思路
限流，熔断和降级区别

文章插图

先回顾下限流，熔断和降级具体的内容和区别。
对于限流简单来说就是入口流量控制，比如QPS超过了我们定义的某个基准值就禁止进入，当负荷下来后，又可以放入更多的请求。简单来说就是服务调用请求，超过了请求负荷就需要等待或被拒绝掉，但是等负荷下来你又可以调用通。
而熔断则是对整个API服务的处理，即整个API接口不再提供服务能力，直接拒绝访问。具体恢复可以手工恢复，也可以在我们设置的时间间隔后自动恢复。对于熔断一般则是根据并发量，错误数，响应时长等达到某个阈值，就直接触发熔断。
服务降级则是针对所有服务而不是单个服务的，即当出现巨大的访问量或并发量的时候，如何通过将非核心服务降级（限流或熔断）以释放资源，来保证核心服务SLA水平。
【通过API网关实现微服务管控-限流，熔断和降级】通过上面的解释总结如下：

限流时候本身不是服务完全不可用，而是对流量进行控制；而熔断则是完全服务不可用。服务降级不是针对单个服务，而是整个服务群，服务降级措施可以是限流，也可以是熔断。

服务限流在前面已经谈到，在去中心化的微服务架构下，限流功能的实现仅仅是为了包含微服务本身不超负荷运转。我们还是以开在商场里面的餐馆的例子来进行说明。
即一个餐馆最多只能容纳100桌就餐，当全部满员后新来的人就需要等待，只有等已经在就餐的客人就餐完毕空出资源后才能够进入。但是这个时候餐厅本身的客流本身来源于两个点，一个是逛商城的人随机过来的，一个是餐厅的少量会员VIP客户。但是餐厅本身没有包间，也就是说当普通客户过多的时候直接导致餐厅排队，VIP客户并不能得到应有的服务。
这个时候我们希望的做法是对普通客户流量进行控制，而不是由于大量普通服务需求的满足导致了VIP客户排队或服务无法得到满足。即餐馆不仅需要考虑自身负荷，还需要考虑对不同类型客户的服务质量。