一，介绍
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 处理。例如：
_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，资源访问层
