如果我来负责支付宝双11大促保障(三)

在梳理好有哪些系统将参与到大促后,我们的目标就是对它们的现状进行健康检查,为后续制订优化方案提供数据支持。

同样,检查纬度还是依照上面罗列的,从自身、依赖方、服务方、基础服务和后台服务五个纬度来检查。

 

自身



1、硬件
主要是检查服务器的各项指标,包括CPU、IO、内存、连接数以及磁盘剩余空间。

2、软件
此次我们只是着重于检查JVM的一些参数,如GC策略和启动参数。

3、接口服务

  • 接口性能。检查tps、成功率、耗时、流控阀值以及超时时间(调外部服务)
  • 定时任务。要明确其作用,用来决定是否执行关闭、流控降级等策略。同时要了解并发数,单线程和多并发对资源的消耗和性能的影响是不一样的。关注耗时主要目的在于,如果其耗时过长,对大促的影响可能比较大,则需要考虑是否可错峰关闭。最后的执行时间肯定是必须的,如果和大促重叠执行,则面临的风险自然是很大的。
  • 降级。 降级是我们系统服务治理的一个重要环节,现简单介绍一下我们在设计流控系统时的一些策略。
    降级的目的主要是为了保护系统自身,当请求量超过系统自身承载量时,及时的执行降级策略,保证核心服务不受影响,牺牲部分非核心业务是必须的。
    降级的策略通常有三种:
    1、超时降级。此情况通常发生在依赖服务频繁长时间的不可用或者因为压力过大响应特别慢,导致调用几乎都达到最大耗时。如果任由其发展下去,系统平均耗时将极具增加。同时,由于顾客并不清楚具体原因,及可能刷新页面,频繁请求,将导致请求量成倍扩大。结果是,一边是请求耗时过长,一边是请求突然猛增,结果可想而知。
    在有一次活动期间,我们依赖的一个系统因为压力过大处理能力极具下降,响应时间陡增,这导致我们的处理时间迅速被拉长,系统被拉向崩溃边缘。于是我们及时采取降级策略,执行了多级流控才保住系统。试想,如果我们没有这个降级保护,将引起连锁反映,整个支付路径的系统都可能被拖垮。有经历过类似情况的朋友肯定清楚,依赖服务宕机不可怕,就怕它一直超时。宕机大不了不用,但是超时,没准会拖垮整个系统。
    2、统计失败次数降级。对于一个服务,如果它不能满足一定成功率,保证一定的服务质量,采取降级的措施是必要的。毕竟,如果支付都是失败,就不应该让用户支付。
    3、故障降级。也就是依赖服务出故障了执行降级。
    降级的类型主要分为人工降级自动降级。由于当时人力和能力的不足,所以降级我们采用的是人工去调整流控阀值,但缺点就是响应时间慢,有可能洪峰就在这一瞬间压垮了系统。
    从降级的程度可分为流控开关。我们在设计时,针对核心系统的核心接口采用的是多级流控,核心系统非核心接口采取的是单极流控或者是开关。
    回到梳理降级方面。当时我们梳理了接口的流控令牌名称和最新流控阀值。
    时间有点晚了,改日完成系统容量评估和压测
时间: 2024-10-05 07:59:39

如果我来负责支付宝双11大促保障(三)的相关文章

如果我来负责支付宝双11大促保障(一)

双11火爆的气氛还没消去,全民狂欢的情景还历历在目,看到阿里炫出的成绩单,突然一阵,如果我是支付宝双11大促保障的负责人,我该怎么保证每一位顾客能越快越满意的买到自己心爱的商品呢?接下来,我将详细介绍一下我的实现步骤. 对于这么重要的活动,心中自然要有个明确的计划.主要分为十二个大的步骤.(1)明确目标(2)梳理外部影响条件(3)梳理内部现状(4)制订子目标(5)识别瓶颈点(6)性能优化(7)梳理风险点(8)制订应急预案(9)梳理非关键成员对关键成员的影响(如资源竞争)(10)制订沟通机制(11

如果我来负责支付宝双11大促保障(五)

接下来我们需要梳理的是核心路径容量模型.首先,需要梳理的是核心路径调用链,就是指核心路径上的调用接口.其次,梳理各接口之间的调用信息,包括调用顺序.调用次数以及同级别接口调用流量比.这些信息都是为了后面建立容量模型做准备.   制订子目标 预估总流量,制订目标TPS在收集完上面的信息后,我们需要分解目标,依次完成各个子目标.在第一步,我们收集了大促活动的详细信息,因此,我们根据这些数据和历史数据预估此次活动的量,然后乘以一定的系数,作为我们此次的目标TPS.比如,双11活动,我们预估将有600T

如果我来负责支付宝双11大促保障(四)

在梳理好有哪些系统将参与到大促后,我们的目标就是对它们的现状进行健康检查,为后续制订优化方案提供数据支持. 同样,检查纬度还是依照上面罗列的,从自身.依赖方.服务方.基础服务和后台服务五个纬度来检查.   自身 1.硬件主要是检查服务器的各项指标,包括CPU.IO.内存.连接数以及磁盘剩余空间. 2.软件此次我们只是着重于检查JVM的一些参数,如GC策略和启动参数. 3.接口服务 接口性能.检查tps.成功率.耗时.流控阀值以及超时时间(调外部服务). 定时任务.要明确其作用,用来决定是否执行关

双11大促期间,作为一个测试人员的反思

双11大促,发现大部分测试人员只能做做功能测试. 但其实我们能做的很多,但是都是要求有一定权威性和执行力,我们所缺乏:1.针对免测情况的各业务风险评估--mike:目前的EOS权限控制在开发,RPM根本没有权限控制系统,所以测试环境部署确实,业务免测测试也经常不知道.这个问题已经在沟通解决了,会让运维开发RPM的权限管理系统,慢慢地把权限从开发人员收回,免测试发布一定要经过测试人员(部署测试环境这一环节,部署的时候由对应测试人员评估风险) --me:其实这个也不解决根本问题,就算把权限从开发收回

双11大促期间服务可用率突然降到50%以下

线上一个服务0:00-0:20没有任何问题,0:20之后突然一个服务调用量增加(不合理接口调用量应该都是0:00开始猛地暴涨), 接口可用率降到50%以下.如果是核心交易接口,那么订单将影响一半以上,很可怕.还好,不是核心业务,是一个辅助展示 业务,并且业务本来不应该打开. 那么为什么配置被打开?为什么调用量增加?马上和下游沟通,以及查找问题,如有情况对系统做降级处理,返回通用数据, 因为下游程序发生了bug,在配置服务时候导致配置异常,不该调用我们接口配置被打开,调用我们接口量暴涨. 为什么调

华普在线全球服务器租用和托管【双11大促销买2月送1月】

美国CPU:至强四核 内存:16G 硬盘:1T 带宽:G口 IP:244(4C) 原价:1299元/月 秒杀价:1299元/月(买二送一) 节 省:1299元 香港CPU:酷睿四核 内存:16G 硬盘:1T 带宽:10M不限 IP:1 原价:1799元/月 秒杀价:1200元/月(买二送一) 节 省:2997元 更多优惠机型加qq2850693174 双11全部优惠 多买多优

大屏设计系列之六:有"屏"有据,阿里双11大屏是怎样炼成的

如果您想订阅本博客内容,每天自动发到您的邮箱中,请点这里 [IT168 专稿]本文根据[2016 第七届中国数据库技术大会](微信搜索DTCC2014,关注中国数据库技术大会公众号)现场演讲嘉宾染熙老师分享内容整理而成.录音整理及文字编辑[email protected]田晓旭@老鱼. 染熙,阿里云前端可视化工程师,负责DataV组件的架构.DataV可视化工具产品,以及数据产品的研发和2015年双十一的前端开发.专注于pc端web数据可视化的架构,探索数据可视化自动测试.新型的数据可视化等领域

京东商品详情页应对“双11”大流量的技术实践

大家来京东打开商品页一般会看到如通用版.闪购.全球购等不同的页面风格,这里面会牵扯到各种各样垂直化的模板页面渲染.以前的解决方案是做静态化,但是静态化一个很大的问题就是页面改版时需要重新全量生成新的静态页.我们有几亿个商品,对于这么多商品,你如果生成页面的话需要跑很多天,而且还无法应对一些突发情况. 比如新的<广告法>,需要对一些数据进行清洗,后端清洗时间和成本来不及,那么很多时候就是从前台展示系统来进行数据过滤.因此需要非常灵活的前端展示架构来支持这种需求. 首先这是我们前端首屏大体的结构.

【转】京东商品详情页应对“双11”大流量的技术实践

原文链接:http://www.csdn.net/article/2015-12-28/2826570 大家来京东打开商品页一般会看到如通用版.闪购.全球购等不同的页面风格,这里面会牵扯到各种各样垂直化的模板页面渲染.以前的解决方案是做静态化,但是静态化一个很大的问题就是页面改版时需要重新全量生成新的静态页.我们有几亿个商品,对于这么多商品,你如果生成页面的话需要跑很多天,而且还无法应对一些突发情况. 比如新的<广告法>,需要对一些数据进行清洗,后端清洗时间和成本来不及,那么很多时候就是从前台