接口优化例子

订单详情优化思路

线上查询订单详情平均耗时 635ms,

线上服务器资源如下:

线上内部的调用链路

从接口层面上分析:

主要耗时的查询在, 查询订单详情: 200+ms, 加上其余的一些查询, 一共是650ms左右

接口返回中的所有的数据都是基于, 订单详情数据库接口来的,

也就是 /orderDetailService/orderDetail (请求数：447821 / 响应时间：230.6ms / 错误数：0), 得获取到该接口的数据才能进行其他数据的组装。

而其余的40多个其他数据接口(查询数据库或者NoSql)平均耗时都在50ms以内, (PS: 有的一些接口是必须符合条件才会去查询)

性能问题在与, 后面的一大堆接口都是串行方式在运行, 一大堆接口串行耗时加起来就是600+ms的

预测的优化目标是, 230ms + 200ms (其他业务处理), 优化该接口响应时间为500ms以内

优化方式:

1. 优先从查询订单详情的接口入手, 看看SQL有没有可能进一步优化, 优化成为200ms内响应
2. 从4核心的服务器资源来看, CPU可利用还能进一步提升, 但需注意别打太满, 以免影响到其他接口的性能
3. 除了基础数据, 其他一些平均50ms内的一定会查询或者查询次数平均较多的, 如果接口之间没有依赖, 可修改为并行方式
4. 或者一些基本不会变动的数据, 使用缓存, 或者一些频繁查询耗时较长的使用缓存, 通过一个基础接口可以判断缓存中的数据是否是最新的, 非最新的重新缓存, 将缓存利用率和命中率提升

根据调用次数可以分为: 一些必定查询的接口, 和一些非必定查询的接口,

测试环境通过 性能分析工具(神器)–XRebel 或者环境部署的skywalking)

环境部署的skywalking

从上面图可以看出主要耗时的方法, 以及远程调用的路径,

也可以看出, 本地运行的web服务远程调用其他服务器的接口, 耗时挺久的 一共需要2秒多,

而在测试环境部署的web服务, 在同一个局域网网络进行远程调用耗时并不会很夸张,

性能瓶颈: 从结果看出, 几十个串行任务, 加起来一共需要这么久, 性能瓶颈在于串行任务太多, 有的查询不太合理,

下面针对上图耗时方法进行优化

优化方式一 (并行, 需注意服务器资源):

针对必定查询的接口, 将数据之间依赖性很少的远程调用(查询数据库)接口, 改为并行, 并且配合配置中心加上开关以便随时可以恢复以前串行的方案

同时可以配合好, 动态刷新配置属性的配置中心来做到, 实时开关并行或者恢复串行

优化方式二: 修改一些多次循环调用的

例如这里线上的, 多次调用获取子任务, 多次获取图片

修改图片为批量查询后的结果:

另一个子任务的批量查询需要别的业务线配合

优化方式三: 缓存

考虑是否可缓存, 图片、问题列表、大数据查询用户指派率、 或者一些不经常修改的数据进行缓存

优化方式四: 减少不必要查询

修改成为, 让前端从列表中取出关键orderFrom参数传过来,

同时兼容其他入口进入的订单详情可以不传, 并且配合配置中心加上开关以便随时可以恢复以前串行的方案

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yn0gQB1I-1666231548436)(https://jiqmwlmd0v.feishu.cn/space/api/box/stream/download/asynccode/?code=NzJiMWQzYmU4MDI5YzA1MTJjMTcyOWFlN2I3Nzc1MmNfOU5kNlhDNmJtdlExT2FUREQ5Zzdxd1R5SENhdjFyaFNfVG9rZW46Ym94Y25yUGRLOEx6YzRJUTRvcXdkekcwc3NkXzE2NjYyMjk3ODU6MTY2NjIzMzM4NV9WNA)]

优化方式五: 将一些重复查询调用的结果重复使用

优化方式六: 将一些已经暂停使用的业务加上条件是否查询调用

使用这个优化方式, 最好配合配置中心@Value("${not.query.prepareDetail:true}")一起使用,

可以通过修改配置属性变成立即恢复原来未优化逻辑

优化方式七: 将没有依赖的数据查询拆出来成为接口让前端异步调用

到此优化方案暂时结束

注意使用异步进行优化时候, 需要注解别共用公共线程池、 如果需要立即响应的功能, 选择不存储任务队列, 拒绝策略走调用者执行

补充优化上线后的结果:

还有个前端增加传递参数的没上, 即优化方式四, 前端上线增加传递参数后, 大概还能少30ms左右

1