网络资源访问层ral设计

一,介绍

resource access layer,简称ral。我们暂且将lar层的一个网络实例称为raler。
下面的讲解以bd ral为例。ral是以php拓展的形式提供的一个客户端,来实现对后端服务的网络请求。用户在ral.conf配置相应的下游地址(支持ip:port,也支持dns这种域名)后,即可使用ral一站式接口与下游服务进行网络交互。

二,功能列表

作为资源访问层,ral层设计包含如下几方面的功能:

1,支持多种交互协议和数据打包格式

ral将网络交互过程分成了:

  • 打包
  • 网络传输交互
  • 解包
    三个过程。并且支持常用的后端交互协议(http,nshead等)。目前支持http,nshead,fcgi三种交互协议;支持string、mcpack1,mcpack2,json,form五种数据打包协议。打包,解包,网络交互对用户透明,在配置文件中正确配置即可。

2,支持资源定位,统一配置,降低运维成本。

支持通过zookeeper和bns方式获取服务配置,在zookeeper or bns服务端更新节点配置信息后,触发客户端回调并更新服务列表配置。此外ral也支持local方式来资源定位,在zookeeper or bns宕机后也可以访问下游。

3,支持本机配置健康检查和负载均衡策略。

支持多种均衡策略:

  • random
  • random robin,即轮询
  • 一致hash

4,支持服务变更后自动加载

ral支持服务配置自动加载。修改配置文件或者资源定位数据发生变更时,ral客户端会首选校验配置合法性,通过后会动态加载新的配置文件,并更新本地备份。

总的来说,ral高度封装了交互过程,集成了负载均衡,超时重试,资源定位,配置自动加载等功能,让调用方不再需要关心繁琐的通用逻辑。

三,配置示例

local配置示例:

# 新增服务,请先找到 [..Local] 父节点,在这个父节点底下添加 Local 的服务的配置
[..Local]
[...@Service]
# 服务名
Name : demoService
DefaultPort : 8080
DefaultRetry : 2
# 连接类型,目前仅支持 SHORT,即短连接
DefaultConnectType : SHORT
# 连接超时,单位ms,默认值 200
DefaultConnectTimeOut : 200
# 读超时,单位ms,默认值 500
DefaultReadTimeOut : 500
# 写超时,单位ms,默认值 500
DefaultWriteTimeOut : 500
[....@Server]
IP : 10.10.10.10
# 此处的 Tag 表示这台后端 Server 属于 jx 机房,在负载均衡的时候会优先考虑访问本机房的后端
Tag: jx
[....@Server]
IP : 10.10.10.11
# 此处如果不配置 Tag,该后端 Server 对全部机房有效
# Tag: yf
# 此处如果配了 Port, 可覆盖上面的 DefaultPort
# Port :8080
[....@Server]
# 除了 IP,还可以配 Hostname,RAL 会帮你做域名解析
Hostname: cq01-ksarch-rdtest00.vm
# 如果同时配了 IP 和 Hostname,以 IP 为准
# 访问内网服务建议使用 IP 方式
IP : 10.10.10.12
[....Protocol]
# 交互协议名称 支持 http / nshead / pshead / fcgi
Name : http
[....Converter]
# 打包协议名称 支持 form / mcpack1 / mcpack2 / json / string 
Name : mcpack2
[....SuperStrategy]
# 直接使用配置套餐
# 可选套餐: RANDOM_PACK / CONSISTENCY_PACK / ROUNDROBIN_PACK
Package : RANDOM_PACK
# 若不使用套餐,可参考以下详细配置
# 超级负载均衡均衡策略 Random / Consistency / RoundRobin
# Random 随机选择一个可用的后端
# Consistency一致性hash 根据传入的第四个参数(bk),加server ipport进行计算后hash
# RoundRobin 轮询各个后端
#Balance : Random
#【以下如果配置不完整表示关闭对应的健康状态】
#连接失败率的状态队列,表示记录过去多少次连接状态,不可reload
#ConnectQueueSize : 100
# 控制连接失败率
#ConnectX1 : 10
#ConnectY1 : 95
#ConnectX2 : 40
#ConnectY2 : 5
#读取健康状态,表示记录过去多少秒的读取状态,不可reload
#HealthyQueueSize : 100
# client端读的超时时间,单位ms
#HealthyTimeout : 100
#计算选择概率的时间间隔,以s为单位
#HealthyCheckTime : 3
#选择概率的最小值,0.1表示最小概率为10%
#HealthyMinRate : 0.1
#速度大于这个倍数才能做流量切分,用于不对称节点的负载平衡
#HealthyBackupThreshold : 3
# 是否允许跨机房连接
#CrossRoom : Off
#是否打开全混联, 相当于该服务全部机器接受任意机房tag请求
#Hybrid : Off

webfoot配置示例:

[...@Service]
Name: group.icc-qta.iknow.cn
Rename: Qta
Timeout: 1500

四,不同数据打包格式的操作

  • string 格式,指不做任何打包、解包操作,直接将 payload(ral() 的第三个参数,即“有效负载数据”) 发到后端;
  • json格式,需要传一个php array作为payloa
    ,ral做json_encode得到json string。
  • form 格式,指 www-form-urlencoded,需要传一个 php array 作为 payload,若 payload 有嵌套的 array,内层 array 进行 json_encode 处理。例如:payload = array( 'user' => 'tom', 'love' => array( 'first' => 'lily', 'second' => 'anna' ) ); 如果是 "post" 方式发送的,后端收到的_POST 请求是
    array( 'user' => 'tom', 'love' => '{"first":"lily","second":"anna"}` );
  • mcpack 格式,需要遵守 mcpack 打包格式规范。

idc匹配和idc mapping

支持按优先级选择不同机房的实例。多机房部署的时候可能会用到。具体见文末参考。

五,负载均衡

对每一次负载均衡处理,均衡过程首先会对一个服务多个实例的优先级进行排序,一次请求的均衡过程如下:

ral目前支持随机,轮询和一致性hash三种均衡策略。首先要清楚,负载均衡要解决的问题:

  • 如何合理利用后端资源,避免浪费
  • 提高服务吞吐量,降低平响
  • 特定应用的负载均衡,比如有cache的应用,如何提高cache命中率
  • 有部分实例挂掉时,如何对外保障服务稳定性
  • 前端请求压力过大时,如何对后端进行过载保护。

目前ral的负载均衡支持的功能:

  • 确定机器选择的优先级
  • 根据连接健康状态选择
  • 根据读取健康状态选择
  • 根据机器的处理能力选择
    下面分别详细介绍本文的重点:随机,轮询和一致性hash三种均衡策略。

1,随机均衡

随机(Random)是最传统的均衡方式,每个服务实例得分通过随机的方式获取。
这种方式服务请求会比较均匀的分配到不同的实例上,以保证后端机器资源使用比较均匀,避免某台机器压力过大而导致服务不稳定。这种方式也是最常使用的一种均衡策略。

2,轮询均衡

轮询也是一种比较传统的均衡方式。这种均衡方式,可以确保对后端服务实例的访问在任何时刻都是非常均匀的。 考虑到还有健康检查等处理流程,轮询策略并不会直接确定本次请求的实例,只保本次轮询到的实例具有最高优先级。在计算优先级得分时,是按照以下方式进行:
均衡时确保每次轮询到的server实例得分最高,其它机器则退化为随机取模的方式计算均衡得分:
本期轮询到server实例得分:N + 1
其它实例得分:rand() % N
最后根据得分对均衡的优先级进行排序,以保证轮询到的机器具有最高优先级,其他实例优先级随机排序。

3,一致性hash均衡

一致性hash(consistency)的均衡策略常用于存在cache的服务,对于这类服务均衡时需考虑其cache命中率,特定的请求应尽可能的映射到同一台机器。
使用Hash的方式做均衡时,要考虑两点:

  • hash均匀性
    选取合适的hash函数,尽量保证均匀映射。
  • hash单调性
    hash单调性是指,如果某个raler实例下线,只会影响这个raler前后两个实例,而不至于所有的hash都要重排。这样可以最大限度保证cache命中率。

六,根据连接健康状态进行选择

在经过均衡策略处理后,每个下游服务的实例按照优先级从高到低排。然后在这一步,根据健康状态对实例进行淘汰。

对每个实例的连接状态都需要进行记录,以判断该机器的健康状态,实现时会为每个服务实例都维护一个连接状态的队列,记录最近一段时间的连接情况。当然这个队列的长度是可以进行配置的,也就是ral配置文件中的ConnectQueueSize。每次有连接失败的情况进队,失败计数加一,失败状态出队时,则连接失败次数减一。


X轴表示连接失败次数,Y轴表示连接健康状态(100%为正常)

从上图可以看出,队列(长度为ConnectQueueSize)中失败次数与健康状态的关系,在连续多次失败时,一旦队列中的失败次数超过P点的X坐标,健康状态便会降到最低。这里K点及P点的坐标在RAL中都有其对应的配置:
ConnectX1 : 10 (K点X坐标)
ConnectY1 : 95 (K点Y坐标)
ConnectX2 : 40 (P点X坐标)
ConnectY2 : 5 (P点Y坐标)

最后根据连接健康状态进行选择,健康得分就是该实例的选择概率,健康得分越低淘汰的概率也就越大。
另外,需要注意的是,RAL中要使这个队列生效,需要运行在php-cgi的情况下,因为对于CLI方式,每次执行PHP连接健康状态的队列每次都会被重新初始化,从而无法保留状态信息。

七,根据读取健康状态选择

在根据连接健康状态进行选择后,连接异常的实例已经历过一次淘汰了。
负载均衡并未就此结束,对于一个稳定运行的服务实例,其时处理时间也应当收敛。 基于这点考虑,负载均衡还进一步支持根据服务访问的健康状态进行选择淘汰。 这里需要注意的是, 读取健康状态的判断是建立在服务处理时间收敛的基础上。对于稳定运行时处理时间不收敛的服务,该过程并不适合。
为了记录每个实例处理时间的历史状态,负载均衡会为每个实例都维护一个读取时间的队列,该队列保留过去一段时间内的状态,这里保留多久也是支持配置的,配置项为:HealthyQueueSize。 那么已经知道了最近一段时间内服务读取的时间,该如何进一步计算读取的健康状态呢,这里的思路如下:

每隔一段时间(M秒)计算该时间段内读取的平均时间,即上述的recent_avg(M)。将该平均时间与队列中总的平均处理时间进行比较,如果M秒内出现波动且耗时增加,健康状态便会有所降低,而耗时减少健康状态则会提高。但如果服务确实耗时增加且整体处理时间又稳定下来,那么经过一段时间,健康状态又会收敛到正常水平。

上式的间隔时间M和健康超时时间timeout(read)都可在配置文件中指定,对应的配置项分别是:HealthyCheckTime和HealthyTimeout。如果无HealthyTimeout配置则不启用读取健康状态选择。 得到健康得分f(healthy)后,选择或淘汰将按如下方式进行(其中R是选择概率的最小值,对应配置项是HealthyMinRate):

八,根据机器处理能力进行选择

在经过了前面两步健康选择和淘汰的过程后,负载均衡会进一步考虑根据机器的处理能力对请求进行分流,即流量切分。 当后端某个实例的性能过低时,应该考虑将流量切分给性能更好机器。至于性能差距在多大时考虑流量切分,可以通过配置HealthyBackupThreshold来指定流量切分阈值。 那么首先面临的问题是:该如何定义某个机器实例的性能呢?
可以通过该实例的平均处理时间来判断,即1/avgtime。 在获取机器实例性能的基础上,就可以对其进行流量切分,尽可能的将请求分配到性能更好的实例去处理,切分思路如下:

  • 首先:高于平均水平的机器并不需要进行流量切分。
  • 其次:对性能低于平均水平的实例,需要考虑对其进行流量切分,性能越低的后端实例被切流量的概率也就越大,切流量时会以配置的切分阈值为标准来查找更优的实例,当然如果找不到符合要求的后端实例就不作切分。最终切流量机器选择时,仍然会按照均衡策略给定优先级顺序考虑。

其实个人觉得这一步跟上一步的根据读取健康状态的工作,是重复的。

即使有一些服务实例处理时间较长或网络延迟较大,通过负载均衡的切流量就可以避免请求延迟较大的服务实例,使服务整体对外的性能较优。

九,最终选择

在负载均衡经历了以上三个选择过程后,常规的负载均衡过程就以完成,这时已经能够确定本次交互优先选择的服务实例。
不过除了以上功能,负载均衡还支持进行跨机房访问。 考虑到有时服务会分机房部署,为降低网络延迟及带宽成本会优先请求当前机房的机器。当单边机房不稳定或宕机的情况下,为了避免拒绝服务,可以配置尝试跨机房。服务可通过CrossRoom配置开启跨机房。

在后端实例配置了机房且启用跨机房,那么当前机房的实例在经过以上三种状态选择被淘汰时,便可尝试跨机房去请求其他机房的实例。 如果不启用跨机房,便会在经历过以上选择淘汰的结果中,选择最高优先级且未因健康状态被淘汰的那个实例。

整个下游服务实例选择过程如下:

下游实例选取过程

十,参考文章

1,资源访问层

推荐阅读更多精彩内容