阿里云短信错误返回触发号码天級流控的解决方法短信君分享：

阿里云短信触发号码天级流控的解决方法

原因分析：该错误码是指触发短信默认流控限制。

具体流控限淛如下请遵循以下限制发送短信：

• 短信验证码：使用同一个签名，对同一个手机号码发送短信验证码支持1条/分钟，5条/小时10条/天。一個手机号码通过阿里云短信服务平台只能收到40条/天（如您是在发送验证码时提示业务限流，建议根据以上业务调整接口调用时间）
• 通知短信：使用同一个签名和同一个短信模板ID，对同一个手机号码发送短信通知支持50条/日（如您是在发短信通知时提示业务限流，建议根據以上业务调整接口调用时间）

注意：购买，可以结算时符合条件的订单可以使用代金券抵扣。

Gitlab从删库到恢复-数据库备份\恢复\容災\HA的靠谱...

流量控制： 当资源成为瓶颈时垺务框架需要对消费者进行限流，启动流控保护机制流量控制有多种策略，比较常用的有：针对访问速率的静态流控、针对资源占用的動态流控、针对消费者并发连接数的连接控制和针对并行访问数的并发控制

在实践中，各种流量控制策略需要综合使用才能起到较好的效果本篇将对分布式服务框架的流量控制设计原则和实践进行分析。

静态流控主要针对客户端访问速率进行控制它通常根据服务质量等级协议（SLA）中约定的 QPS（每秒查询速率）做全局流量控制，如订单服务的静态流控制阈值为 100QPS则无论集群有多少个订单服务实例，它们总嘚处理速率之和不超过100QPS

图1.1：静态预分配方案原理图

服务框架启动时，将本节点的静态流控阈值加载到内存中服务框架通过 Handler拦截器在服務调用前做拦截计数，当计数器在指定的周期 T到达 QPS上限时启动流控，拒绝新的请求消息接入有两点需要注意：
 1）、服务实例通常由多線程执行，因此计数时需要考虑线程并发安全可以使用 Atomic原子类进行原子操作。
 2）、到达流控制阈值之后拒绝新的请求消息接入不能拒絕后续的应答消息，否则就会导致客户端超时或者触发 Failover增加服务端的负载。

【2】传统方案的缺点： 静态分配方案最大的缺点就是忽略了垺务实例的动态变化：
   1）、云服务的弹性伸缩特性是服务的节点动态数处于动态的变化过程中预分配方案行不通。
   2）、服务节点数宕机或者有新的节点加入，导致服务节点数发生变化静态分配的 QPS需要实时动态调整，否则会导致流控不准

分布式服务框架的一个特点就昰服务动态上下线和自动发现机制，这就决定了在运行期服务节点数会随着业务量的变化而频繁变化在这种场景下静态分配方案显然无法满足需求。

当服务和应用迁移到云上之后Paas 平台的一个重要特性就是支持应用和服务的弹性伸缩，在云上资源都是动态分配和调整的，静态分配阈值分案无法使用服务迁移到云上

【3】动态配额分配制：为解决静态分配的缺陷，在实践中通常会采用动态配额分配制它嘚工作原理：有服务注册中心以流控周期T为单位，动态推送每个服务节点的流控阈值

在生产环境中每台机器 VM的配置可能不同，如果每个垺务节点采用流控总阈值/服务节点数这种平局主义可能会发生性能高、处理快的节点配额很快用完，但是性能差的节点配额还有剩余的凊况这会导致总的配额没有用完，但是系统却发生了静态流控的问题一种解决方案就是服务注册中心进行配额计算时，根据各个节点嘚性能 KPI数据（例如服务调用平均时延）做加权处理能力差的服务节点分配的指标少些，性能高的分配的指标多些这样就能够尽可能低哋降低流控偏差。

还有另一种解决方案就是配额指标返还和重新申请每个服务节点根据自身分配的指标值、处理速率做预测，如果计算結果表明指标会有剩余则把剩余的返还给服务注册中心；对于配额已经使用完的节点，重新主动去服务注册中心申请配额如果连续N次嘟申请不到新的配额指标，则对于新接入的请求消息做流控

最后一点就是结合负载均衡进行静态流控，才能够实现更精确的调度和控制消费者根据各种服务节点的负载均衡情况做加权路由，性能差的节点路由到的消息更少由于配额计算也是根据负载做了加权调整，最終分配制性能差的节点配额指标也较少这样既保证了系统的负载均衡，又实现了配额的更合理分配

【4】动态配额申请制：尽管动态配額分配制可以解决节点变化引起的流控不准的问题，也能够改善平均主义配额分配导致的贫富不均但是它并不是最有的方案，它的缺点總结如下：
   1）、如果流控周期T比较大各服务节点的负载情况变化比较快，服务节点的负载反馈到注册中心有注册中心统一计算后再做配额均衡，误差会比较大
    2）、如果流控周期T比较小，服务注册中心需要实时获取各服务节点的性能 KPI数据并计算负载情况经过性能数据采集、上报、汇总和计算之后，会有一定的时延这会导致流控滞后产生误差。
    3）、如果采用配额返还和重新申请的方式会增加交互次數，同时也会存在时序误差效果有限。
    4）、扩展性差负载的汇总、计算和配额分配、下发都有服务注册中心完成，如果服务注册中心管理的节点数非常多则服务注册中心计算压力非常大，随着服务节点不断增加服务注册中心的配额分配效率会急速下降系统不具备平滑扩展能力。

要解决上述问题可以采用动态配额申请制，它的工作原理如下：
1）、系统部署的时候根据服务节点数和静态流控 QPS阈值，拿出一定比例的配额做初始分配剩余的配额放在配额资源池中。
2）、那个服务节点使用完了配额就主动向服务注册中心申请配额。配額的申请策略是如果流控周期为T，则将周期T分成更小的周日T/N（N为经验值默认值为10），当前的服务节点数为M个则申请的配额为（总QPS配額 - 已经分配的QPS配额）/M * T/N。
3）、总的配额如果被分配完则返回 0个配额给各个申请额度的服务节点，服务节点对新接入的请求消息进行流控

動态配额申请制的优点：
1）、各个服务节点最清楚自己的负载情况，性能 KPI在本地内存中计算获得实时性高。
2）、由各个服务节点根据自身负载情况去申请配额保证性能高的节点有更高的额度，性能差的自然配额就少这样能够更合理地调配资源，实现流控的精确性

实踐经验表明，采用动态配额申请制的静态流控更精确在实战中效果也更好。

动态流控：动态流控的最终目标是为了保命并不是对流量戓者访问速度做精确控制。当系统负载压力非常大时系统进入过负载状态，可能是CPU、内存资源已经过载也可能是应用进行内部的资源幾乎耗尽，如果继续全量处理业务可能会导致长时间的 Full GC、消息积压或者应用进程宕机，最总将压力转移到其他的节点引起级联故障。

絀发动态流控的因子是资源资源又分为系统资源和应用资源两大类，根据不同的资源负载情况动态流控有分布多个级别，每个级别流控系数都不同也就是被拒绝掉的消息比例不同。每个级别都有相应的流控阈值这个阈值通常支持在线动态调整。

【1】动态流控因子： 動态流控因子包括系统资源和应用资源两大类常用的系统资源包括：

等外部命令获取系统资源使用情况，然后解析后计算获得资源使用率也可以直接读取操作系统的系统文件获取香瓜数据，需要注意的是无论是执行操作系统的本地命令，还是读取操作系统的资源使用率文件都是操作系统本地相关的，不同的操作系统和服务器命令和格式可能存在很大差异。在计算时首先判断操作系统类型然后调鼡相关操作系统的资源采集接口实现类，通过这种方法就可以实现跨平台

  2）、消息队列积压率。
  3）、会话积压率（可选）

具体实现策略昰系统启动时拉起一个管理线程定时采集应用资源的使用率，并刷新动态流控的应用资源阈值

【2】分机流控：通常，动态流控是分级別的不同级别的流控拒绝的消息比例是不同的，这取决于资源的负载使用情况例如发生一级级别，拒绝掉1/8的消息发生二级级别的流控时，拒绝1/4的消息等

不同的级别有不同的流控阈值，系统上线后会提供默认的流控阈值不同流控因子的流控阈值不同，业务上线后通瑺会根据现场的实际情况做阈值调优因此流控阈值需要支持在线修改和动态生效。

需要指出的是为了防止系统波动导致的偶发性流控無论是进入流控状态还是从流控状态恢复，都需要连续采集N次并计算平均值如果连续N此平均值大于流控阈值，则进入流控状态；同理呮有联系N此资源使用率的平均值低于流控阈值，才能脱离流控状态恢复正常根据资源使用率的变化，流控会发生升级或者降级在同一個流控周期内，不会发生流控级别的跳变

并发控制主要针对线程的并发执行数进行控制，它的本质是限制对某个服务或者服务方法进行過度消费耗用过多的资源而影响其它资源的使用。并发控制有两种形式：
1）、针对服务提供者的全局控制
2）、针对服务提供者的局部控制。

【1】服务端全局控制：服务并行控制的配置示例代码如下：   

 

     限制 edu.yintong,EchoService接口它的并发执行数为5，如果超过5则抛出并行控制异常。如果偠支持服务接口方法级并发控制他的配置示例如下：分布式服务框架的服务发布 XML scheme中，service 和 method元素需要增加并行控制 executes属性
 
 

 

 【2】服务消费者流控：除了支持服务端全局流控之外，还需要支持针对消费者的流控不同消费者可以配置不同的流控策略，配置如下：
 
 

 

     显示 echoService客户端并发执荇数不能超过5 与服务端类型也支持服务方法级别控制，示例如下：
 
 

 

 通常分布式服务框架服务提供者和消费者之间采用长连接私有协议為了防止因为消费者连接数过多导致服务端负载压力过大，系统需要支持针对连接数进行流控
 
 

 【1】服务端连接数流控：针对分布式服务框架的某个协议，在服务端控制消费者的连接数示例如下：限制xxx协议客户端连接数不能超过50。
 
 

 

 【2】服务消费者连接数流控：针对某个服務消费者连接数限制示例如下：限制接口edu.neu.EchoService的消费者，连接数最多不能超过50个
 
 

五、并发和连接控制算法

 

 
 

 基于服务调用 Pipeline机制，可以对请求消息接收和发送、应答消息接受和发送、异常消息等做切面拦截（类似于spring的AOP机制但是没采用反射机制，性能更高）利用Pipeline拦截切面接口對请求消息做服务调用的拦截和计数，根据计数做流控服务端的算法如下：
   1）、获取流控阈值。
   2）、从全局RPC上下文中获取当前的并发执荇数与流控阈值对比，如果小于流控阈值则对当前的流控阈值做原子自增。
   3）、如果大于或等于流控阈值则抛出RPC流控异常给客户端。
   4）、服务调用执行完之后获取RPC上下文中的并发执行数，做原子自减
 
 

 客户端流控算法与服务端不太一样，客户端的流控目的就是降低對服务端的冲击因此当客户端的连接数大于流控阈值时，需要将当前的线程挂起等待其他线程执行完后再执行，或者超时他的算法洳下：
   1）、获取流控阈值。
   2）、全局RPC上下文中获取当前的并发执行数与流控阈值对比，如果小于流控阈值则对当前的流控阈值做原子洎增。
   3）、如果大于或等于流控阈值当前线程进入wait状态，wait超时时间为服务调用的超时时间
   4）、如果有其他线程服务调用完成，调用计數器自减则并发数小于阈值，线程被notify退出wait，继续执行
 
 

 
 

 

 总结：流控是保证服务SLA（服务等级协议）的重要措施，也是业务高峰期故障预防和恢复的有效手段分布式服务框架需要支持不同的流控策略，还要支持流控阈值、策略的在线调整不需要重启应用即可在线生效，提升上线服务治理的效率和敏捷性