这是我参与「第五届青训营」笔记创作活动的第17天。
今天主要针对大项目已经实现的东西进行复盘，并对功能测试做出详解。
功能测试
测试用例表格
功能验收清单中包含了抖音项目方案中提及的各个模块功能。主要测试了主要业务流程，一些较复杂链路（如多次点赞取消点赞查看点赞登录用户总数等）虽然没有写在测试用例中，但也在实际开发中进行了测试。
链路追踪
微服务调用关系图：
链路调用时间图（一小时内，为了方便观察只调用了用户信息）：
一次用户信息调用的链路耗时详情：
性能测试
测试准备
测试环境：
- （x86_64 AMD 8核16线程）
- 微服务通过分配端口运行在同一主机下
- 数据库，缓存，MQ，链路追踪通过 docker 运行在同一主机下
测试方案：
- 使用 Hertz 提供的 pprof 扩展，对 Hertz 项目进行性能分析（通过火焰图分析 CPU 使用情况）；
- 利用 Apifox 自动化测试模块书写测试用例和测试套件，根据多次循环得到较平稳的延迟时间，生成测试结果；
- 利用 Jemeter 测试多并发场景下的接口性能情况。
测试结果
*注：测试时间有限，这里仅针对部分场景和链路进行了测试。
基准测试
接口（功能）测试：
混合测试：
并发测试
在并发测试中，我们优先处理上述基准测试中响应最慢，数据最多，但同时也是最核心的视频流部分：
我们以3000毫秒为阙值，观察并发量上限：
| 样本 | 平均 | 最短 | 最长 | |
|---|---|---|---|---|
| 视频流接口 | 100 | 2896 | 2527 | 3163 |
测试结果表明，在并发量到达 50 的时候会接近 3000 响应延时。
如果在高并发情况下，当前服务器配置和服务处理方案是不够用的。需要进行优化（详情见 4.3）
负载测试 / 压力测试
以用户登录 + 查看信息业务链路为例：
对应响应时间测试结果如下：
修改上述配置，长时间压力测试（100分钟，固定20并发）：
对应pprof火焰图如下：
可以看到，大部分的 CPU 占用都在主要业务上，同时还有部分 CPU 占用在 jaeger 链路追踪。考虑到资源利用问题，可以在上线版本优化 jaeger 链路追踪。
性能优化
热门视频优化
短视频app最核心的部分便是视频流的获取，但是目前我们的项目视频流获取响应比较慢。主要原因在于视频流涉及到的业务模块和响应记录链路长度较长，容易产生更多的记录查询：
*tips: 以上为 2 -> 30 并发量步进。
由于微服务粒度较细，这里的视频流请求时会分别去调用用户，评论，点赞等多个微服务获取数据。
我们可以采取对热门服务（这里的热门服务定义需要通过合理的决策和规则。这里假设一个视频在 ns 内访问了100次以上，那么我们称该视频为热门视频一段时间）进行缓冲来优化响应。目前采用缓冲策略为加入到 Redis 中。
由于在进行压力测试时请求参数没有设置变量，所以响应变化曲线尤为明显：
可以看出，当视频被识别为热门视频后，其响应速度立刻提升。
发送聊天信息优化
我们对聊天消息进行并发测试：
| 总体 | 测试背景 | 样本 | 平均响应 | 异常% |
|---|---|---|---|---|
| 1 | 25并发，100线程数，2s完成，循环 | 8007 | 226 | 0% |
| 2 | 50并发，250线程数，5s完成，循环 | 17226 | 399 | 0% |
| 3 | 500并发，2500线程数，5s完成 | 2500 | 628 | 0% |
| 4 | 1000并发，5000线程，5s完成 | 5000 | 5571 | 0.48% |
| 5 | 100并发，5000线程，5s完成 | 5000 | 7025 | 0% |
这里可以看到，当我们高并发发送信息时，可能会导致响应时间急速上升，并且出现异常量。
我们这里可以使用 RoketMQ 集群来处理高并发场景。
同样是处理 1000并发，5000线程，5s完成 的场景，我们加入 RocketMQ 进行削峰处理，并且加入出错后重新消费机制。
观察此时的汇总报告：
响应折线图：
可以看到这里的响应时间降低，使得网关层可以迅速应付高流量，而在消息队列做平滑处理。
*tips: 在高并发场景下，服务收到的请求数会缺失，导致最终的数据库添加条数少于5000，问题来源还在探究。
