画布 1
压测问题
  压测的必要性
    先勾勒系统的拓扑，然后对拓扑进行分类，把业务系统、中间件和基础设施分开来，查看容量和瓶颈
    技术必要性
      勾勒系统依赖
      发现基础设施瓶颈
      发现中间件瓶颈
      测算业务性能
      测算系统容量
    业务必要性
      品牌
        大促活动前，为了保障品牌必须预防事故
          双十一商家都会加倍采购，大促反而掉单，业务结果极差
      体验
        减少核心体验的延迟，增加营收
      成本
        评估业务财年的人力成本
  压测的目标设立
    双十一目前每一年的系统峰值都不可预测
      2020 年
        订单创建（提单、生单）峰值
          583,000
            交易限流的阈值大致上是 60 万
        支付峰值
          440,000
            支付限流的阈值大致上是 52 万
      保险峰值
        日单量 xxx 单
        峰值投保 qps xxx 单
        峰值插曲 qps xxxx 单
    涉及多少个 bu、bg 加入
      有总技术团长 + 技术大队长
        每个 bu 有队长
    压测一次通过率多高
  建立流程把控
    通过合理的分工来提高协作效率
    有效的方案
      如果有必要，应该在节假日以前压测
      如果可行，应该常态化压测
      要准备压测场景
    业务玩法是怎样的
      七月份就开始设立业务目标和玩法
    技术备战
      8 月、9 月进行开发，组织双周会汇总进度，10 月产出作战手册
    充足的准备
    靠谱的平台技术产品，压测要依赖于压测平台的，最好有商业产品
      流量录制
      生成压测计划
        导入压测数据
        导入压测脚本
        允许配置压测环境变量
        配置 set 环境
      发送
      停止
      监控汇总
      生成压测报告
    压测准备
      压测环境准备
        复用真实环境
          缩容压测、另建环境压测不可行，因为物理环境变了。
        压测环境改造
          业务改造
            识别压测流量
              在任何环节都不丢压测标记
                请求头 + ThreadLocal
                请求头 + Java agent
                对业务代码低侵入
              压测流量本身可能是某个特定时间的流量，这样即使丢失压测标记，进入 db 中的数据也是无效数据。所以可能
            流量单一性问题
              单一流量是否会触发某些短路行为，是否会被幂等、拦截、限流，触发动态校验、触发缓存加载、压测流量不应该触发安全策略
            流量的限流限制
              精细化限流和熔断会导致压测局部失灵
            剔除压测数据对报表的影响
            剔除压测数据对搜索引擎的影响
            建造影子表
              schema 必须完全一致
            离开全链路的服务要做好挡板设计
              可以 mock 的先 mock
                报文
                支付
                供应链出库
                不要大量发信息、邮件给客户！
              不可以 mock 要考虑是不是有配置能够切成线下模式
                结算
            能够识别时间偏移
              否则优惠券等业务规则验证不到
            提前申请够足够的压测资源
              业务服务器
              中间件资源
                特定配置集群
                特定分区扩容
          中间件改造
            数据库的影子表改造，数据库中间件必须可识别压测流量
              数据库的影子存储是拦截数据库连接后替换jdbc connection对象，保证测试流量的sql语句执行在影子db实例中，影子db实例与线上db实例保证在同一数据库集群内，保证压力测试有效；
                也就是说在一个线程的 ThreadLocalMap 里准备两个 connection 对象。
            缓存的影子表改造，缓存中间件必须识别压测流量
              redis和memcache是拦截连接后改写缓存的key，在原key前加统一压测标识并写入同一缓存集群中，保证压力测试有效，压测产生的缓存过期时间统一改短到1分钟，并开发测试缓存删除脚本，执行后可快速释放缓存空间；
                使用真实环境必须使用原集群
            消息队列
              要支持影子 partition 和影子 msg
              要支持动态扩容
            日志组件要支持压测日志单独分离出来
              部分业务产生的日志可能会被大数据部门采集后制作报表或各类数据统计，目前对logback进行了支持，将测试流量产生的日志写入单独的测试日志文件中。另一种可选方案是在日志内容中增加压测标记，在日志收集处理服务中识别压测标记后丢弃，这样处理出错风险更低，但前提是用相同的日志框架并有统一的日志收集处理服务，目前网易严选团队采用的是这种方案；
            扩缩容问题
              容器要有办法扩缩容
              配置推送要能够精确广播成功
      基础数据准备
        保证数据的数量级
        选取业务模型数据
          买家
          卖家
          商品
          如果有必要，可以使用全测试数据
        数据采样
          如果数据散列程度不够，可能会触发缓存、限流
          不同的数据可能造成的请求响应时长也不一样
        数据过滤
          如果过滤的数据不够，可能需要生成待测试数据，也就是所谓的“语料生成”
        数据脱敏
        业务模型数据的建立
          评估涉及到的系统和接口
            结合过去的数据
            结合业务的玩法
            要产出一个漏斗，交易核心环节和非核心环节的请求和数据的数据量的数量级会有很多区别。千万不要忽略接口的请求量的数量差异。
要画架构总图
          数量级
            按现实数据，乘以比例计算压测数据数量级。
          数据形式
    压测实施
      系统预热
        平时预热，压测也就需要预热。
          压测的预热可以用流量爬坡来做，不断波状脉冲压测。爬坡的过程中需要不断观察各项指标。
          爬坡可以先从预发布环境开始，然后进入 prod 环境
      登录准备
        平时大促，压测时也要登录
          如果架构设计里面需要使用到长连接，登录特别重要
      准备施压机
        如果需要大规模压测，施压机要预先准备好
        压测机如果需要管控流量，要有集群统一精确限流的手段，甚至接口流量调节能力。要有集群调度能力，考虑中心化调度和去中心化调度。
          分布式的集群可以模拟各个入口的真实下单请求
          分布式的集群可以操纵流量配比
          如果有分链路业务流量分流，一定要搞清楚压测流量配比
      选取压测时机
        为了减少压测事故对业务带来的影响，通常要选择业务低峰期。所以以前经常要熬夜通宵压测。
        压测开始前要拉群、周知 sre、dba、rd、qa、相关中间件同学以及上下游负责同学
      正式压测策略
        峰值脉冲：即完全模拟0点大促目标峰值流量，进行大促态压测，观察系统表现。
        系统摸高：取消限流降级保护功能，抬高当前压测值（前提是当前的目标压测值已经达到，则可以进行摸高测试），观察系统的极限值是多少。可进行多轮提升压力值压测，直到系统出现异常为止。
        3）限流降级验证：即验证限流降级保护功能是否正常。 （AHAS引入）商业化产品AHAS(应用高可用服务，Application High Availability Service）提供了全面的限流降级能力，可进行全链路的降级保护。
        破坏性测试：这个主要是为了验证预案的有效性，类似于容灾演练时的预案执行演练。即为持续保持大促态压测，并验证预案的有效性，观察执行预案之后对系统的影响。
        一般的压测至少包含这一种
    压测后
      清理现场
        所有机器重启
        缓存重新刷新预热
      复盘
        查看压测数据，分析瓶颈
          vm
            fgc 次数
            fgc 平均时间
            各个区域使用率
            blocked 状态线程数
            waiting/timed_waiting 线程数
          服务 rt
            tp999 响应耗时
            服务错误率
              系统错误
              业务错误
          数据库性能
            读写性能
            响应时间
            主从延迟
          mq 性能
            是否产生堆积
            消息发送时延
            消息消费时延
        产出改进计划
        确定下一轮压测时间
  先聊 kpi，有目标以后再分解 kpi