负载均衡（一）基于接口、方法、参数的路由

基本场景：

在实际的应用场景中，一般会以接口作为服务的粒度。也就是说，一个服务就是指一个接口的远程实现，当然某个接口的具体实现要根据具体的业务和系统来决定。在一个集群中会提供多个服务（接口），每个服务又有多个方法，因此除了基础的服务器集群层面的负载均衡策略外，在某些特定的场景下我们还有更细粒度的服务路由控制需求。

问题引出：

如上图所示，我们看到有两组调用者集群（调用者1和调用者2）都依赖于服务器提供者提供远程服务，这个服务提供者有两个服务---接口A和接口B，每个服务有分别提供了两个方法。我们看一下实际中可能发生的如下场景：

~高并发，多线程的情况？

（1）多请求的应对：在实际实现中，服务提供者在执行服务请求者请求时，内部的线程模型是一个线程对应一个请求，而线程总数是有限制的（一般采用线程池来管理所有线程的工作线程）。当系统运行时，请求并发量大的情况下，所有工作线程都在工作，新的请求会进入等待队列。

~假如某个服务的提供者中的某个方法是一个很耗时的方法会出现什么情况呢？

（2）细粒度控制的应对：假设接口A中的方法1是一个很耗时的方法（即方法m1执行时间远大于接口A中的其他方法），而调用者对于两个接口中的所有方法的调用频率相差不多。那就可能出现所有的线程都在等待接口A的方法1的处理。这样所有的线程都被接口A的方法1所占用。

    1.基于接口进行路由：控制同一个集群中不同服务的路由并进行请求隔离是一种可行的解决方案。

如上图所示，我们采用的方案是通过客户端的路由把所有对于服务A的请求都送到上方的集群，把调用服务B的请求都送到下方集群。而这两个集群的代码其实完全一样，是客户端的路由导致了分流。具体实现，一般采用的方法是把路由规则进行集中管理，在具体调用端的服务框架上获取规则后进行路由的处理，具体来说是根据服务定位提供服务的那个集群的地址，然后与接口路由规则中的地址一起取交集，德奥的地址列表在进行接下来的负责均衡算法，最终得到一个可用的地址去调用。

    ~到此我们会发现，基于接口的路由只是保证了接口B中的方法不受接口A的影响。但是A中的其他方法仍收到A.m1方法的影响。

    2.基于方法进行路由：该方式的原理与基于接口路由的原理是一样的，只是把路由的规则做的更加细致一点。即在通过接口定位        到服务地址列表后，根据接口加方法名从规则中得到一个服务地址列表，再和刚才的地址列表取交集。

    3.基于参数进行路由：沿着上述思路，还可以基于参数进行路由。应用场景一般是需要对一些特定参数进行特殊处理的情况。