微服务体系下，限流和熔断分别在哪里发挥作用？

限流大多在广义的“服务端”。熔断大多在广义的“客户端”。

限流简单举例就是令牌桶，过量的请求过来就直接拒绝。
如果是对 app 、浏览器要访问的接口限流，一般就做在网关层（对浏览器来说，网关就是服务端）。
服务间调用的时候，被调用的服务（服务端）也可以做限流；或者被网关调用的服务，自己也可以做限流（对网关来说，被调用服务是服务端）。

熔断一般是在客户端视角的，检查服务端正不正常，在有多个服务端可选的情况下，只调功能正常的、不去调有异常的服务端。对 app 、浏览器来说，服务端就一个域名，大概率也就一个 ip ，一般不做熔断（熔断了就把整个服务端干掉了）。
微服务一般有多副本，直接访问微服务的“客户端”可以做熔断。
比如网关对后端服务来说是客户端，网关可以做熔断。
后端服务间调用，调用方是客户端，调用方也可以做熔断。

具体要不要配熔断，要不要限流。看业务实际情况，感觉没一个特别固定的方法论。

限流是入口做，熔断是出口做。每个服务都有入口和出口，每个系统也有入口和出口。一般来说，网关是需要有限流的，每个服务自己最好也做限流。每个服务调用其他的服务可以做熔断，为了保护对方/自己

@MelodYi 想问下 Hystrix 在单个服务多个实例的情境下，如何做限流和熔断呢？是不是不适用于此类场景？

@mangojiji 你是说你的微服务，整个大项目，只有一个服务？
那是个啥微服务，不就是个 spring web 么（当然你也确实可以说，这是一个微服务）。

你还是参考这个服务端、客户端的概念就好。如果你的微服务从来不调用外部，那就只是服务端的身份，不会有作为客户端的身份。那这个服务本身只需要考虑限流问题就行了。

如果你还有网关，网关后面仅一个服务。那这个服务上我觉得限流意义也不大。
过量的流量让网关先抗住更合理些。