你好，我是何小锋。上一讲我们介绍了 RPC 中常用的保护手段“熔断限流”，熔断是调用方为了避免在调用过程中，服务提供方出现问题的时候，自身资源被耗尽的一种保护行为；而限流则是服务提供方为防止自己被突发流量打垮的一种保护行为。虽然这两种手段作用的对象不同，但出发点都是为了实现自我保护，所以一旦发生这种行为，业务都是有损的。

那说起突发流量，限流固然是一种手段，但其实面对复杂的业务以及高并发场景时，我们还有别的手段，可以最大限度地保障业务无损，那就是隔离流量。这也是我今天重点要和你分享的内容，接下来我们就一起看看分组在 RPC 中的应用。

为什么需要分组？

在我们的日常开发中，我们不都提倡让用户使用起来越简单越好吗？如果在接口上再加一个分组维度去管理，不就让事情变复杂了吗？

实则不然，举个例子。在没有汽车的年代，我们的道路很简单，就一条，行人、洋车都在上边走。那随着汽车的普及以及猛增，我们的道路越来越宽，慢慢地有了高速、辅路、人行道等等。很显然，交通网的建设与完善不仅提高了我们的出行效率，而且还更好地保障了我们行人的安全。

同样的道理，我们用在 RPC 治理上也是一样的。假设你是一个服务提供方应用的负责人，在早期业务量不大的情况下，应用之间的调用关系并不会复杂，请求量也不会很大，我们的应用有足够的能力扛住日常的所有流量。我们并不需要花太多的时间去治理调用请求过来的流量，我们通常会选择最简单的方法，就是把服务实例统一管理，把所有的请求都用一个共享的“大池子”来处理。这就类似于“简单道路时期”，服务调用方跟服务提供方之间的调用拓扑如下图所示：