记一次关于服务端接口问题优化全流程

产品上线以来一直以来都收到很多用户反馈开关机缓慢问题。我们也知道问题所在是因为我们产品涉及到的最底层调度是第三方提供的。而在加上第三方调用链路过长所以导致我们的链路非常长。
开机要经过链路。 客户端发起请求-》后台接收信息向底层平台发起请求-》底层平台接收到信息执行-》执行成功返回信息-》后台接收信息向前端推送 -》前端展示开机成功

这个链路非常的长同时执行时间非常的长。我作为测试在阅读后台代码和后台日志发现我们在自身服务上发现我们本身在程序内部执行需要等待非常久。需要一直有进程在等待底层的执行结果。有结果再返回前端。这样会给用户一直等待的感觉。

第一次优化：因此我提出我们引用异步操作的方法。当我们调用底层平台成功后先返回 开机中 给用户。让用户不会一直等待。真正的开机状态我们则以socket进行推送。当我们推出这套方案时外网用户的反馈量降低了20%

第二次优化：但是用户还是反馈速度慢。我们继续做优化。我去查服务端日志发现我们的底层执行成功了。但是服务端并没有立刻向前端推送消息。和后台同学沟通后知道。我们判断开机是否成功是通过轮询zstack平台知道的机器开机状态。轮询是有间隔的。所以我们的轮询相当于浪费了部分时间。因此和后台同学沟通。开机成功的消息我们用线程管理。只要有开机的就会一直轮询。这样我们就不会有开机的浪费时间。 用了这个方案后我们在轮询阶段的时间平均减少了6秒。
缺点：
但是我们还有很多需要改进的地方。例如有一定量级的用户进行开机。轮询服务产生的请求量就会很大。

收获：
第一次尝试通过服务端日志和后台代码一步步分析可以优化的点。同时推动后台来参与优化。和项目沟通优化的时间和人力。把这次接口优化的影响点和需要的人和项目沟通清楚。把这次优化当作技术需求来做。