分布式服务框架学习笔记4 服务路由

透明化路由

很多开源的RPC 框架调用者需要配置服务提供者的地址信息，尽管可以通过读取数据库的服务地址列表等方式避免硬编码地址信息，但是消费者依然要感知服务提供者的地址信息，这违反了透明化路由原则。

基于服务注册中心的订阅发布

在分布式服务框架中，服务注册中心用于存储服务提供者地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的方式获取服务提供者的地址信息，而不需要像之前那样在代码中硬编码服务提供者地址信息。消费得只需要知道当前系统发布了哪些服务，而不需要知道服务具体存在于什么位置，这就是透明化路由。它的工作原理就是基于服务注册中心（例如ZooKeeper）的订阅发布机制。

消费者需要缓存服务提供者地址。

负载均衡

负载均衡策略：
1. 随机
2. 轮循
3. 服务调用时延
4. 一致性哈希
相同参数的请求总是发到同一个服务提供者，当某一台提供者宕机时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。平台提供默认的虚拟节点数，可以通过配置参数进行修改。
5. 粘滞连接
用于连接用于有状态服务，尽可能让客户端总是向同一提供者发起服务调用，除非该提供者宕机，再连接另一台。由于服务通常被强烈建议设计成无状态的，因此，粘滞连接在实际项目中很少使用。

本地路由优先策略

injvm 模式

在一些业务场景中，本地JVM内部也发布了需要消费的服务。该场景下，从性能、可靠性等角度考虑，需要优先调用本JVM内部的服务提供者，这种本地优先的路由模式被称为injvm模式。
injvm协议是一个伪协议，它不开启端口，也不发起远程服务调用，优先调用JVM内的服务提供者，相比于其它路由策略，它的执行流程相同，只不过将远程服务调用替换成了内部调用。

innative 模式

如果物理机或者VM 配置比较好，多个应用进程往往会选择合设。服务消费者和服务提供者可能会被部署到同一台机器上（VM）。服务路由时优先选择机本的服务提供者，如果找不到再重新发起远程服务调用，该模式被称为innative模式。

路由规则

负载均衡、本地路由优先等路由策略通常中以满足大部分业务的线上需求，但是在一些场景中需要对路由策略设置一些过滤条件，比较常用的是基于表达式的条件路由和脚本路由。

条件路由规则

1. 通过IP条件表达式进行黑白名单访问控制，
2. 流量引导，只暴露部分服务提供者，防止整个集群服务都被冲垮，导致其他服务也不可用
3. 读写分离：method=find*,list*,get*,query*=>providerIP=192.168.1.*
4. 前后台分离：app=web*=>providerIP=192.168.1.,app=java=>provierIP=192.168.2.*
5. 灰度升级，将Web前台应用路由到新的服务版本上：app=web*=>providerIP=192.168.1.*

脚本路由规则

脚本路由规则的特别是通常都支持动态编译，修改后可以实时生效，不需要重启系统，这在线上动态调整路由规则时非常有效。

路由策略定制

主要应用场景如下：
- 灰度升级
- 服务故障、业务高峰期的导流
- 与业务领域相关的非通用路由定制需求
路由扩展策略如下：

• 平台提供路由接口供用户实现
• 平台提供路由配置XML Schema定义，支持用户扩展路由规则
• 业务发布自定义路由策略，对于通过Spring Bean方式的服务发布，用户定义扩展路由bean，然后在服务提供者配置路由规则的时候，引用相关扩展的bean即可；如果是通过JDK的SPI方式扩展，则需要在jar包的META-INF/services目录下的路由策略文件中新增扩展的路由实现类和策略名。

配置化路由

路由配置策略设计如下：
1. 本地配置
2. 统一注册管理
3. 动态下发

最佳实践——多机房路由

多机房路由，不同机房会共用一个服务注册中心集群（异地容灾机房除外）。
仅仅依靠随机、轮询等负载均衡策略，消息将会被路由到两个机房，达不到不跨机房调用的目标。利用条件路由规则，可以非常便捷地解决问题。

在原有的负载均衡策略基础上，配置条件路由策略，由于不同机房的网段通常不同，可以根据网段条件匹配来实现地址过滤。具体配置策略如下：
app=web*,consumerIP=192.168.1.=>providerIP=192.168.1.。对于机房A中所有的Web前台应用，只访问本机房内部的服务提供者，不跨机房调用。
还有一种策略，就是虚拟分组，将整个集群系统的服务提供者（跨机房）逻辑分成若干个组，某个消费者只访问一个虚拟分组的服务提供者，防止跨组服务调用。如果是多机房部署，虚拟分组可以对应1个机房；如果是单个机房，则虚拟分组可以对应1个机房。通过拆分和分组，防止某个消费者看到集群中所有的服务提供者，既可以减少竞争提升性能，也可以增强故障隔离能力。
需要指出的是，当某个机房发生大面积宕机或者服务提供者无法正常工作时，需要跨机房访问其它健康的服务提供者，防止某个机房故障导致业务中断。