分布式服务框架-原理与实践:6—服务路由-学习笔记

分布式服务框架上线运行时都是集群组网，这意味着集群中存在某个服务的多实例部署，消费者如何从服务列表中选择合适的服务提供者进行调用，这就涉及到服务路由。分布式服务框架要能够满足用户灵活的路由需求。

6.1 透明化路由

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

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

在分布式服务框架中，服务注册中心用于存储服务提供者地址信息，服务发布相关的属性信息，消费者通过主动查询和被动通知的方式获取服务提供者的地址信息，而不需要硬编码。

消费者只需要知道当前系统发布了哪些服务，而不需要知道服务具体存在于什么位置，这就是服务化路由。

它的工作原理就是基于服务注册中心的订阅发布机制。

服务注册中心的工作原理如图所示：略

服务消费者和服务提供者通过注册中心提供的SDK与注册中心建立链路，服务提供者将需要发布的服务地址信息和属性列表写入注册中心。

服务消费者根据本地引用的接口名等信息，从服务注册中心获取服务提供者列表，缓存到本地。

===

由于消费者可能先于服务提供者启动，或者系统运行过程中新增服务提供者，或者某个服务提供者宕机退出，就会导致注册中心发生服务提供者地址变更。

注册中心检测到服务提供者列表变更之后，将变更内容主动推送给服务消费者，消费者依据变更列表，动态刷新本地缓存的服务提供者地址。

6.1.2 消费者缓存服务提供者地址

消费者调用服务提供者时，不需要每次调用都去服务注册中心查询服务提供者地址列表，消费者客户端直接从本地缓存的服务提供者路由表中查询地址信息，根据路由策略进行服务选路。

当服务提供者发生变更时，注册中心主动将变更内容推送给消费者，由后者动态刷新本地缓存的服务路由表，保证服务路由信息的实时准确性。

采用客户端缓存服务提供者地址的方案不仅仅能提升服务调用性能，还能保证系统的可靠性。

当注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存的地址信息进行通信，只是影响新服务的注册和老服务的下线，不影响已经发布和运行的服务。

6.2 负载均衡

负载均衡策略是服务重要的属性，分布式服务框架通常会提供多种负载均衡策略，同时支持用户扩展负载均衡策略。

6.2.1 随机

采用随机算法进行负载均衡，通常在对等集群组网中，随机路由算法消息分发还是比较均匀的。

它的主要缺点有2个：

1)在1个截面上碰撞的概率较高

2）非对等集群组网，或者硬件配置差异较大，会导致各节点负载不均匀。

通常，实现上会采用JDK提供的java.util.Random或者等在指定服务提供者列表中生成随机地址，消费者基于随机生成的服务提供者地址进行远程调用。

6.2.2 轮询

轮询，按照权重设置轮询比率，到达边界之后，继续绕接。

主要缺点是存在慢的提供者累积请求问题，比如第2台机器很慢，没挂

当请求调到第2台时就卡在那，久而久之，所有请求都卡在第2台上。

实现非常简单，原理就是按照权重，顺序循环遍历服务提供者列表，到达上限后归0，继续循环。

6.2.3 服务调用时延

消费者缓存所有服务提供者的服务调用时延，周期性的计算服务调用平均时延，然后计算每个服务提供者调用时延与平均时延的差值，根据差值大小动态调整权重，保证服务时延大的服务提供者接收更少的消息，防止消息堆积。

该策略的特点就是要保证处理能力强的服务提供者接收到更多的消息，通过动态自动权重调整消除服务调用时延的震荡范围，使得所有服务提供者服务调用时延接近平均值，实现负载均衡。

效果：略

6.2.4 一致性哈希

相同参数的请求总是发到同1个服务提供者，当某1台提供者宕机时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

平台提供默认的虚拟节点数，可以通过配置参数进行修改。

一致性哈希环！

6.2.5 粘滞连接

略

6.3 本地路由优先策略

6.3.1 injvm模式

在一些业务场景中，本地JVM内部也发布了需要消费的服务。

该场景下，从性能，可靠性等角度考虑，需要优先调用本JVM内部的服务提供者，这种本地优先的路由模式成为injvm模式。

XXX

6.3.2 innative模式

XXX

6.4 路由规则

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

6.4.1 条件路由规则

场景如下：

1)黑白名单

2)流量引导

3)读写分离

4)前后台分离

5)灰度升级

6.4.2 脚本路由规则

支持动态编译，修改后实时生效。

在线上动态调整路由规则时非常有效。

常用的路由脚本有javascript,groovy,mvel等。

6.5 路由策略制定

下面聊策略的制定，什么时候需要自定义路由呢？

1)灰度升级：x

2)服务故障，业务高峰期的导流：通过自定义路由，将异常的峰值流量导流到几台或者1台服务器上，防止

整个集群负载过重导致整个生产系统雪崩。

3)与业务强相关的场景。

就是自定义路由策略

6.6 配置化路由

1)本地配置

2)统一注册管理：注册到统一服务注册中心，进行集中化配置管理

3)动态下发:修改-》推送

6.7 最佳实践-多机房路由

随着业务的不断发展，单个机房容量已经不足以支撑未来业务的发展，业务开始跨机房部署。

跨机房调用会带来时延增加、网络故障概率变大等问题，如何避免？

路由规则自定义！