开发者学堂课程【云原生中间件产品销售红宝书：应用高可用 AHAS 产品销售指南】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/629/detail/9890
应用高可用 AHAS 产品销售指南
内容介绍：
一、突发流量下，如何保证业务应用不宕机？
二、AHAS 产品简介
三、性能测试PTS+ AHAS一销售案例
四、客户案例介绍-太平
五、总结
一、突发流量下，如何保证业务应用不宕机？
1、突发流量下，如何保证业务应用不宕机？
11月份讲的是面对双11的红风流量做什么样的准备，从标题上能够感受到双11的红风流量，基本上是业务模型或者是双11玩法已经基本上确定时，也是能够预估出在这样的玩法情况下预估的运营流量或者是运营的业务指标大概是多少，应对样的指标准备怎么样的容量情况，做事情，怎么做，如果已经准备，还会有在预期之外的事情，为避免预期之外的事情给业务系统带来不好的效果应该做什么，所以两个系列是属于有延续性的事情。
2、如果面临突发流量，突发流量是预期之外的会有样的影响，
比如很经典的场景像有的公司老板今年年会时要发大红包或者要抽奖但是不想用钉钉抽红包之类的，觉得玩法不够好，他想要自己做发红包或者是抽奖的系统，在这时候他也预估了参加年会时一共有5000个人，5000个人平均点多少次都是没有问题的，做完压测预估出容量，整个做的非常好，但是在实际的年会的过程中会发现老板们的玩法花样比较多，比如几个老板一起发的时候，那个时间点的流量已经超过当时玩法预估的峰值信息，这时会发现整个系统出现预估之外的情况，比如服务器返回数据不正常，甚至是直接显示服务器已经停停止响应，在整个年会达到最高涨时出现很不好的反应，甚至是已经做了预期内的准备，但是还是出现预期外的事情，最终的结果是年会早早结束，整个准备的部门成为众矢之的，整个业务系统也出现预期之外的高负载，面对这样的突发流量时，当时很多情况的做法都是不知所措，不知道要做什么样的事情能够缓解突发流量带来的系统的影响，大多数情况扩容，但是扩容操作从头到尾准备，预估大概需要多少资源的准备，虽然现在有弹性但前前后后至少也要有个百小时，在实际业务的场景中一小时就会流失掉很多用户。
3、突发流量，业务宕机的原因
（1）缺乏意识
只知道准备资源，不知道要准确的准备资源，没有进行有效的评估。预估流量，预估业务，根据流量准备资源，但是没有非常准确的进行有效的突发情况的评估，没有做评估也没有做准备，自然没有准备有效的预案。
（2）没有提前准备预案措施
完全信任业务评估，没有准备有效的预案措施。
有做压测，准备对应的容量，也有一些措施，但是措施是出现宏峰流量时要把多余的流量给挡掉，保证大部分人的体验。
（3）用错工具
自己使用了开源的工具，没有正确的进行配置，导致引入新问题，在当时测试时没有发现。
（4）不知道快速修复问题
突发流量来领，不知道问题原因，只能堆机器扩容，但效果甚微。人为评估时会有预期外的情况出现，在真的预期外的情况来临时，不知道问题的原因，只能堆机器，效果非常小。
4、为什么要做限流防护
如果让业务系统做保护措施，压测是做预防措施，提前预估面对预估的流量一定要准备的事情，准备这么多机器，如果超过预期的流量，系统真的只能扛一万但是一万一千时要保证一万的流量是正常的，做限流防护，从常规的四个角度分析。
（1）品牌
因为不管是没有做压测还是没有做限流防护或者最终系统崩盘，会导致的品牌形象直接受损，经济情况或者是后续的营收，用户数都会有非常大的影响。由于对瞬间大流量的准备不足，导致给企业带来直接经济损失或者品牌形象受损的事情经常发生，需要保护大部分人丝滑使用服务。
（2）体验
有活动在推广期间，体验是非常重要的，有口碑也是在这时候建立的，如果体验不好会导致客户流失并且会带来类似于蝴蝶效应一样，会影响很多个人，推广期间的体验至关重要，会影响产品口碑及影响力。大量数据表明， 90%的人在首次使用时有不好的体验。后续将不许继续使用该产品。拉新或者挽回成本会非常高。
（3）成本
不同业务模型流量配比不同，如何精准识别突发流量点，并最低成本地进行业务恢复。
除了运营成本之外还会有技术上的或者是真实的容量的成本，不同的业务模型流量是不一样的，需要精准的识别突发的流量点是在哪里并且用最低成本的方式进行业务恢复，出现问题不可怕，最可怕的是出现问题不知道要怎么做，也不能够最低成本快速的进行恢复。
（4）不确定性
分布式系统复杂度和业务发展的不确定性，上下游;的依赖非常复杂，需要“不完全性”信任每个应用的上下游。进行“自我保护”。
比如天猫会掉支付系统，淘宝也会掉支付系统，上下游会非常的复杂，会导致在每一个应用它都需要不完全信任上游或者下游，会认为上游有异常的调用，认为下游在调用它时会出现异常的响应，都需要进行保护。
5、理想状态-活动运行环节
没有做限流防护和做限流防护，突发流量比较多的情况下会出现在活动里面，在活动运行环节时用不用限流保护对大部分用户体验差别会非常大，如果没有用的时候，在整个运行活动中突发流量时会相比抢火车票还难，当本身的系统能够跑1000个人但是有1500个人时，系统崩盘1500个人都不能访问，但是如果有限流防护时能保证至少1000个人可以完全没有问题，还会多出10%的人响应比较慢一点，只有剩下的400个人会有一点问题，但是已经保证大部分人的用户体验，所以运用限流防护之后，在活动中两个活动状态不同的对比，限流防护主要的措施或者是流程化的东西，需要准备或者架构的梳理，业务架构会涉及到哪些点，核心系统是什么，大致的容量是多少，能够承载的最大的qbsr是多少量以及不同的接口看需要达到的预案状态是什么，第二个是根据梳理的架构，做好的评估，做一波的压测，比较真实的达到能够拿到的容量水位的状态，第三步是在整理定位或者是容量微调时达到比较理想化的状态，第四步是非常重要的，全方位的防护环节，需要在关键的入口，集群，单机里面都需要做防护，根据前面接口的梳理得到有关键的接口是什么，每一个集群的体量是多少，系统防护是什么样子的，第二个在活动过程中时发现异常可以随时调整或者是随时隔离，比如有下游的应用出现运行时异常的状态需要进行隔离，不能影响当前以及上游，类似于这样的操作，在活动前的提前准备以及活动过程中时发现问题的实时恢复和调整，最后在活动结束之后做一波总结和分析，积累问题进行改进，为下一次的活动，限流防护的阈值沉淀经验，比如这次活动发现系统能够承载的更高，下一次的阈值防护可以把它往上调一点，所以都是需要一轮一轮沉淀不断时刻日常运行的东西。
6、客户案例介绍-某X利(全球直销品牌)
（1）客户场景
客户类型：中秋、国庆电商大促。
业务场景：8月首次大促，准备不足，线上电商营销失败，中秋大促压力较大、官网电商大促，含秒杀，支付等场景。
项目背景：时间紧迫、系统复杂、任务繁重。
（2）价值
客户收益：真实的模拟秒杀业务、多地域/运营商来源大流量，高真实度的完成性能测试，顺利完成大促，业务营收、平台口碑。
我们的收益：提升产品口碑，现在活动前都会使用压测产品，从PTS带入更多产品使用( AHAS. DTS咨询服务)，现是AHAS的重点标杆客户。
（3）操作方法
压测入场：梳理核心业务、 构造数据、压测实施，问题定位、 优化改造、再次验证。
新产品引入：熔断保护: 保证大部分用户的实时体验;大促目标数据确认：限流保护( AHAS )，DTS 引入，多活架构做保障。
（4）为何能成功?
业务梳理清晰，选择了主流、可靠的压测工具，性能测试服务。
全国的直销品牌，没有用压测，也是没有用限流防护，自己准备大促，败。第一次大促时发现因为从技术角度或者是产品运营的角度都会分别做总结和分析以及下一次的改进产品，运营上面会觉得以前的玩法不合适，所以下一次的业务模型改变，8月一直到中秋之间时间间隔非常短，还有电商大促会有比较传统的现象或者是普遍的现象，第三方比如支付宝或者短信通知之类的，依赖会非常的高，他们会被银行或者是接口给脱垮掉，对他而言挑战非常大，时间很紧迫，系统很复杂，任务很繁重，首要的目标是中秋和国庆的大促一定不能出现任何问题，在过程中这家公司使用AHAS限流防护的功能。客户直接发的朋友圈历史新高顺利过关，整个大促都是非常顺利。
现在安利只要有活动或者是新业务的推广它肯定会用AHAS做限流防护，对它的产品口碑整个的营收收益以及个客户体验都是非常好的。也会带动整个AHAS的服务，比如它会开始使用pds提前做压测的容量验证系统容量验证，再用AHAS根据验证的系统阈值做限流防护的措施以及根据压测过程中推断出哪些接口是容易出问题的，会有连锁的反应，也会配上相应的防护操作，安利现在是AHAS的重点客户。梳理业务构造数据进行压测实施得到系统的容量上限，它会根据容量上限配置的限流阈值，再进行一轮压测，进行限流阈值的验证以及限流之后的体验的验证，保证全方位的设置保护措施，同时根据业务的不同的重要程度设置不同的防护手段，比如核心的接口是入口流量，比如首页或者查看某个商品详情，操作排队的阈值是1000个人从第1001个到1010排队稍微慢一点，还有一种是削峰填谷，熔断是针对下游有异常的情况出现的，在活动中时秒级监控，AHAS限流防护是提供秒级监控，注意秒级监控除了看整个接口，它还可以看到sql语句秒级的监控，看的是什么应用，就可以看到应用最低力度的监控数据，在过程中真的出现突发异常，和之前是否有遗漏或者有异常的调用时可以快速的调整进行隔离降解，生效时间也是秒级实时生效的。成功的客户案例总结，三个重要的点，第一个是业务梳理比较清楚，第二个是提前用压测进行容量的验证和限流阈值的验证以及体验的验证，最重要的一点是选择主流可靠便捷的限流防护工具，便捷是出现问题时要非常能够快速的实施以及在使用它的时候成本要非常的低，可靠，用它做系统的防护，如果工具自身不正常如何对系统进行限流防护。
7、大促成功原因
（1）清晰的业务与数据
梳理清楚压测范围、准备好相应的数据
（2）最正确的工具
压测验证容量
秒级实时监控查看数据
如果的监控力度是一分钟的，很多时候大促的洪峰时间也就两三分钟的时间，如果监控数据力度延迟一到两分钟，等反应过来时它已经异常，浪潮已经过去。
简单操作，快速接入防护工具
限流时能有一个较好的体验
突发异常降级操作后秒级生效
限流保护大部分人能够正常用，被挡掉的那部分人，业务上也是希望有较好的体验，并不是直白的挡掉他，给他一个比较好的体验方式。突发的异常操作需要秒级的生效，跟刚洪峰流量也两三分钟的时间，如果不能秒级生效，会产生蝴蝶效应雪崩的现象，整个热点的浪潮已经过去，选择最正确的限流防护工具才会使整个大促能够最终圆满的进行。
（3）成功的大促活动
较准确的容量评估(保证最大用户流量)
安全的限流防护:访问如丝滑运行，不用挤破头
8、限流防护工具对比
（1）开源 Hystrix
线程池/信号量维、插件形式、代码强入侵、适配框架有限
（2）开源 Sentinel
区分强弱依赖不同防护策略，使得整个的防护体积会更加的丰富，更加的强大和灵活，流量整形/热点检测/负载保护，热点检测类似于刷单的操作，同一个ip超过它正常的访问，比如在疯狂的刷单时同一件商品它会不停的加购，正常时不会一秒钟之内把一件商品加购物车加100次，能够很好的识别出异常的请求或者是异常的调用。适配几乎全部主流框架、本地sdk防护，只需较少代码修改。适合单机集群，在修改代码上面量是非常少的，不会像hystrix代码入侵性非常强。
（3）AHAS 应用高可用服务
包含开源 sentinel 中全部功能
强弱依赖不同的防护策略，主流框架以及流量整形，热点检测，负载保护全部都有。
可通过 agent 部署，无需任何代码修改
只需要在限流防护保护的机器上装 agent，不需要修改任何的代码，所以针对运维测的同学非常友好，因为运维的同学要对线上的稳定性负责，但是他没有权限修改线上的代码，如果用 agent 的部署方式能够完全的满足它，它可以对系统进行基础的维护，agent 维护，但是不需要修改应用的代码，也能够达到整个系统体系的安全防护。
开箱即用，快速配置/生效
在控制台上可以操作。
秒级监控查看
在页面上可以看到实时的秒级监控以及历史监控的数据也都是秒级的。
非云上服务亦可使用，并不是只有阿里云商的服务才可以用，非阿里云上的用户，比如是友商边也可以进行通过公网的方式上报数据。
可自行设置防护等级
比如防护等级分为两种，一种是入门级，一种是高级入，入门级防护规则少一点，可以满足日常基础防护的功能，收费也非常低，只有全量防护的一折，三毛钱一天，一个节点才三毛钱一天，高级防护很多时候会用在宏峰大促的场景，或者是新系统要推广时候的场景，它需要做全面的系统防护，入门级在日常里面的维护已经够了，以防万一的情况，高级防护时可以更加全面的保护系统，而且都是在页面上控制台上切换就会实施生效的。商业化的竞品是没有的，别家公司没有做，现在只有阿里云AHAS提供商业化的服务，目前有五个节点，后面会有一定额度的免费试用。
