讲师：牛兔（张春梅）
本次分享将按照以下四个方面展开：
高可用体系
云上PTS服务
AHAS流量防护一．高可用体系
1.高可用体系概念：除了像日常代码功能测试之外，其他与业务稳定性或者可用性相关的都可成为高可用体系，所谓高可用即就是让业务和服务高可用。
2.高可用体系按照功能或者业务实现可以分为：
①全链路压测：容量规划，弹性伸缩，线上压测；
②线上管控：限流降级，开关预案，流量调度，监控报警；
③异地多活：容错容灾；
④故障演练：依赖治理，灰度测试。
3.高可用体系中商业化的产品包括：PTS(性能测试服务)和AHAS 应用高可用服务。
4.AHAS 应用高可用服务包括线上流量防护以及故障演练两个部分。
在做业务需求或者业务维护时：除了关注资源层面问题，要站在更高一层去关注业务服务的情况，业务服务的整个系统架构能不能够高可用使用，从工具、方法、角度去关注可以如何做这些事情。
二．云上PTS服务
PTS的发展历程
从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
①价格和复杂度：分布式业务复杂度高，任何业务有可能成为一个瓶颈；
②业务量挤压非常大：比如在线教育、在线问诊业务量特别大；
③覆盖范围，贴合真实的业务场景：工具、压测模型要求流量更加真实，更加贴合业务场景，从客户测模拟。
性能测试-驱动力2
④压测方式：更加贴合真实业务场景，包含三种方式：引流，日志回放，全构造，一般会通过第三种方式来做。
⑤全场景：包括全场景压测，必须全场景覆盖，业务模型比较完整，要有容量规划或者容量评估的主线在，主要目的是发现问题在哪，得出自己的瓶颈点在哪，做优化主要是最后得出容量到底是什么样子；
⑥简&强：第一点：对于全场景的要求，主要是多角色的时候都需要有一个简单的操作在；
第二点：流量必须真实存在；第三点：形成一块闭环操作。
在不同的测试规模，以及对应的压测阶段会产生的相关问题，基于此，形成了如下模型：
总结：可以看到，非生产环境，一般发现的是代码类问题，比如说GC，内存，泄露或者配置做的可能不好，那么在生产环境会发现更多系统化，调用链路或者更多通用层面的问题，比如说负载均衡的问题。
对上述所有内容的总结分如下四大驱动力来总结：
第一点：分布式环境分布式环境，分布式架构导致瓶颈点有可能在A，也有可能在B,就会导致无法在黑盒环境下来看到具体问题在哪，就需要做分布式环境下的压测，除此之外，分布式还体现在压缩平台的伸缩性；
第二点：云化，本地维护成本高；
第三点：移动互联网，业务连续性要求高，包括业务不能中断，抢断市场比较滞后；
第四点：DevOps，操作成本非常低，有更好的体验。
性能测试的价值：
①品牌保障体验以及营销体验；
②洪峰流量或者大促，数据上来看，每0.1s的体验延时，会有10%的营收比例降低；
③成本人力以及服务器资源成本，如果可以简便评估目前的容量成本，在容量规划成本上会有大幅度降低。
如果做容量评估应该怎么做：
容量评估分为三步：
第一步:压测方法
①架构梳理；②确定目标以及方法；③测试准备：数据准备，模型准备；④Checklist记录：在关键时刻应该做什么事情。
第二步：工具选型
①：开源；②：SaaS产品。
第三步：场景压测
①构造方式；②压测模式；③定位方法。
开源和SaaS如何选择（以JMeter为例）：
开源工具：开源工具本身具有其特点，协议支持范围比较广，是支持一些自定义的方法；
自研平台：对自身来说，对于源代码有一个比较深入的了解或者深入的熟悉过程，并且自研平台对于一些特殊的协议进行适配，但是在人力/资源成本、维护成本都比较高，并且稳定性也比较弱，如果原码版本有迭代，是否要跟着继续迭代；
PTS中JMeter的支持：高并发能力，流量可以按照真实的地域来发起，以及PTS自身有自己的采样日志，其次也透漏了JMeter的错误日志。
用SaaS的工具相对成本以及性价比都比较高。
压测报告中的一些日志记录：
上文主要讲述了JMeter平台的有关知识，PTS最核心能力的主要是自研的一个引擎，阿里巴巴双11活动主要用到的引擎，目前常用的主要用两套引擎，一套是自研的，另外一套是JMeter原生的。自研的引擎是纯UI编辑的形式，不需要涉及0代码，本地也不需要维护一些东西，只需要维护数据文件即可。
从流程介绍性能测试服务的能力：
从压测的阶段来分析PTS的能力：
云端录制：配置好代理，在pc上边操作就可录制下来。
从功能上来说：如图
SLA：服务协议，在某次压测时，可以定义压测服务对应的服务等级协议是什么，比如rt不能超过500ms，成功不能低于四个九，如果低于的话则可以做告警或者停止压测，这样就可以在压测的过程中帮助你监测压测过程的准确性。
定时压测：多用于预约或者定时的周期执行的工作，比如说每个月定时会有大促活动，基本每周迭代一次，前一天可以迭代几分钟，第二天对迭代结果进行分析就行，包括结合SLA中的服务等级协议，设置好状态成功率，则可以实现无人值守的工作。
压测过程中会有一些问题：如下
除图上列出的问题之外，还有预估与实际可能有差异，比如在春节期间，在线教育用户量可能会有所增加，那么会在春节之前就在线教育方面会有所扩容，但是会可能会出现意料之外的情况，比如疫情，那么就在线教育来说，肯定要再继续扩容以应对突增的用户，但是具体要扩增多少，并且扩容之后如果还出现问题那么要加一些防护措施。
出现问题之后处理时一定要高效，并且要在多层次多维度上处理问题。
三．AHAS流量防护
由2018年双十一相关数据来看：如图
从图上数据可以得出两点:
①量级很大；②时间非常短。
那么就要做好如果一旦出现问题的时候，对于客户的影响情况，如果问题没有得到及时处理，用户可能就会退出界面。
洪峰流量：
Sential的诞生：以双十一的经典界面为例。如下图所示：该图展现的是双十一活动中出现的经典界面，是为了限流。为了避免峰值过来时导致系统的雪崩，以保证大部分用户的体验。所以有了流量防护的工具。
Sential是什么？
Sential是一款面向分布式架构的轻量级控制框架，主要以流量为切入点，从以下几个维度保护系统及服务的稳定性：
①流量控制 ②熔断降级 ③流量整形 ④系统保护
以下述架构为例来进行相关说明：
网关层面：在网关层面可以做一些流量控制，分布式架构应用本身是集群化的，不同的应用本身之间会有调用，那就可以在应用级别做一些流量化的塑形，这个可以应用在错峰相关上。
适用场景：
①电商业务类，存在大促、秒杀等场景
②资讯类业务，社会热点带来不可预知的突发流量
③直播、视频类业务，在线观看连接数徒增
④突然出现来自某个ip的大量流量
⑤可能会出现刷单的情况，抢占了正常商品的流量
⑥需要自动识别并限制某些过热流量
那么在进行流量防护时都要考虑什么因素？
①允许访问的速率
②爆发量
③爆发间隔时间
接下来我们来看一下熔断降级的相关知识：
经过的链路越多，小明失败的概率就越高。
在被保护的应用发现有部分应用掉了，其中有一个应用异常，那么就会选择将这个应用降级掉，来保证其他服务的正常运行。也就是说，链路中某个资源不稳定时，对该资源调用进行限制。
传统的系统负载保护：根据硬指标做，但是硬指标具有延迟性，浪费了系统的处理能力；系统的恢复速度慢。进而导致以下问题：调节具有延迟性；恢复慢。
从而产生新的过载保护算法:如下图所示：
提出新的算法，需要结果来进行验证，如图：
对比了效果之后，我们来看一下性能的相关信息：
本文由社区志愿者整理而成，设区内容志愿者火热招募中，有好礼相赠哦。欢迎加入！戳我了解详情加入！
