网络优化篇-如何大幅度提升端上性能

日期:2019-08-10 08:19:32 作者: 浏览: 查看评论 加入收藏

   DNS解析快么?在网络优化篇-从DNS开始 这篇文章中,已经分析过DNS解析了,事实证明,DNS解析是漫长的,尤其在端上,有时长达几百ms。

       三次握手快么?快,也不快。你想想,即使是在有连接池优化的前提下,整个应用的生命周期内还是要经过无数次三次握手,那么,最好的方式是什么呢?一次连接,到处使用

       序列化、反序列化、包压缩暂时不在我们今天的考虑范围内。

成功率为什么低

       端上的网络请求难免遇到超时,连接失败,IO异常,DNS解析异常等等多种错误情况。当你在遇到这些情况时,没有补救措施,当然成功率低了。

引入长链接

       在知道了种种原因之后,我们引入了长链接。将网络请求通过长链接发送到后端gateway,后端gateway进行转发即可。以OkHttp为例,我们可以很轻松的使用拦截器,将网络请求拦截下来,然后通过长链接发送出去。需要注意的是,这个拦截器要加在ConnectInterceptor之前

这是一个转换器接口的例子,功能是将Http协议的Request转换为长链协议的Request,将长链协议的Response转化为Http协议的Response。

  •  
  •  
  •  
  •  
  •  
  •  
public interface CoreConvert<U, D> {
  CoreHttpRequest convertToU(U request);
  D convertToD(U request, CoreHttpResponse response);}

       做了这些就够了么?不够,远远不够,我们还需要做两件事。1. 互备 2. 动态调整。

长链接和Http互相兜底

       谁都无法保证长链接一定可靠,也无法保证http短链接可靠。因此,我们还需要做的是,当一种链路出现问题的时候,切换到另一种链路重试一下。这样,可以减少失败率,通过这种方式,我们端上的成功率从92%提升到了99%+,提升非常明显

动态调整

       那么,这里指的动态调整是什么呢?虽然我们引入了长链接,理论上长链接要比http短链接快很多,但是,事实却不一定是这个样子。所谓的动态调整,指的是我们不断的通过相应时间去分析出长链接和短链接的质量,然后选择让api请求走短链接还是长链接。通过这样不断的调整,能够帮助我们在链路选择上,自动调度到比较好的链路中,提升网络质量。

最后

整篇下来,可能理论偏多,但是这一套理论已经在我们目前的端上验证了很长时间,事实证明,是可行的。并且改造成本不高,对业务无感知,零侵入。

支付宝转账赞助

支付宝扫一扫赞助

微信转账赞助

微信扫一扫赞助

留言与评论(共有 0 条评论)
   
验证码: