GITC 2017全球互联网技术大会 北京站

质量&测试 陶文-基于流量回放技术进行中台建设

滴滴的出行平台支持了快车、专车、拼车等多个产品线,逻辑复杂度非常高,同时对稳定性要求也非常高。中台化的目标是在原本一套的系统中切分出比较明显的前台和中台的系统边界。如何在这样的约束条件下进行无损的架构调整是非常大的难题。经过一段时间的探索,RD和QA共建了一套“月光宝盒”的辅助系统。通过对生产环境进行流量录制,然后在开发环境进行回放,有效保障了重构工作的质量。

1. 基于流量回放技术 进行中台建设 taowen@didichuxing.c om MORE THAN A JOURNEY
2. 01 挑战 02 现有方案 03 新方案 04 展望
3. CHAPTER 1 挑战
4. 公司简介 MORE THAN A JOURNEY
5. MORE THAN A JOURNEY
6. 中台化 出行平台 MORE THAN A JOURNEY 十多个大产品 数百种细分场景 挂一漏万 中台化 出行中台 快车 拼车 专车 巴西
7. CHAPTER 2 现有方案
8. 手写自动化测试 测试 脚本 MORE THAN A JOURNEY 测试边界划分 logic service logic service logic service state state state 边界划分的大 1、依赖的state多 2、掉链子的模块多 带来问题定位困难 集成的bug多于模块自身的bug
9. 手写自动化测试 测试 脚本 MORE THAN A JOURNEY 测试边界划分 logic service logic service logic service state state state 边界划分的小 1、一堆依赖的服务需要mock 2、内部服务之间的交互不是 稳定的系统边界,经常调整, 写新功能先要修复一堆挂掉的测试
10. 双写双读,日志比对,灰度切流 旧系统 日志 小流量 新系统 日志 1、流量覆盖不到的,测试也覆盖不到 2、切流过程出问题对用户有损 3、迭代速度受到上线周期的巨大影响 4、双写或者双读比对期间额外消耗资源 MORE THAN A JOURNEY
11. CHAPTER 3 新方案
12. 用流量生成测试用例 生产环境 录制 MORE THAN A JOURNEY 开发环境 流量 回放 并且比对录制流量和回放结果的diff 录制的流量 相当于手写的带mock的单元测试脚本
13. 为什么流量录制和回放没有普及 • 插入点怎么搞,是要业务接入特殊的rpc sdk么? • 并行的请求处理过程,如何抽取出一个完整的处理过程? • 怎么区分外部进来的请求,和访问rpc获得的response? • 请求与请求之间怎么切分开来,难道要解析http协议么? • 回放的时候怎么实现mock,如何知道这次请求过来返回什么? • 业务要是和时间相关呢? • 怎么diff回放结果,线下肯定和线上有很多差异啊? • 对重构可能有一点点用,做新需求开发帮助不大吧? MORE THAN A JOURNEY
14. 录制回放的整体流程 录制 回放 比对 录制的流量 回放结果 MORE THAN A JOURNEY
15. 录制 录制 回放 比对 录制的流量 回放结果 MORE THAN A JOURNEY
16. 录制的结果 RPC 请求 Inbound request Session Call outbound: request + response Append file Send UDP Read storage Inbound response MORE THAN A JOURNEY Actions
17. 录制要解决的问题 MORE THAN A JOURNEY
18. 串行录制 MORE THAN A JOURNEY
19. 并行录制 MORE THAN A JOURNEY 绝大部分业务逻辑在一个线程内串行执行 通过 thread 来关联 inbound / outbound 比手工传递 trace_id 更容易
20. 尽量做到语言无关,框架无关 MORE THAN A JOURNEY 越靠上越多元化,适配的成本越高 LD_PRELOAD=boss_recorder.so ./server-start.sh 太靠下了,线程信息就丢失了
21. 尽量做到协议无关 数据流 MORE THAN A JOURNEY 请求 响应 请求 依赖时序来识别 下一个请求的开始
22. 回放 录制 回放 比对 录制的流量 回放结果 MORE THAN A JOURNEY
23. 开发人员如何使用 MORE THAN A JOURNEY
24. mock重定向 发起回放 Inbound System Under Test Outbound Libc Connect() redis MORE THAN A JOURNEY
25. mock请求匹配实现 Byte数组 切分成16bytes chunks MORE THAN A JOURNEY 按完全相同的chunk数进行打分
26. 剧本的传递,结果的收集 MORE THAN A JOURNEY
27. 比对 录制 回放 比对 录制的流量 回放结果 MORE THAN A JOURNEY
28. MORE THAN A JOURNEY
29. CHAPTER 4 展望
30. 成也流量,败也流量 业务代码 MORE THAN A JOURNEY 业务代码 基础代码 “过去的”流量没有的,就测不到 … 基础代码无法预测所有的用户,以及上层的行为 无法判断漏测带来的风险级别
31. 模糊的问题,模糊来解 确定性的业务代码 依赖过去的流量回放 不确定的基础代码 依赖手工脚本加 随机数据生成 业务代码 构造随机流量 github.com/google/gofuzz github.com/json-iterator/go 基础代码 MORE THAN A JOURNEY
32. 基于mock的测试 logic1 logic2 state Mock logic2 测试logic1 MORE THAN A JOURNEY 两个缺点 1、只能测试一个进程内的逻辑,无法跨进程组合测试 2、mock 不如基于 state 的测试真实
33. 基于状态的测试 logic1 logic2 state Mock logic2 测试logic1 MORE THAN A JOURNEY logic1 logic2 state 构造state 测试 logic1 + logic2
34. state 就是那些“免测”的叶子系统 logic1 logic2 state Mock logic2 测试logic1 MORE THAN A JOURNEY logic1 logic2 state 构造state 测试 logic1 + logic2 logic1 logic2 state 构造 logic2+state 测试 logic1
35. 集成测试:系统级流量回放 logic service logic service logic service 通过服务标准化(包管理+docker+服务注册发现) 解决服务组装问题 对状态的依赖成为最大难点 state MORE THAN A JOURNEY state state
36. 流量录制是未来的发展方向 偏用户侧:流量回放 偏底层:“随机”生成流量 MORE THAN A JOURNEY state 整体: 用录制的流量 构造state 集成测试逻辑
37. Q/A 如对滴滴平台技术部的机会感兴趣,请发送简历至我们的招聘HR maosanyan@didichuxing.com ,或加微信&电话联系(18910686942)。
38. thread id v.s. trace id 线程1 线程2 线程1 线程2 一个线程下可能发起多次rpc 基于 trace_id 进行传递 需要遍历所有的rpc调用处,容易遗漏 MORE THAN A JOURNEY 关联线程之间的“委托关系” 需要关注的地方更少