我们对项目模块进行了一定程度的微服务化改造，之前所有模块都放在一个项目里（一个大文件夹），线上部署也一样，这样的缺点显而易见。 后面我们按照业务功能拆分成一个个的子模块，然后子模块之间通过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字段传给后端
对于要访问的一个服务模块，部署上一般是一个集群，我们需要配置机器集群的所有IP，当然，如果有内部DNS服务，也可以配上集群的域名。
对于一个RPC框架来说，基本的功能有负载均衡、健康检查、降级&限流等，我们的流量控制即针对降级&限流功能，在详细介绍它之前，先说说负载均衡与健康检查是如何实现的，这是流量控制实现的基础。
立即学习“PHP免费学习笔记（深入）”；
负载均衡我们实现了随机与轮询算法，随机算法通过在所有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有任何交互，没有性能损耗。
系统介绍：YIXUNCMS中专专版是易迅软件工作室在中秋节来临之即推出的专题模板建站系统，使用增强版后台管控系统，板板设计符合节日特点。易迅软件工作室恭祝全国人民中秋快乐。特别提示：由于网站页面的不同设计，部分后台功能未在前端进行体现。系统特点：1、采用目前流行的PHP语言编写，底层采用超轻量级框架作为系统支撑；2、页面布局使用DIV+CSS技术，遵循WEB标准，及大提高页面的浏览速度；3、使用应
我们的健康检查依赖于一个中心化的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以下，说明相关模块已是系统的瓶颈，下一步就应该增加硬件资源或者优化我们的程序性能了。
相关推荐：
