基于RPC框架的服务端体系化测试方案
如果无法正常显示,请先停止浏览器的去广告插件。
1.
2.
3.
4. O1
背景介绍
O2
RPC测试方案
O3
未来展望
5. 背景介绍
6. 广告投放业务简介
7. 广告投放系统架构
智能算法平台 高并发投送系统 数据高速公路 流式计算平台
前沿机器学习算法的分布式
架构 十毫秒级别的实时决策
百亿次/天的广告投放 内部及外部TB级
数据处理 日志的准实时挖掘与反馈
反作弊与计价
8. 广告投放系统特点
亿级PV
万级QPS
大型分布式系统
高并发
对外为HTTP接口
多模块之间频繁RPC通信
低时延
处理时间<100ms
传输数据量大
链路复杂
复杂的广告系统涉及服务种类多、链路
长、 数据量大,对QA的测试带来了极
大的挑战!
9. 广告投放系统测试难点
测试挑战
02
01
集成测试成本高
1、系统涉及多模
块,每次测试都搭
建所有模块进行联
调测试,成本高,
耗时长
如何高效高质测试?
03
单模块可测性差
1、模块之间通信
使用rpc协议,目前
主流接口测试工具
对rpc协议支持不足
2、模块测试下游
依赖较多,数据变
化带来测试结果的
不可靠
特殊场景覆盖难
1、全链路自动化测试,
覆盖广告类型有限,
验证不全面
2、系统内部大量算法
模型,带来测试结果
不确定性
3、线上海量数据索引,
如何使用线上真实物
料
基于RPC的测试方案!
10. RPC技术介绍
RPC(Remote Procedure Call Protocol)远程过程调用协议。一
个通俗的描述是:客户端在不知道调用细节的情况下,调用
存在于远程计算机上的某个对象,就像调用本地应用程序中
的对象一样。
11. RPC框架解析
接口文件描述层
RPC协议层
网络通信层
GRPC
Protobuf
Thrift
Thrift TCP
BRPC HTTP
TRPC
IDL序列化 + RPC 协议 + 通信协议
12. 主流RPC框架介绍
……
13. RPC测试方案
14. RPC测试方案
接口测试
1
2
自研请求客户端,用于
日常功能测试、开发自
测、上线前回归测试等
MockServer
流量保存
保存海量真实流量在测
试环境中使用,提高测
试场景丰富性与真实性
3
5
Mock依赖服务的返回数据,
降低测试的复杂度
4
Diff测试
通过大量真实请求,对
不同版本/环境下相同
服务回放,用于丰富测
试场景、高效回归测试
性能测试
服务进行极限发压,探测性能瓶颈;
base/test环境对比,发现性能问题
15. 1. RPC接口测试
分布式系统
C
B
A
E
D
pb
pb
请求客户端
消息转码
json
json
pytest+allure
(自动化测试)
参数解析
RPC请求
json
json
手动调用
(手工测试)
16. 1.1 RPC接口测试-请求实现
静态注册 动态反射
代码中定义好请求及返回类型 动态生成请求数据
若接口增加,需要手工编写代码 利用动态编译及反射技术
若接口更改,需要重新编译 只需引用最新proto文件
适合压力测试等高性能要求场景 性能损耗较大
17. 1.2 消息转码-protobuf
// hello.pb.h
class HelloService {
public:
virtual void Hello(Controller*, HelloRequest*,
HelloResponse*, Closure*) = 0;
}
Protocol buffers
// hello.proto
option cc_generic_services = true;
service HelloService {
rpc Hello(HelloRequest)
returns (HelloResponse);
}
protoc
class HelloService_Stub: public HelloService {
public:
HelloService_Stub(Channel*);
void Hello(Controller*, HelloRequest*,
HelloResponse*, Closure*);
}
18. 1.2 消息转码-protobuf
// Person.json
{ "userName": "Martin",
"favoriteNumber": 1337,
"interests":
["daydreaming", "hacking"]
}
// Person.proto
message Person {
required string user_name = 1
optional int64 favorite_num = 2;
repeated string interests = 3;
}
19. 1.2 消息转码-protobuf
protobuf 如何与 json相互转换
Hello
Message
Message Lite
Message Descriptor
GetDescription() filed_count()
GetReflection() filed(int index)
Hello是自定义的pb类型,继承自Message. MessageLite作为Message
基类,更加轻量级一些。
通过Message的两个接口GetDescriptor/GetReflection,可以获取该
类型对应的Descriptor/Reflection
Descriptor
Descriptor是对message类型定义的描述,包括message的名字、
所有字段的描述、原始的proto文件内容等
Reflection
GetInt32(consn Message& message,
const FiledDescriptor* filed)
SetInt32(Message* message, const FiledDescriptor* field,
int32 value)
Reflection
Reflection主要提供了动态读写pb字段的接口,对pb对象的自
动读写主要通过该类完成
对每种类型,Reflection都提供了一个单独的接口用于读写字
段对应的值
20. 1.3 消息转码-Thrift
21. 1.3 消息转码 - Thrift
// Person.json
{ "userName": "Martin",
"favoriteNumber": 1337,
"interests":
["daydreaming", "hacking"]
}
// Person.thrift
struct Person{
1: required string userName,
2: optional i64 favoriteNumber,
3: optional list<string> interests }
22. 2. 流量保存
A
分布式系统
B
自研流量录制代码
测试环境回放脱敏流量
在数据发送/接收处保存流量
C
O
E
F
D
G
H
流量数据(json)
23. 3. RPC Diff测试
分布式系统
分布式系统
A1 ……
pb pb
A2
pb
pb
Diff判断
Diff客户端
消息转码
指定流量
RPC请求
测试报告
多线程发送
参数解析
json
流水线/手工调用
流量数据
……
24. 4. RPC 性能测试
分布式系统
C
B
A
E
D
动态访问指定服务
pb
pb
QPS自行控制,灵活发压
性能指标收集
流量筛选,特定流量持续发压
测试报告自动生成
压测客户端
数据收集
消息转码
指定流量
QPS控制 多线程发送
RPC请求 参数解析
测试报告
json
流水线/手工调用
流量数据
25. 4.1 RPC 性能测试-QPS控制
QPS 尖峰
滑动窗口协议
QPS 平稳
26. 5. RPC MockServer
分布式系统
指定端口启动
A
指定数据返回
通过规则返回
异常数据处理
多线程并发处理
流量转发
E
D
pb
通过指定key返回
C
B
pb
pb
pb
MockServer
流量转发
消息转码
指定端口
协议识别 多线程接收
RPC服务 数据查询
Key
json
手工启动
流量数据
27. 5.1 RPC MockServer-协议识别
id请求的id,目前未使用。
flags本次请求的一些标志符,目前用于传输errorCode。
log-id,本次请求的日志id,服务端用该id定位一个唯一的客户端
请求。
Provider 标识调用方的表示。
magic-number特殊标识,用于标识一个包的完整性
method-id是RPC方法的序列号,根据proto文件中定义的service顺序,
从注册进入的起始值开始依次递增。
body-length消息体长度。
xrpc 协议头
协议头内容可解析出对应的RPC协议!
28. RPC测试方案-落地效果
应用范围广
01
RPC测试方案已经成为广告投放系统测试
的基础服务,覆盖全部微服务接口
落地效果
高效易用
02
测试范围更加精准,测试效率大幅
提高,RD自测比例达到20%
03
可移植性强
面对新模块/新系统,只需少量工作即可
完成适配
29. 未来展望
30. 未来展望
通用化
平台化
智能化
31. 360技术
THANKS
360质量效能