2017年基于流量回放技术进行中台建设.pdf

《2017年基于流量回放技术进行中台建设.pdf》由会员分享，可在线阅读，更多相关《2017年基于流量回放技术进行中台建设.pdf（37页珍藏版）》请在三个皮匠报告上搜索。

1、MORE THAN A JOURNEY基于流量回放技术进行中台建设现有方案新方案010203挑战展望04挑战CHAPTER 1MORE THAN A JOURNEY公司简介MORE THAN A JOURNEYMORE THAN A JOURNEY出行平台中台化快车拼车专车巴西出行中台十多个大产品数百种细分场景挂一漏万中台化现有方案CHAPTER 2MORE THAN A JOURNEYlogicservicelogicservicelogicservicestatestatestate测试脚本测试边界划分边界划分的大1、依赖的state多2、掉链子的模块多带来问题定位困难集成的bug多于模块

2、自身的bug手写自动化测试MORE THAN A JOURNEYlogicservicelogicservicelogicservicestatestatestate测试脚本测试边界划分边界划分的小1、一堆依赖的服务需要mock2、内部服务之间的交互不是稳定的系统边界，经常调整，写新功能先要修复一堆挂掉的测试手写自动化测试MORE THAN A JOURNEY旧系统新系统日志日志小流量1、流量覆盖不到的，测试也覆盖不到2、切流过程出问题对用户有损3、迭代速度受到上线周期的巨大影响4、双写或者双读比对期间额外消耗资源双写双读，日志比对，灰度切流新方案CHAPTER 3MORE THAN A JO

3、URNEY生产环境流量录制开发环境回放并且比对录制流量和回放结果的diff录制的流量相当于手写的带mock的单元测试脚本用流量生成测试用例MORE THAN A JOURNEY插入点怎么搞，是要业务接入特殊的rpc sdk么？并行的请求处理过程，如何抽取出一个完整的处理过程？怎么区分外部进来的请求，和访问rpc获得的response？请求与请求之间怎么切分开来，难道要解析http协议么？回放的时候怎么实现mock，如何知道这次请求过来返回什么？业务要是和时间相关呢？怎么diff回放结果，线下肯定和线上有很多差异啊？对重构可能有一点点用，做新需求开发帮助不大吧？为什么流量录制和回放没有普及MOR

4、E THAN A JOURNEY录制回放的整体流程录制回放比对录制的流量回放结果MORE THAN A JOURNEY录制录制回放比对录制的流量回放结果MORE THAN A JOURNEY录制的结果Inbound requestInbound responseCall outbound:request+responseAppend fileSend UDPActionsSessionRPC 请求Read storageMORE THAN A JOURNEY录制要解决的问题MORE THAN A JOURNEY串行录制MORE THAN A JOURNEY绝大部分业务逻辑在一个线程内串行执行通

5、过 thread 来关联 inbound/outbound比手工传递 trace_id 更容易并行录制MORE THAN A JOURNEY太靠下了，线程信息就丢失了越靠上越多元化，适配的成本越高尽量做到语言无关，框架无关LD_PRELOAD=boss_recorder.so./server-start.sh MORE THAN A JOURNEY请求响应请求依赖时序来识别下一个请求的开始数据流尽量做到协议无关MORE THAN A JOURNEY回放录制回放比对录制的流量回放结果MORE THAN A JOURNEY开发人员如何使用MORE THAN A JOURNEYmock重定向Syst

6、em Under TestredisOutboundInboundLibcConnect()发起回放MORE THAN A JOURNEY切分成16bytes chunksByte数组按完全相同的chunk数进行打分mock请求匹配实现MORE THAN A JOURNEY剧本的传递，结果的收集MORE THAN A JOURNEY比对录制回放比对录制的流量回放结果MORE THAN A JOURNEY展望CHAPTER 4MORE THAN A JOURNEY业务代码业务代码基础代码“过去的”流量没有的，就测不到