微服务架构 前后端交互优化 上篇
传统前后端交互结构如下:
如图所示前后端耦合一起,交互方式http+jsp+js,静态资源和业务代码统一存放同工程,同台服务器部署,服务器接收到浏览器的请求后,进行业务处理返回页面,页面渲染,最终返回给浏览器
用户流量增加后存在以下问题
- 页面和业务逻辑同工程,分解压力变小
- 同服务器部署,服务器性能有瓶颈
- jsp页面获取数据后需要编译,性能差
- 无法横向扩展,不支持高可用
- 页面渲染速度缓慢,用户体验差
由于传统交互结构不能满足用户体验,需要重新定义前后端交互方式
采用前后端分离方式 (h5+http json) 交互可提高用户体验
结构视图如下:
如图所示,前后端分离优势如下:
- 前后端解耦,分开部署编译打包
- h5静态页面存放cdn加速渲染
- h5可部署多份,负载均衡
- h5和后端可并行开发,mock数据 提高开发效率
- h5可打包、拆包、压缩容量,提供轻量级
- 服务端专注于数据处理返回
很多互联网公司为了提高页面渲染速度,从传统前后端交互脱离 变为 前后端分离交互方式,可见这是一种趋势。
前后端分离交互步骤如下
- 目前主流前端框架(vue、react、angular)和后端约定数据传输格式 如(json、xml)
- 约定请求类型(POST、GET)、请求入参、请求出参
- 可提前书写接口文档或 引入Swagger自动生成接口文档
- 针对特殊业务场景,如扫码登录,需要使用特殊请求方式,如 长链接、轮询、重试
交互性能优化思路
- 简单查询使用Get请求、复杂查询、增删改使用Post请求
- 页面作用于CDN上,加速请求
- 全局请求拦截,增加head头部,签名认证
- 大数据量获取请求分批次,分多次请求
- 服务端热点数据读取缓存
- 服务端文件写入、导出功能单独转发
- 服务端返回body字节压缩
- 服务端异步处理请求返回
优化说明如下
- 由于GET、POST请求方式传输不同,GET容易受攻击、POST请求会预检请求,是否支持跨域通过后才提交数据
- 作用于CDN上,静态资源不需要每次下载,读本地缓存,如304 cache
- 前后端签名认证(jwt)
- 服务器返回大数据量会影响 网络带宽和 解析读取能力,分批次获取可缓解压力
- 服务端走缓存提高查询效率(redis、ehcache)
- 导入、导出功能由数据量大 IO、内存开销大,需单独指向某台服务器处理不影响主应用流程(F5/NGINX指定url分流)
- 服务端返回数据可经过压缩返回
- 服务端非实时场地业务可用mq消息异步处理,提高吞吐量(rocketmq)
以下针对服务端数据返回压缩优化进行实例讲解
以上视图是未优化场景下,获取省市区数据,尽管页面第一次获取成功后缓存本地cache,但由于数据量大,请求时效长达 1.3s,大小 327KB,通过分析可发现此请求接口存在性能问题,正常接口均在50-300ms之内,大小在50KB以内,需要进行优化
优化思路
- 省市区数据量大,可否拆开成3份数据,分别获取省、市、区数据,提高数据传输、加快渲染速度
- 可否针对省市区数据压缩后进行返回客户端
优化步骤
-
打开tomcat-server.xml,找到运行端口 如 <Connector port=“9021”
-
新增属性 compressableMimeType=“application/json,application/x-javascript,application/javascript,
text/html,text/plain,text/javascript,image/gif,image/x-icon,image/png,
image/gif,text/css,image/jpeg,audio/mpeg,video/mp4,application/x-font-ttf,application/x-font-otf,
image/svg+xml” (需要压缩的response类型)
新增属性 compressionMinSize=“6144” 默认2048/2k (超过这个大小进行压缩)
新增属性 compression=“on” 启动压缩功能,会影响部分服务器CPU资源
从上面的截图中优化后结果可以得出如下关键信息点: -
省市区耗时缩短,从1.3s —> 231ms
-
省市区大小减少 从327kb —> 50.6kb
结果分析
- 分别请求省、市、区数据是能提高数据传输、加快渲染速度,但可能会频繁请求接口导致服务端压力,本地缓存后数据需更新时繁琐
- 数据压缩后,网络传输加快,本地缓存数据
Web缓存优化、HTTP请求加速、多请求优化、页面渲染优化等见下篇文章