面试官:说说你们公司如何做服务路由的?

众所周知，负载均衡是为了解决 【服务的Consumer】 如何从众多可用服务节点中选取一个最合适的节点，对其发起调用。

场景导入

但现实中经常还会遇到这样场景：比如服务X部署在了三个IDC，所有服务节点也就被分成三组，那么【服务X的Consumer】发起调用时，应该如何选择呢？

这就是服务路由要解决的问题。

什么是服务路由？

服务消费者在发起服务调用时，必须根据特定规则选择服务节点，从而满足某些特定需求。

适用场景

分组调用

为保证高可用的服务，实现异地多活，一个服务往往不止部署在一个IDC，可能不仅在私有机房，还会在公有云甚至多家公有云部署。服务节点也因IDC不同，分成不同组，这时对于【服务消费者】，选择调用哪个分组，就需有相应路由规则。

灰度发布

在服务上线发布的过程，一般需先在一小部分服务节点上先预发布服务，验证业务功能是否符合预期：

• • 
    
• 符合
  就继续扩大发布范围
• 不符
  就要排查问题，解决后重新发布。
  • 
    

流量切换

在业务线上运行过程中，经常会遇到一些不可抗因素导致业务故障，比如光缆被挖，运营商网络被攻击，导致整个机房的服务都不可用。

这时就需按照某个指令，能够把原来调用这个机房服务的流量切换到其他正常的机房。

读写分离

互联网绝大部分业务读多写少，因此在部署服务时，可以把读写分开部署。

服务路由规则

条件路由

基于条件表达式的路由规则：

condition://0.0.0.0/dubbo.test.interfaces.TestService?
  category=routers&dynamic=true&priority=2&enabled=true&rule=
  " + URL.encode(" host = 10.20.153.10=> host = 10.20.153.11")

​​​​condition://​​  ​说明​这是一段用条件表达式编写的路由规则，具体规则：

host = 10.20.153.10 => host = 10.20.153.11

​​​=>​​​前：【​服务消费者​】​的匹配条件​

​​​=>​​​后：【​服务提供者​】​的过滤条件​：当【​服务消费者​】节点满足匹配条件，就对该​服务消费者​执行后面的过滤规则。

所以该段表达式即：

IP为“10.20.153.10”的【服务消费者】都调用IP为“10.20.153.11”的【服务提供者】

若 ​服务消费者的匹配条件 ​为空，表示匹配所有服务消费者：

=> host ！= 10.20.153.11

若 ​服务提供者的过滤条件 ​为空，表示禁止服务消费者访问：

host = 10.20.153.10=>

具体应用场景

排除某服务节点

=> host != 172.22.3.91

所有的服务消费者都不会访问IP为172.22.3.91的服务节点。

一般应用在线上流量排除预发布机以及摘除某个故障节点。

白名单

host != 10.20.153.10,10.20.153.11 =>

除了IP为10.20.153.10和10.20.153.11的【服务消费者】可发起服务调用，其他【服务消费者】都不可以。

比如某后台服务只允许特定机器访问。

黑名单

host = 10.20.153.10,10.20.153.11 =>

除了IP为​​10.20.153.10​​​和​​10.20.153.11​​的服务消费者​不能发起服务调用​，其他服务消费者都可以。

比如线上经常会遇到某些调用方的不寻常调用，影响了服务的稳定性，即可通过黑名单屏蔽之。

机房隔离

host = 172.22.3.* => host = 172.22.3.*

IP网段为​​172.22.3.*​​的服务消费者，才可以访问同网段的服务节点。一般应用于服务部署在多个IDC，理论上同一个IDC内的调用性能要比跨IDC调用性能要好，应用这个规则是为了实现同IDC就近访问。

读写分离

method = find*,list*,get*,is* => host =172.22.3.94,172.22.3.95
method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98

find*、get*、is*等读方法调用IP为172.22.3.94和172.22.3.95的节点，除此以外的写方法调用IP为172.22.3.97和172.22.3.98的节点。大部分业务读请求远大于写请求，而写请求的重要性往往要远远高于读请求，所以需要把读写请求进行分离，以避免读请求异常影响到写请求。

脚本路由

基于脚本语言的路由规则，常用的脚本语言比如JavaScript、Groovy、JRuby等。比如：

"script://0.0.0.0/com.foo.BarService?
  category=routers&dynamic=false&rule=" + 
  URL.encode("（function route(invokers) { ... } (invokers)）")

​​script://​​ 代表了这是一段脚本语言编写的路由规则，具体规则定义在脚本语言的route方法实现。比如下面这段用JavaScript编写的route()方法：只有IP为10.20.153.10的服务消费者可以发起服务调用。

function route(invokers){
  var result = new java.util.ArrayList(invokers.size());
  for(i =0; i < invokers.size(); i ++){
    if("10.20.153.10".equals(invokers.get(i).getUrl().getHost())){ 
       result.add(invokers.get(i));
    } 
  }
  return result; 
 } (invokers)）;

服务消费者该如何

获取路由规则

本地配置

路由规则存储在服务消费者本地上。服务消费者发起调用时，从本地固定位置读取路由规则，然后按照路由规则选取一个服务节点发起调用。

不排除某些服务消费者有特定的需求，需要定制自己的路由规则，这个时候就适合通过​本地配置​来定制。

配置中心管理

所有的服务消费者都从配置中心获取路由规则，由配置中心来统一管理。

服务路由最好是存储在配置中心中，由配置中心来统一管理。这样所有服务消费者就不需要在本地管理服务路由，因为大部分的服务消费者并不关心服务路由的问题，或者说也不需要去了解其中的细节。通过​配置中心​，统一给各个服务消费者下发统一的服务路由，节省了沟通和管理成本。

动态下发

一般是运维人员或者开发人员，通过服务治理平台修改路由规则，服务治理平台调用配置中心接口，把修改后的路由规则持久化到配置中心。因为服务消费者订阅了路由规则的变更，于是就会从配置中心获取最新的路由规则，按照最新的路由规则来执行。

动态下发可以理解为一种高级功能，它能够动态地修改路由规则，在某些业务场景下十分有用。比如某个数据中心存在问题，需要把调用这个数据中心的服务消费者都切换到其他数据中心，这时就可以通过动态下发的方式，向配置中心下发一条路由规则，将所有调用这个数据中心的请求都迁移到别的地方。

当然，这三种方式也可以一起使用，这个时候服务消费者的判断优先级是本地配置>动态下发>配置中心管理。

总结

服务路由简单说就是为了实现某些调用的特殊需求，比如分组调用、灰度发布、流量切换、读写分离等。在业务规模比较小的时候，可能所有的服务节点都部署在一起，也就不需要服务路由。但随着业务规模的扩大、服务节点增多，尤其是涉及多数据中心部署的情况，把服务节点按照数据中心进行分组，或者按照业务的核心程度进行分组，对提高服务的可用性是十分有用的。以微博业务为例，有的服务不仅进行了核心服务和非核心服务分组，还针对私有云和公有云所处的不同数据中心也进行了分组，这样的话就可以将服务之间的调用尽量都限定在同一个数据中心内部，最大限度避免跨数据中心的网络延迟、抖动等影响。

而服务路由具体是在本地配置，还是在配置中心统一管理，也是视具体业务需求而定的。如果没有定制化的需求，建议把路由规则都放到配置中心中统一存储管理。而动态下发路由规则对于服务治理十分有帮助，当数据中心出现故障的时候，可以实现动态切换流量，还可以摘除一些有故障的服务节点。

​

目前交流群已有​ 800+​人，旨在促进技术交流，可关注公众号

​