php数据访问层设计,网络资源访问层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 处理。例如：

_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。每次有连接失败的情况进队，失败计数加一，失败状态出队时，则连接失败次数减一。

从上图可以看出，队列(长度为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配置开启跨机房。

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

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

下游实例选取过程

十，参考文章