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

对应到微服务里面同样，即订单查询服务时间上有APP，小程序和CRM三个服务消费方。不能由于某一个消费方的大量调用而导致其它消费方服务请求也受影响。
即在这个场景下，实际上服务限流本身是两个层级的限流。

其一是对服务入口总流量进行限流，确保微服务本身在负荷之内；其二是对单个服务进行限流，以确保微服务本身有空余能力满足其它服务。

在实际当前开源的微服务限流熔断实现上，基本很难控制到单个应用请求方，而对应API网关在进行限流熔断实现的时候，我们则可以完全做到这点。
具体的并发量设置多少？
对应服务限流设置，我们以一秒内的QPS请求数阈值进行配置。那么针对一个微服务API接口，究竟应该配置多大的QPS值？对于这个问题仍然是事前和事后两种处理方式。
对于事前方式即我们在微服务上线前就要准备和模拟真正的业务场景，进行API接口的性能测试，看下API本身的性能和QPS数据。
我们可以不断地加大并发观察两个关键指标，一个是系统本身的资源负荷情况，一个是服务本身的响应时长情况。比如加大到500并发的时候，资源负荷已经超过80%，那么这个时候500并发就是极限值。但是你可能加大到300个并发的时候服务响应时长已经指数级增长而无法满足业务需求，那么这个时候你就只能取300并发下实际的QPS数据。
在配置的时候我们对QPS数据再预留点冗余即是我们可以配置的限流值。
当然也可以是后期处理方式，比如前期我们对限流没有任何配置，但是上线后会发现业务并发达到某个值的时候服务响应缓慢或者资源负荷很大导致内存泄漏等。那么这个时候，我们就需要基于实际服务运行采集到的值进行配置。
对于限流的思考
对于限流前面已经描述过，实际有两种情况，一个就是请求直接排队等待，连接保持；一种是请求访问直接被拒绝掉，但是过一会访问又可以访问了。
如果真要启用限流，建议采用第一种情况。任何一个接口服务对于消费方来说，如果出现一会可用，一会不可用，需要消费方自己不断地去重试都是不可接受的。虽然保证了微服务提供端的可靠性，但是对于服务提供本身的友好性则大打折扣。
即使是排队等待，我们也需要考虑连接超时配置，你要确保在连接超时前，排队等待的请求都能够被正常地处理掉。
举个高速入口收费站的例子说明。