「技术干货」Pontus-用友云限流服务

在我们讨论系统稳定性的时候,其实核心的关键词就是容量规划,如何做好业务容量与系统性能的评估,是保障系统稳定性的关键。对于系统性能的评估,需要我们具备自动化工具来对系统进行性能压测,探测系统在实际业务场景下的基线数据,这是我们进行系统资源配置的基础,也是在应对流量增长时进行弹性扩容的依据。
在我们做好容量规划的前提下,在实际业务场景下,我们还是不可避免的会面对不确定的系统压力,在面对突发不确定流量的情况下,我们最担心的就是系统的“雪崩”。就像突然爆发的车流让道路交通瘫痪一样,我们的系统在突发流量下,很可能像多米诺骨牌一样,全链路的崩塌。
很多情况下,我们以为我们的系统能够这样:

但实际上确实这样

在系统发生雪崩的情况下,我们连基本容量规划的负载都保证不了。如何保障我们的系统能够在复杂多变的业务场景下,能够持续稳定的提供的负载处理能力。这就要求我们按照系统的容量规划,做好系统的限流保护,让超出负载的流量能够快速的failover,将系统无法承载的流量拒之门外,保护我们的系统不会发生雪崩。
如何做限流
在一般的概念中,我们在讨论限流的时候,首先会想到并发的限流,通过限制系统服务调用的并发数来对系统进行保护。这里面其实包含两层概念:线程数和QPS。
线程数是我们系统中实际活跃的处理线程的数目,而QPS是我们系统在一定时间度量范围内的访问速率。一般传统的限流手段是通过对活跃线程数进行控制来进行系统流量的控制。在现今复杂的互联网服务调用体系下,更常用的是QPS进行限制来达到我们系统保护的效果。
考虑我们现今大部分的互联网架构,一般业务系统会由几十甚至上百的微服务构成,一次业务请求的处理,涉及众多的微服务调用。从线程数的角度看,很难去对整体系统的流量做一个衡量。在我们对复杂的业务系统进行性能评估的时候,会使用全链路压测的工具来进行,衡量的目标也是基于系统的QPS.所以使用对QPS进行限制的手段,会更好的对业务系统进行一个负载保护。
在笔者多年稳定性的负责工作中,一般在系统的各个入口处使用QPS作为主要的限流保护手段,线程数限流更多是作为上游系统对下游系统的一种熔断机制来使用,保护上游系统在下游RT变长的情况下,不会被拖垮。
限流的实现
线程数限流
对于线程数的限流,一般通过令牌许可的方式实现,通过预置令牌的数目来控制系统的活跃线程数量,没有获取令牌的线程,快速的失败返回。

在线程的入口处获取许可令牌,在执行业务逻辑完毕的出口处归还令牌。在实现上一般使用try{……}finally{……}结构实现,在finally中进行令牌的释放。
线程数的限流多数用于简单系统的负载保护,及自我的熔断保护优雅降级,防止依赖的下游服务RT变长的情况下,造成自身系统性能下降。在例如天猫交易系统这种,依赖下游服务(库存、物流、商品、营销等)较多的系统中,一个服务的变慢可能会对处于核心的交易系统造成不良的影响,所以对于在交易系统中,对于依赖的核心服务都是设置一个自我保护的线程数限流值,在下游服务出问题的情况下进行优雅降级。
QPS限流
和线程数不同,QPS限流是对按照一定时间单位内的并发速率来对系统进行限制。QPS与线程数限流相比,最大的好处除了能够按照压测模型的测算进行设置外,在笔者看来,另一个最大的好处就是可以对流量进行削峰,防止流量突刺对系统资源进行穿透影响。
QPS虽然度量单位上是秒,但是一般的实现不会基于秒级进行计数统计来进行限流保护,基于秒级的计数时间窗口过大,不能够消除流量突刺。试想一下在一秒的时间窗口内,流量突发集中在后面10ms,那么在最后的时刻,系统流量会变成我们期望值的100倍,可想而知这个时候对于系统来说是多么可怕的灾难。

所以在实现上,一般基于时间窗口的分片来进行计数,将整个QPS的计数周期划分为多个时间窗口,将计数值分散在各个时间窗口进行控制和计算,这样能够避免上面提到的流量突刺的出现,能够有效的将流量进行削峰,将流量洪峰削平,放着洪峰对于系统资源的破坏,例如缓存的热点穿透。
在软件的世界里很奇妙,我们会发现很多东西没有银弹,软件的进化过程,就是跟着实际的场景不断的调优。基于时间窗口的QPS限流,虽然能够消除流量突刺的场景,但是不可避免的会造成流量的损耗。试想一下如果流量的分布不均匀,那么在流量少的时间窗口下,没有到达的流量实际是损耗的。
在实际场景中,例如天猫双十一零点高峰,流量实际在每个时间窗口都是处于极度饱和的状态,这个时候简单的窗口分片就能达到很好的限流效果。
在流量分布不均匀的情况下,我们可以实现动态的时间窗口分片,将不饱和的时间窗口流量在不超过系统负荷的情况下累加到下一时间窗口,这样可以降低流量的损耗。
Pontus-用友云限流服务
用友云iuap平台为了保证客户云端系统服务的稳定性,结合微服务平台的建设,推出了稳定服务套件之一的限流服务Pontus,帮助用友云客户构建稳定性的系统防护体系。
Pontus支持QPS和线程限流两种方式,结合用友云微服务治理平台,将限流服务通过中间件统一服务的方式,内置在应用的微服务框架体系中,对微服务接口提供统一的限流一级防护。
采用动态滑动窗口机制,能够对流量峰值进行削峰,并且最大程度的降低流量损耗。触发限流及后端接口响应超时时,自动触发接口降级。
pontus服务与用友云开发者中心无缝集成,包含在用友云中间件统一SDK中,用户应用在开发者中心部署之后,能够自动发现服务接口,并对相应服务接口进行限流配置。
源于电商大促多年实践场景,Pontus能够为云应用提供稳定一致的流量防护,进行流量削峰和系统熔断,为云应用的稳定性保驾护航。

原文地址:http://blog.51cto.com/14084875/2334683

时间: 2024-10-06 20:51:17

「技术干货」Pontus-用友云限流服务的相关文章

转: 拒绝「技术栈」选择恐惧症

所谓最小化可行产品(Minimum Viable Product,MVP),就是将产品快速推向客户,从客户反馈中不断进行迭代.更重要的是,MVP 也是研发团队进一步完善产品的基础. 但是,在正式代码之前,你需要选择今后支撑产品的 技术栈,也就是要选择好整个产品每一层所要应用的技术语言.架构等. 技术栈的选择往往是创始人面临的艰难问题.无论是技术人员还是非技术人员,如果不具体了解每个语言和架构的特点,面对现在如此多元化的IT技术,简直能逼死纠结症患者.而且,如果选错了语言或者框架,很可能会导致较为

用友云服务治理平台 助力企业微服务架构落地

本文主要阐述使用微服务架构时,治理框架或者平台需要解决的主要问题,微服务落地实施过程中所遇到的关键问题和对应解决方案.同时,文章也介绍用友云旗下的微服务治理平台的核心功能和技术架构,以及微服务治理平台在用友云一些产品下的实践,下一步的发展计划和趋势. 用友云微服务治理平台由来 伴随互联网.云计算.大数据等技术的快速发展,越来越多的企业在信息化之后,将企业上云和数字化提上日程.软件架构的微服务方式重构.应用的自动化运维.容器化等需求强烈,催生出了众多的PaaS平台.同时,针对微服务,也涌现除了许多

微服务架构之「 配置中心 」

在微服务架构的系列文章中,前面已经通过文章<微服务架构之「服务网关 」>介绍过了在微服务中服务网关的原理和应用,今天这篇文章我们继续来聊一聊微服务中另外一个重要模块:「 配置中心 」.后面还会继续介绍 服务框架.服务监控.服务治理等.还是那句话,只有将这些基础设施弄清楚了,微服务实践的道路才能走的稳.走的远. 「配置中心」,顾名思义,就是用来统一管理项目中所有配置的系统.虽然听起来很简单,但也不要小瞧了这个模块.如果一个中型互联网项目,不采用配置中心的模式,一大堆的各类配置项,各种不定时的修改

100offer举办的「寻找实干和坚持的技术力量」开源项目投票排名分析程序

由于100offer举办的「寻找实干和坚持的技术力量」开源项目投票活动没有按照票数排序的功能,所以本文写了个小程序来实现这个功能,代码如下: import org.jsoup.Jsoup; import org.jsoup.nodes.Element; import java.net.URL; import java.util.HashMap; import java.util.Map; import java.util.concurrent.atomic.AtomicInteger; /**

「iOS开发」关于一对一视频聊天直播系统技术(二)处理

针对视频直播的实时流网络 LiveNet 和完整的直播云解决方案,很多开发者对这个网络和解决方案的细节和使用场景非常感兴趣. 结合实时流网络 LiveNet 和直播云解决方案的实践,我们将用一系列文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面.深入地了解视频直播技术,更好地技术选型. 在上期采集中,我们介绍了视频采集针对音频采集和图像采集以及它们分别对应两种完全不同的输入源和数据格式. 本篇是<解密一对一视频聊天直播技术>系列之二:处理.我们将讲解常见视频处

50篇经典珍藏 | Docker、Mesos、微服务、云原生技术干货

概念篇 全方位探(tian)索(keng)Mesos各种存储处理方式 老肖有话说@Mesos User Group第四次约会 技术实践 | Mesos 全方位“烹饪”指南 回顾 JAVA 发展轨迹,看 Docker 与 Mesos Docker 与 Mesos 的前生今世 | 数人云CTO肖德时@KVM分享实录 如何利用 Mesos 持久化存储方案部署 ArangoDB 集群 数据处理平台架构中的SMACK组合:Spark.Mesos.Akka.Cassandra以及Kafka 畅谈 Mesos

全力支撑用友云产品 打造技术中台标杆项目

前言 随着云计算技术的不断发展,容器和Kubernetes已经成为云原生应用的基石,容器的周边生态也日益成熟,微服务.服务网格.DevOps等技术相继涌现. 容器的出现,推动了软件开发.测试.部署.运维和运营模式的创新.容器云平台的建立承载了企业的IT基础设施和基础技术服务,为企业应用的创新和发展提供了强有力的支撑,同时促进了与产业链生态环境中上下游系统的高效对接与协同创新. Kubernetes作为容器云的编排工具,目前已经成为行业的事实标准,完美地解决了调度,负载均衡,集群管理等功能. 开发

#技术男拯救世界# 如何自动跳过12306的「查询失败」

我等屌丝用不起Windows,也没法装哪些高大上的抢票浏览器,只好苦逼的刷12306官网.但是刷12306的过程中老是遇到「查询失败」错误,一旦遇到,刷票就自动中断了,让人非常不爽.于是就自己写了下面这个小脚本,用来跳过失败错误并恢复刷票. 使 用方法:打开任何浏览器,登录12306网站,进入查询/刷票页面,打开开发者工具里的网页控制台(Chrome:查看->开发者 ->JavaScript控制台,Firefox:工具->网页开发者->网页控制台,Safari:先打开「首选项」-&

技术干货:实时视频直播首屏耗时400ms内的优化实践

本文由"逆流的鱼yuiop"原创分享于"何俊林"公众号,感谢作者的无私分享. 1.引言 直播行业的竞争越来越激烈,进过2018年这波洗牌后,已经度过了蛮荒暴力期,剩下的都是在不断追求体验.最近正好在做直播首开优化工作,实践中通过多种方案并行,已经能把首开降到500ms以下,借此机会分享出来,希望能对大家有所启发. 本文内容的技术前提: 1)基于FFmpeg的ijkplayer,最新版本0.88版本: 2)拉流协议基于http-flv. http-flv更稳定些,国内