PHP 基于redis实现的流量控制系统
我们对项目模块进行了一定程度的微服务化改造，之前所有模块都放在一个项目里（一个大文件夹），线上部署也一样，这样的缺点显而易见。 后面我们按照业务功能拆分成一个个的子模块，然后子模块之间通过RPC框架进行访问，各个子模块有各自独立的线上机器集群、mysql及redis等存储资源，这样一个子模块出问题不会影响到其它模块，同时可维护性，扩展性更强。
但现实中每个子模块的服务能力是不同的， 如下图按子模块拆分之后的架构图所示，假设到达A模块的QPS为100，A依赖于B，同时每一个A模块到达B模块的请求QPS也为100， 但B模块所能提供的最大QPS能力为50， 如果不进行流量限制，则B模块因为超过负载而流量堆积导致整个系统不可用，我们的动态流量控制系统就是找到子模块的最佳服务能力，即限制A模块到达B模块的流量为50QPS，则至少保证一部分请求是能够正常进行的，而不会因为一个子服务挂掉而拖跨整个系统。
我们的RPC框架是一个PHP实现的框架，主要支持http协议的访问。对于一个前端A模块来说，对于依赖于的后端B模块， 需先对B模块进行服务化配置，再按服务名字进行引用访问，服务配置一般形式如下：
[MODULE-B] ; 服务名字
protocol = "http" ;交互协议
lb_alg = "random" ; 负载均衡算法
conn_timeout_ms = 1000 ; 连接超时,所有协议使用, 单位为ms
read_timeout_ms = 3000 ; 读超时
write_timeout_ms = 3000 ; 写超时
exe_timeout_ms = 3000 ; 执行超时
host.default[] = "127.0.0.1" ; ip或域名
host.default[] = "127.0.0.2" ; ip或域名
host.default[] = "127.0.0.3" ; ip或域名
port = 80 ; 端口
domain = ‘api.abc.com‘ ; 域名配置，不作真正解析，作为header host字段传给后端
[MODULE-B] ; 服务名字
protocol = "http" ;交互协议
lb_alg = "random" ; 负载均衡算法
conn_timeout_ms = 1000 ; 连接超时,所有协议使用, 单位为ms
read_timeout_ms = 3000 ; 读超时
write_timeout_ms = 3000 ; 写超时
exe_timeout_ms = 3000 ; 执行超时
host.default[] = "127.0.0.1" ; ip或域名
host.default[] = "127.0.0.2" ; ip或域名
host.default[] = "127.0.0.3" ; ip或域名
port = 80 ; 端口
domain = ‘api.abc.com‘ ; 域名配置，不作真正解析，作为header host字段传给后端
对于要访问的一个服务模块，部署上一般是一个集群，我们需要配置机器集群的所有IP，当然，如果有内部DNS服务，也可以配上集群的域名。
对于一个RPC框架来说，基本的功能有负载均衡、健康检查、降级&限流等，我们的流量控制即针对降级&限流功能，在详细介绍它之前，先说说负载均衡与健康检查是如何实现的，是这流量控制实现的基础。
负载均衡我们实现了随机与轮询算法，随机算法通过在所有IP中随机选一个即可，比较容易实现，对于轮询算法，我们是基于单机轮询，将上一个选择的IP序号利用apcu扩展记录在本地内存中，以方便找到下一个要使用的IP序号。
被访问的机器可能会失败，我们将失败的请求IP记录在redis中，同时分析记录的失败日志来决定是否需要将一个机器IP摘除，即认为这个IP的机器已经挂掉，不能正常提供服务了，这就是健康检查的功能，我们通过相关服务配置项来介绍下健康检查的具体功能：
ip_fail_sample_ratio = 1 ; 采样比例
失败IP记录采样比例，我们将失败的请求记录在redis中，为防止太多的redis请求，我们可以配一个失败采样比例
ip_fail_cnt_threshold = 10; IP失败次数
ip_fail_delay_time_s = 2 ; 时间区间
ip_fail_client_cnt = 3 ； 失败的客户端数
不可能一个IP失败一次就将其从健康IP列表中去掉，只有在有效的ip_fail_delay_time_s 时间范围内，请求失败了 ip_fail_cnt_threshold 次，并且失败的客户端达到ip_fail_client_cnt 个， 才认为其是不健康的IP。
为什么要添加 ip_fail_client_cnt 这样一个配置，因为如果只是某一台机器访问后端某个服务IP失败，那不一定是服务IP的问题，也可能是访问客户端的问题，只有当大多数客户端都有失败记录时才认为是后端服务IP的问题
我们将失败日志记录在redis的list表中，并带上时间戳，就比较容易统计时间区间内的失败次数。
ip_retry_delay_time_s = 30 ； 检查失败IP是否恢复间隔时间
某个失败的IP有可能在一定时间内恢复，我们间隔 ip_retry_delay_time_s 长的时间去检查，如果请求成功，则从失败的IP列表中去除
ip_retry_fail_cnt = 10； 失败IP如果检查失败，记录的失败权重值
ip_log_ttl_s = 60000； 日志有效期时间
一般来说只有最近的失败日志才有意义，对于历史的日志我们将其自动删除。
ip_log_max_cnt = 10000； 记录的最大日志量
我们用redis记录失败日志，容量有限，我们要设定一个记录的最大日志数量，多余的日志自动删除。
在我们的代码实现中，除了正常的服务IP配置，我们还维护了一个失败IP列表，这样通过算法选IP时先要去掉失败IP，失败IP记录在一个文件中，同时利用apcu内存缓存加速访问，这样我们所有的操作基本是基于内存访问的，不会有性能问题。
我们只有在请求失败时才会将日志记录在redis中，那在什么时候将失败的IP找出来呢，这涉及到查询redis list列表中所有的失败日志，同时统计失败个数，是一个较复杂的操作。我们的实现是多个PHP进程抢占锁的方式，谁抢到了就执行分析操作，记录失败的IP到文件中。因为只有一个进程会执行分析操作，所以对正常请求不会有什么影响。 同时只有在失败时才会有抢占锁的动作，正常情况下基本不会与redis有任何交互，没有性能损耗。
我们的健康检查依赖于一个中心化的redis服务，如果它挂了怎么办？如果判断redis服务本身挂掉了，rpc框架会自动关闭健康检查服务， 不再与redis交互，这样至少不会影响正常的RPC功能。
在健康检查实现的基础上我们可以实现流量控制，即当我们发现大部分或全部IP失败时，我们可以推断是因为流量过大导致后端服务响应不过来而请求失败，这时我们就应该以一定策略限流，一般的实现是直接将流量全部摘除，这有点粗暴，我们的实现是逐步减少流量，直至失败的IP比例降到一定数值，后面又尝试逐步增加流量，增加与减少可能是一个循环的过程，即是动态的流量控制，最终我们会找到一个最佳的流量值。通过相关配置来介绍一下流量控制的功能：
degrade_ip_fail_ratio = 1 ; 服务开始降级时失败IP比例
即失败的IP比例达到多少时开始降级，即开始减少流量
degrade_dec_step = 0.1 ; 每次限流增加多少
即每次减少多少比例的流量
degrade_stop_ip_ratio = 0.5;
在失败的IP已降到多少比例时开始停止减少流量，并尝试增加流量
degrade_stop_ttl_s = 10;
停止等待多长时间开始尝试增加流量
degrade_step_ttl_s = 10
流量增加或减少需要等待的时间。
每一次流量增加或减少后，下一步如何做是根据当时失败的IP比例来决定的，而且会保持当前流量值一段时间，而不是立即做决定。
degrade_add_step = 0.1
每次增加流量增加的比例值
degrade_return = false ; 降级时返回值
降级时我们不会再去访问后端服务，而是直接给调用方返回一个配置的值。
流量控制的状态图描述如下：
如何实现控制流量在一定比例呢？ 通过随机选择，比如获得一个随机数并判断是否落在某个范围内。 通过限制流量在一个最佳值，在影响最少的用户情况下让大部分请求能正常工作，同时流量控制配合监控报警，发现某个模块的流量控制比例在1以下，说明相关模块已是系统的瓶颈，下一步就应该增加硬件资源或者优化我们的程序性能了。
原文地址：https://www.cnblogs.com/maibaodexiaoer/p/8569808.html