分布式架构 前后端交互优化 上篇

传统前后端交互结构如下：

如图所示前后端耦合一起，交互方式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请求加速、多请求优化、页面渲染优化等见下篇文章