【3.工程开发】-仿真环境/流量回放/全链路压测/故障注入

本文涉及工程中测试/稳定性相关的一些内容，全文见：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层)抓包

  
  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
• 总体架构

  
  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同样令牌桶)
预案管理，开关监控