RPC：业务分组，隔离流量

为什么需要分组

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

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

同样的道理，我们用在RPC治理上也是一样的。在刚开始业务量不大的情况下，应用之间的关系并不会太复杂，请求量也不会很大，我们的应用有足够的能力扛住日常的所有流量，并不需要花费太多的时间去治理调用请求过来的流量，因此通常会选择最简单的方法，就是把服务实例同一管理，把所有的请求调用一个共享的“大池子”来处理

但是随着业务的发展，集群流量激增，这时我们就可以尝试把应用提供方这个大池子划分出不同规格的小池子，再分配给不同的调用方，而不同小池子之间的隔离带，就是我们在RPC里面所说的分组，它可以实现流量隔离

怎么实现分组

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

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

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

• 没有统一的标准
• 但是建议按照应用重要级别划分：非核心应用不要跟核心应用分在同一个组，核心应用之间应该做好隔离，一个重要的原则就是保障核心应用不受影响。

通过分组的方式隔离调用方的流量，从而避免因为一个调用方出现流量激增而影响其他调用方的可用率。对于服务提供方来说，这种方式是我们日常治理服务过程中一个高频使用的手段，那通过这种分组进行流量隔离，对调用方应用会不会有所影响呢？

如何实现高可用

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

那没有没有更高可用一点的方案呢？回到我们前面说的那个马路例子上，正常情况下我们必须让车在车道行驶，人在人行道上行走。但是当车道或者人行道出现抢修的时候，在条件允许的情况下，我们一般都是允许对方借道一段时间，直到道路完全恢复。

我们同样可以把这个特性用到我们的 RPC 中，要怎么实现呢？

• 前面提到，调用方应用服务发现的时候，除了带上对应的接口名，还需要带上一个特定分组名，所以对于调用方来说，它是拿不到其他分组的服务节点的，那这样的话调用方就没法建立起连接发请求了
• 因此问题的核心就变成了调用方要拿到其他分组的服务节点，但是又不能拿到所有的服务节点，否则分组就没有意义了。一个最简单的方法就是，允许调用方可以配置多个分组。但这样的话，这些节点对调用方来说就都是一样的了，调用方可以随意选择获取到的所有节发送请求，这样就又实现了分组隔离的意义，并且还没有实现“借道”的效果
• 所以我们还需要把配置的分组区分下主次分组，只有在主分组上的节点都不可用的情况下才去选择次分组节点；只要主分组里面的节点恢复正常，我们就必须把流量都切换到主节点上，整个切换过程对于应用层来说完全透明，从而在一定程度上保证调用方应用的高可用