开发者社区> 琛琛轴子> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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

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

讲师:牛兔(张春梅)

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

高可用体系
云上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

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

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

相关文章
对于云原生时代的后端业务开发和项目系统学习,选Go Or Java?
现在的后端主流语言无非是 C++、Go、Java、Python这几类,这4个语言是近些年来不同时代不同业务阶段的后端语言开发代表。
0 0
物联网课程论文:《基于云原生的物联网端管云系统方案综述与演进设想》
这篇论文八千多字,主题是 云原生+物联网平台。花了几天心思,查了很多篇论文,因为自己对物联网通信的硬件方面不太会,所以还是选择写综述类的论文了,这篇论文感觉技术深度和广度比我上一篇计算机网络论文要更加深刻一点。
0 0
基于云原生的集群自愈系统 Flink Cluster Inspector(成本侧)
1. 业务背景与挑战1.1 实时计算集群现状关于热点机器处理一直是阿里云 Flink 集群运维的一大痛点,不管在日常还是大促都已经是比较严重的问题,同时这也是分布式系统的老大难问题。而在今年整个阿里云成本控制的背景下,随着集群水位的逐步抬升,热点问题愈发严重。日均有上千次的热点机器出现,并且在晚上业务高峰期,整个热点持续时间会超过 60min,对于业务以及对于平台影响是比较大的。(集群日均数千次机
0 0
云原生之使用docker部署Dochub文库系统
云原生之使用docker部署Dochub文库系统
0 0
云原生之使用docker部署centos系统测试环境
云原生之使用docker部署centos系统测试环境
0 0
【云原生实战】KubeSphere实战——多租户系统实战
【云原生实战】KubeSphere实战——多租户系统实战
0 0
【云原生 | 拓展01】手把手教你搭建ferry开源工单系统
erry 是集工单统计、任务钩子、权限管理、灵活配置流程与模版等等于一身的开源工单系统,当然也可以称之为工作流引擎。 致力于减少跨部门之间的沟通,自动任务的执行,提升工作效率与工作质量,减少不必要的工作量与人为出错率。.....................
0 0
直播回顾 | 云原生混部系统 Koordinator 架构详解(附完整PPT)
近期,来自 Koordinator 社区的两位技术专家从项目的架构和特性出发,分享了 Koordinator 是如何应对混部场景下的挑战,特别是提升混部场景下工作负载的运行的效率和稳定性,以及对后续技术演进的思考与规划。我们也将本次直播的核心内容进行了整理,希望能给大家带来一些深入的启发。
0 0
直播预告 | 云原生混部系统 Koordinator 架构设计
2022 年 4 月 6 日,阿里云原生混部系统 Koordinator 宣布正式开源。如果你想进一步了解 Koordinator,了解 Koordinator 如何应对混部场景下的挑战?如何解决集群资源利用率低、IT 成本高、集群资源管理复杂等问题?又如何改进提升混部场景下工作负载的运行效率和稳定性?
0 0
+关注
文章
问答
来源圈子
更多
阿里云 云原生应用平台 肩负阿里巴巴集团基础设施云化以及核心技术互联网化的重要职责,致力于打造稳定、标准、先进的云原生产品,成为云原生时代的引领者,推动行业全面想云原生的技术升级,成为阿里云新增长引擎。商业化产品包括容器、云原生中间件、函数计算等。
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
小团队能做大系统 Cloud Native云原生架构实践
立即下载
云原生混部系统 Koordinator 架构详解
立即下载
阿里云云原生 Serverless 案例集
立即下载