仿真环境/流量回放/全链路压测/故障注入

本文涉及工程中测试/稳定性相关的一些内容,全文见:https://segmentfault.com/a/11...
1.仿真环境是用线上流量转发到下线环境做线下实验。重点在于流量引入和数据/队列/push,im服务的隔离
2.全链路压测 是用大量与线上流量类似的流量请求到线上,检测故障。重点在于大量数据与真实流量的模拟,压测数据隔离
3.流量回放 可以用来定位问题,将有问题请求百分百还原到线下机器,对控制读写接口返回用线上真实mock,可不断重复。重点在于线下请求劫持到回放机器进行mock,和mock数据匹配。
4.故障注入也被叫防火平台,用于故障主动注入演练服务保护有效性等。
因为都是公司未开源东西。这里都会涉及到引流和数据隔离,先重点说下这两个的通用解决,然后只简单介绍四个的实现。

引流:

1.通信框架实时引流:

  • 方案:
    框架层根据包头中的额外信息,判断哪些流量需要转发到仿真环境,只转发需要转发的流量,且实时转发
    判断转发条件在配置平台下发
    连接池,隔离目标server。
  • 优点:可以按业务细粒度引流
  • 缺点:无法回放

2.收到请求后写入MQ,引流系统消费

  • 优点:可以重读消费
  • 缺点:请求密集度和线上不一致

3.日志回放(全链路压测)

  • 方案:收集线上日志,通过日志还原请求
  • 优点:业务无侵入
  • 缺点:日志还原复杂

4.TCPCOPY

  • 方案
    基于数据链路层/网络层抓包回放
    tcpcopy通过libpcap(数据链路层)或rawsocket(IP层)抓包

    clipboard.png
    assistant server为了截获响应给TCPCopy,不会回给online server

  • 优点:业务无侵入
  • 缺点:网络层就无法按照业务选择

5.TCPDUMP流量(流量回放)

  • 方案
    单独机器采样TCPDUMP录制流量,编写工具读取并解析.cap文件,实现流量回放
  • 优点:可以多次回放请求
  • 缺点:解析.cap文件+cap文件存储+tcpdump对耗时稍有影响

数据隔离

1.全部单独数据配置。

数据同步+大量机器

2.数据访问流量劫持

写本地或写丢弃,读线上。

  • 本机访问线上数据流量劫持方案:iptable
    原理
    Netfilter是Linux用于网络数据包过滤的模块,它有四个表五个链。Iptables是用于向这Netfilter添加规则的用户空间程序。
    E.g.
    // 将本机发往9613的tcp包转到100.90.160.37的9613端口
    iptables -t nat -A OUTPUT -p tcp --dport 9613 -j DNAT --to 100.90.160.37:9613
    // 将本机非root用户发往beststg集群3000端口的流量重定向到本机9001端口
    iptables -t nat -A OUTPUT -p tcp --dport 3000 -m set --match-set beatstg dst -m owner ! --uid-owner 0 -j REDIRECT --to 9001
    // 将本机发往100.69.238.129 9000端口的tcp流量丢弃
    iptables -A OUTPUT -p tcp -d 100.69.238.129 --dport 9000 -j DROP
  • 需要数据劫持到单独模块
    redis
    mq topic、回调地址

需要考虑数据

redis,mq,mysql

仿真环境

  • 通信框架实时引流。
  • 对数据iptable劫持
    1.redis:劫持到RedisRouter
    2.mq
    1)发出去的请求带回调地址的(比如bridgemq),劫持到mqproxy。替换请求中的回调URL为目标环境URL
    2)topic都改成线下的,发送和的订阅都改

全链路压测

  • 模拟数据:日志回放。
    按照接口配置顺序取高峰期几小时数据。对请求中部分数据替换为压测
  • 全部单独数据配置:
    压测用户信息单独存储,单独存储。mysql,redis加注释方式.mq的topic统一加前缀
  • 施压工具开发
    用的NIO
  • 整体架构

    clipboard.png
    ultron-server:web控制台,负责新建压测计划、压测任务,调整压测,修改压测配置,查看压测监控和性能数据等。
    daemon:远程调起agent。ultron-server新建压测任务只会在数据库添加一条待运行的压测任务记录,并将空闲agent分配给压测任务,ultron-server本身不负责发压,然后daemon会从数据库读取待运行的任务以及给任务分配好的agent,然后通过shell命令远程调起agent。
    datasource: 即数据源,全链路压测时向agent提供司乘基本信息和路线信息,http日志回放时向agent提供日志日志文件。datasource起了一个定时任务从redis(全链路压测)或者日志文件(http日志回放)读取数据,缓存到内存的队列里面,当压测agent启动后,从datasource的内存队列里面拉取压测数据。
    redisfiller: 将匹配好的路线信息和司乘数据写入redis,供datasource拉取数据用。

流量回放

  • TCPDUMP流量
    因为mock方案,需要保证串行。http:nginx+lua; thrift:server改。选则一台线上机器做串行到tcpdump机器即可
  • 数据iptable劫持
    劫持到proxy转发到mock机器。数据tcp级别的mock。配置白名单iptable不劫持放过
  • mock匹配
    完全串行。1s内单个请求所有子tcp都结束后才记录下一个,直接用时间匹配(tcp级别比如访问redis,mysql无法用traceid等,用线程id各语言不通用)

故障注入

收益

降级预案的有效性:下游依赖出现故障时,预案能及时应对,将系统的 SLA 维持在相对较高的水平,不因下游故障引起当前服务可用性的故障
监控报警:校验报警是否符合预期:是否报警、消息提示是否正确、报警的实效、收到报警的人是否预期
故障复现:故障复盘的后续todo项落地效果如何,通过一定时间后对故障的重现和验证,完成闭环
架构容灾测试:主备切换、负载均衡、流量调度等容灾手段健壮性如何,提前发现并修复可避免的重大问题
参数调优:限流策略、报警阈值、超时设置的调优
故障模型训练:有针对性的制造一些故障,给故障定位系统制造数据

故障全景

1.依赖服务端:故障规则,依赖分析
依赖模型包括关系、流量、强弱三个组成部分:
依赖关系:定义依赖的方向,我依赖谁,谁依赖我
依赖流量:定义每个应用、服务、方法调用的次数
依赖强弱:定义依赖的松紧程度
对依赖的治理就是持续稳定的拿到关系、流量、强弱的数据。
架构拓扑可视化:自动探测应用的拓扑结构,绘制组件间依赖关系和应用对基础架构的依赖
2.依赖插件:
调用拦截,业务识别,注入
结果输出:依赖报表,用例轨迹,插件管理等
https://help.aliyun.com/docum...
3.注入:

  • 应用:外部超时/响应变慢等。接口,DB延迟/连接满/热点,redis缓存热点,kafka,中间件的负载均衡/限流等
  • 资源:cpu,内存,磁盘你,io。网络延时等
  • 程序:cpu,mem,iptable.
    流量劫持,解析,过滤,模拟丢弃和延时和放到目标ip(直接重建socket复制缓冲区),只能针对特定协议做延时和丢弃和转发,和nginx功能差不多,看解析协议的能力了,比如http可以到url的规则,redis可以到命令,thrift可以到xx。nginx增加响应时间插件。
    java:字节注入
  • 注入方式
    隔离环境,复制流量和数据
    影响业务隔离:只影响要发生故障的请求,其他业务流量放过,用中间价摆脱对环境的依赖
    注意混部的影响

服务保护

降级、熔断,服务(1.目前写sdk在代码中读配置直接不发送就返回,分协议处理。2.统一劫持返回)和功能(开关配置)
限流,nginx改;统一入口流量劫持(目前thrift没做,可以和nginx一样令牌桶)
预案管理,开关监控

脚本宝典为你提供优质服务
脚本宝典 » 仿真环境/流量回放/全链路压测/故障注入

发表评论

提供最优质的资源集合

立即查看 了解详情