RPC如何实现流量隔离机制？

应对突发流量，限流是好手段，但还有其它手段，可最大限度保障业务无损。

1 为何分组

若在接口上再加一个分组维度去管理，不就让接口复杂了？

实则不然，比如无汽车年代，道路很简单，就一条，行人、洋车都在上边走。那随着汽车普及，道路越来越宽，有高速、辅路、人行道。交通网的建设与完善不仅提高出行效率，还更好保障行人安全。

RPC治理也一样。假设你是一个服务提供方应用的负责人，早期业务量不大，应用之间的调用关系简单，请求量不大，应用有足够能力扛日常所有流量。无需花太多时间治理调用请求过来的流量，通常选择最简单的方法，把服务实例统一管理，把所有请求都用一个共享“大池子”处理。类似“简单道路时期”，服务调用方跟服务提供方之间的调用拓扑，无隔离调用拓扑：

后期你接口的调用方越来越多，流量也多了。突然其中一个调用方流量激增，让你整个集群瞬间高负载，影响到其它调用方，导致它们的整体可用率下降，就得想法保证应用稳定。

2 问题本质是啥？

早期为管理方便，把接口都放到同一分组下，所有服务实例是以一个整体对外提供能力。

但业务膨胀，这种粗暴管理模式不再适用，就好比“有了汽车，交通网也得抓紧建设”，让人车分流。

道路上的人和车类比我们应用的调用方，我们可尝试把应用提供方这个大池子，划分出不同规格小池子，再分配给不同调用方，而不同小池子之间的隔离带，就是RPC里的分组，可实现流量隔离。

3 分组实现方案

RPC里咋实现分组？

既然是要求不同调用方拿到池子内容不同，回想服务发现，因为RPC流程里，能影响调用方获取服务节点的逻辑就在于它。

服务调用方通过接口名去注册中心找到所有的服务节点，完成服务发现。那换到这里的话，这样做其实并不合适，因为这样调用方会拿到所有的服务节点。因此为了实现分组隔离逻辑，我们需要重新改造下服务发现的逻辑，调用方去获取服务节点的时候除了要带着接口名，还需要另外加一个分组参数，相应的服务提供方在注册的时候也要带上分组参数。

通过改造后的分组逻辑，我们可以把服务提供方所有的实例分成若干组，每一个分组可以提供给单个或者多个不同的调用方来调用。那怎么分组好呢，有没有统一的标准？

这分组没有标准，我自己总结个规则参考，按应用重要级别划分。

非核心应用，不要跟核心应用分在同组，核心应用间应隔离，重要原则：核心应用不能受影响。如提供给下单过程中用的商品信息接口，要独立出一个单独分组，避免受其它调用方污染！

有了分组，服务调用方跟服务提供方之间的调用拓扑变成，分组调用拓扑：

通过分组，隔离调用方的流量，避免因为一个调用方出现流量激增而影响其它调用方的可用率。对服务提供方，这种方式是日常治理服务过程中的常用手段，这种分组流量隔离，对调用方应用有啥影响呢？

4 如何实现高可用？

分组隔离后，单个调用方在发RPC请求时，可选择的服务节点数相比没有分组前减少了，那对单个调用方，出错概率就升高了。如一个集中交换机设备坏了，而这调用方的所有服务节点都在这交换机下面，对服务调用方，它的请求怎么也到达不了服务提供方了，导致调用方业务受损。

有没有高可用方案？正常必须让车在车道行驶，人在人行道上。但当人行道或车道出现抢修，条件允许情况下，一般允许对方借道行驶一段时间，直到道路完全恢复。

RPC里咋实现“借道”？
调用方应用服务发现时，要带上：

对应接口名
特定分组名
所以对调用方来说，它是拿不到其它分组的服务节点的，那这样的话，调用方就无法建立连接。

因此问题核心变成：caller要拿到其它分组的服务节点，但又不能拿到所有的服务节点，否则分组就无意义了。最简单方案：允许caller配置多个分组。但若如此，这些节点对caller就都一样了，caller可随意选择获取到的所有节点去发请求，就又失去分组隔离意义，且还没实现“借道”效果。

所以还要把配置的分组，区分主次分组，只有主分组上的节点都不可用，才选择次分组节点。只要主分组里的节点恢复正常，须把流量都切换到主节点，整个切换过程对应用层透明，从而一定程度保障caller应用的高可用。

5 总结

RPC里可通过分组，人为给不同caller划分出不同小集群，实现caller的流量隔离，保障核心业务不受非核心业务干扰。考虑问题不能顾此失彼，不能因新加功能而影响原系统稳定性。

不仅可通过分组把Provider划分成不同规模小集群，还可利用分组，完成一个接口多种实现。

一般为方便管理服务，推荐每个接口的功能尽量唯一。但特殊场景下，两个接口也会完全一样，只是具体实现稍不同，就可以在Provider应用里同时暴露两个相同接口，但只是接口分组不一样而已。