云原生下,如何保障业务系统的高可用性?-阿里云开发者社区

开发者社区> 阿里巴巴云原生> 正文

云原生下,如何保障业务系统的高可用性?

简介: 本文章由阿里云高可用产品的产品经理牛兔在阿里云社群直播中,从云原生角度来讲解如何保障业务系统的高可用性。

讲师:牛兔(张春梅)

本次分享将按照以下四个方面展开:

高可用体系
云上PTS服务
AHAS流量防护

一.高可用体系

1.高可用体系概念:除了像日常代码功能测试之外,其他与业务稳定性或者可用性相关的都可成为高可用体系,所谓高可用即就是让业务和服务高可用。
2.高可用体系按照功能或者业务实现可以分为:
①全链路压测:容量规划,弹性伸缩,线上压测;
②线上管控:限流降级,开关预案,流量调度,监控报警;
③异地多活:容错容灾;
④故障演练:依赖治理,灰度测试。
3.高可用体系中商业化的产品包括:PTS(性能测试服务)和AHAS 应用高可用服务。
4.AHAS 应用高可用服务包括线上流量防护以及故障演练两个部分。
在做业务需求或者业务维护时:除了关注资源层面问题,要站在更高一层去关注业务服务的情况,业务服务的整个系统架构能不能够高可用使用,从工具、方法、角度去关注可以如何做这些事情。

二.云上PTS服务

PTS的发展历程
image.png

从2008年开始,阿里巴巴开始做性能测试和分布式化,到2010年开始做容量规划方面,像CSP,Autoload的工具;之后开始做线下的性能测试,像PAP分布式压测平台,但是线下测试会产生相关问题,由于线上环境与线下规模以及代码配置之间有差异,会产生准确性能不够高的问题,可能会导致压出来的数据没有意义。之后开始尝试用CSP做线上测试,会涉及到基础的操作,会根据线上流量,从日志上里面爬一下里面涉及到的接口是什么,这些接口的大概比例是什么,相关日志回放,但是日志回放会有一个问题,用最简单的post类型来看,post类型几乎不会打到表单里去,就算打入日志里面去,数据能否正常使用也是一个问题。到2013年发布全链路压测1.0版本,该版本可以做全部链路的一些压测,包括基础数据构造,构造的数据可以全部放进去,以及链路之间的接口配置可以做到;到2014年,通过SV平台输出,但是此时SV平台利用做线下测试,类似于之前做的PAP,到2015年推出PTS基础版,形式为脚本形式,数据以及要压的东西,脚本以要在PTS版本里面写好,同年全链路压测开始做平台化,依赖的第三方端,例如在支付上,要如何去做,是要mooc掉还是做链路打通,探寻更多的平台,到16年一方面业务体系繁多,支持更多生态业务,第二个是否能做到更智能化,直到17年全链路压测的铂金输出,18年又加入开源方向,支持了Jmeter类型压测,19年性能测试与高可用领域的模块的深度融合。
PTS经过十多年的沉淀,逐步形成当今的成熟平台。

为什么要做性能测试?
性能测试-驱动力1
image.png

①价格和复杂度:分布式业务复杂度高,任何业务有可能成为一个瓶颈;
②业务量挤压非常大:比如在线教育、在线问诊业务量特别大;
③覆盖范围,贴合真实的业务场景:工具、压测模型要求流量更加真实,更加贴合业务场景,从客户测模拟。

性能测试-驱动力2
image.png

④压测方式:更加贴合真实业务场景,包含三种方式:引流,日志回放,全构造,一般会通过第三种方式来做。
⑤全场景:包括全场景压测,必须全场景覆盖,业务模型比较完整,要有容量规划或者容量评估的主线在,主要目的是发现问题在哪,得出自己的瓶颈点在哪,做优化主要是最后得出容量到底是什么样子;
⑥简&强:第一点:对于全场景的要求,主要是多角色的时候都需要有一个简单的操作在;
第二点:流量必须真实存在;第三点:形成一块闭环操作。
在不同的测试规模,以及对应的压测阶段会产生的相关问题,基于此,形成了如下模型:
image.png

总结:可以看到,非生产环境,一般发现的是代码类问题,比如说GC,内存,泄露或者配置做的可能不好,那么在生产环境会发现更多系统化,调用链路或者更多通用层面的问题,比如说负载均衡的问题。

对上述所有内容的总结分如下四大驱动力来总结:
image.png

第一点:分布式环境分布式环境,分布式架构导致瓶颈点有可能在A,也有可能在B,就会导致无法在黑盒环境下来看到具体问题在哪,就需要做分布式环境下的压测,除此之外,分布式还体现在压缩平台的伸缩性;
第二点:云化,本地维护成本高;
第三点:移动互联网,业务连续性要求高,包括业务不能中断,抢断市场比较滞后;
第四点:DevOps,操作成本非常低,有更好的体验。

性能测试的价值:
image.png

①品牌保障体验以及营销体验;
②洪峰流量或者大促,数据上来看,每0.1s的体验延时,会有10%的营收比例降低;
③成本人力以及服务器资源成本,如果可以简便评估目前的容量成本,在容量规划成本上会有大幅度降低。

如果做容量评估应该怎么做:
image.png

容量评估分为三步:
第一步:压测方法
①架构梳理;②确定目标以及方法;③测试准备:数据准备,模型准备;④Checklist记录:在关键时刻应该做什么事情。
第二步:工具选型
①:开源;②:SaaS产品。
第三步:场景压测
①构造方式;②压测模式;③定位方法。
开源和SaaS如何选择(以JMeter为例):
image.png

开源工具:开源工具本身具有其特点,协议支持范围比较广,是支持一些自定义的方法;

自研平台:对自身来说,对于源代码有一个比较深入的了解或者深入的熟悉过程,并且自研平台对于一些特殊的协议进行适配,但是在人力/资源成本、维护成本都比较高,并且稳定性也比较弱,如果原码版本有迭代,是否要跟着继续迭代;

PTS中JMeter的支持:高并发能力,流量可以按照真实的地域来发起,以及PTS自身有自己的采样日志,其次也透漏了JMeter的错误日志。
用SaaS的工具相对成本以及性价比都比较高。
image.png

压测报告中的一些日志记录:
image.png

上文主要讲述了JMeter平台的有关知识,PTS最核心能力的主要是自研的一个引擎,阿里巴巴双11活动主要用到的引擎,目前常用的主要用两套引擎,一套是自研的,另外一套是JMeter原生的。自研的引擎是纯UI编辑的形式,不需要涉及0代码,本地也不需要维护一些东西,只需要维护数据文件即可。

从流程介绍性能测试服务的能力:
image.png

image.png

从压测的阶段来分析PTS的能力:
image.png

云端录制:配置好代理,在pc上边操作就可录制下来。
image.png

从功能上来说:如图
image.png

SLA:服务协议,在某次压测时,可以定义压测服务对应的服务等级协议是什么,比如rt不能超过500ms,成功不能低于四个九,如果低于的话则可以做告警或者停止压测,这样就可以在压测的过程中帮助你监测压测过程的准确性。

定时压测:多用于预约或者定时的周期执行的工作,比如说每个月定时会有大促活动,基本每周迭代一次,前一天可以迭代几分钟,第二天对迭代结果进行分析就行,包括结合SLA中的服务等级协议,设置好状态成功率,则可以实现无人值守的工作。
压测过程中会有一些问题:如下
image.png

image.png

除图上列出的问题之外,还有预估与实际可能有差异,比如在春节期间,在线教育用户量可能会有所增加,那么会在春节之前就在线教育方面会有所扩容,但是会可能会出现意料之外的情况,比如疫情,那么就在线教育来说,肯定要再继续扩容以应对突增的用户,但是具体要扩增多少,并且扩容之后如果还出现问题那么要加一些防护措施。

出现问题之后处理时一定要高效,并且要在多层次多维度上处理问题。

三.AHAS流量防护

image.png

由2018年双十一相关数据来看:如图
image.png

从图上数据可以得出两点:
①量级很大;②时间非常短。
那么就要做好如果一旦出现问题的时候,对于客户的影响情况,如果问题没有得到及时处理,用户可能就会退出界面。
洪峰流量:
image.png

Sential的诞生:以双十一的经典界面为例。如下图所示:该图展现的是双十一活动中出现的经典界面,是为了限流。为了避免峰值过来时导致系统的雪崩,以保证大部分用户的体验。所以有了流量防护的工具。
image.png
image.png

Sential是什么?
Sential是一款面向分布式架构的轻量级控制框架,主要以流量为切入点,从以下几个维度保护系统及服务的稳定性:
①流量控制 ②熔断降级 ③流量整形 ④系统保护
以下述架构为例来进行相关说明:
image.png

网关层面:在网关层面可以做一些流量控制,分布式架构应用本身是集群化的,不同的应用本身之间会有调用,那就可以在应用级别做一些流量化的塑形,这个可以应用在错峰相关上。
适用场景:
①电商业务类,存在大促、秒杀等场景
②资讯类业务,社会热点带来不可预知的突发流量
③直播、视频类业务,在线观看连接数徒增
④突然出现来自某个ip的大量流量
⑤可能会出现刷单的情况,抢占了正常商品的流量
⑥需要自动识别并限制某些过热流量
那么在进行流量防护时都要考虑什么因素?
①允许访问的速率
②爆发量
③爆发间隔时间
image.png

接下来我们来看一下熔断降级的相关知识:
image.png

经过的链路越多,小明失败的概率就越高。
image.png

在被保护的应用发现有部分应用掉了,其中有一个应用异常,那么就会选择将这个应用降级掉,来保证其他服务的正常运行。也就是说,链路中某个资源不稳定时,对该资源调用进行限制。
image.png

传统的系统负载保护:根据硬指标做,但是硬指标具有延迟性,浪费了系统的处理能力;系统的恢复速度慢。进而导致以下问题:调节具有延迟性;恢复慢。

从而产生新的过载保护算法:如下图所示:
image.png

提出新的算法,需要结果来进行验证,如图:
image.png

对比了效果之后,我们来看一下性能的相关信息:
image.png

本文由社区志愿者整理而成,设区内容志愿者火热招募中,有好礼相赠哦。欢迎加入!戳我了解详情加入!

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里巴巴云原生
使用钉钉扫一扫加入圈子
+ 订阅

关注云原生中间件、微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生技术趋势、云原生大规模的落地实践

官方博客