网关限流了，躲在后面的服务就能高枕无忧啦？

[导读] 今天想跟大家聊一个比较有意思的话题，就是：网关限流了，服务本身就能高枕无忧了吗？我想大部分公司的架构都是下面这样子的，网关在最前面，充当了守门员的工作。请求想要进来，必须经过网关，所以在网关层面做流控是最合适的，没有之一。如果我们认为，只要网关把入口的流量控制好了，下游...

今天想跟大家聊一个比较有意思的话题，就是：网关限流了，服务本身就能高枕无忧了吗？

我想大部分公司的架构都是下面这样子的，网关在最前面，充当了守门员的工作。请求想要进来，必须经过网关，所以在网关层面做流控是最合适的，没有之一。

如果我们认为，只要网关把入口的流量控制好了，下游的服务就不用瞎操心了，直接躺平即可。这种想法本身没错，可是经过大量的实践，往往故事的结局却不是你想象的那么美好。

首先，如果你作为某一个服务的负责人或者开发者，你的职责就是要保护这个服务不出问题。对你来说，外部任何信息任何系统你都不能信任。

大家都在对你说，网关已经限流了，上游服务也限流了，到你这都是安全的，不要考虑那么多。你信我，这些人只是过过嘴瘾，当你负责的服务出问题后，他们绝对不会承认之前说过的话。

在服务的划分中，一般有三种：

如果是纯对外的服务，网关限流了，这个服务本身没有必要限流了，因为没有其他的流量进来。

如果是纯内部服务，肯定是自己要做一层流控的，因为你在最底层，你的调用方很多。

如果是对内也对外的服务，也要自身做一层流控，因为对外的网关直接拦截了，但是你还有其他的接口在对内服务，如果这个对内的接口被一个外部调用量很大的接口在调用，那么你的请求量将急剧上升。

所以，你需要对你负责的服务类型有清醒的认知，是否会同时对内又对外。正所谓靠人人跑,靠墙墙倒! 只有靠自己才是最稳妥的。在服务内加一层限流做为救命的稻草，其他服务挂了不关你的事情，只要你负责的服务不挂就可以了。

这个时候你能想到前面给大家介绍的流控类型吗？集群或者单机模式，这两种模式结合起来用才是强有力的保护。网关层用集群限流，内部服务单机限流做为兜底，保证不被流量冲垮。