项目重构总结

正值测试阶段，抽时间做一次总结。

由于历史原因，部门的技术栈相对落后且不统一，ng1、react、vue、node、甚至jsp等前后端不分离的比比皆是。但没办法啊，毕竟业务驱动，重构、追赶新技术是需要很大成本的。

米币支付这个项目之前就是前后端不分离的，这次他们希望沿用之前的技术减少时间和人力成本，毕竟前后端分离接口都得改。那我不干啊，好不容易重构了，不向前兼容，怎么还后退了呢。据理力争，找接口协商，最后接口可以完全抽出一个人力配合，才同意前后端分离。本来想采用vue + ts的，但ts被否决了，理由是组内还没有ts的项目，怕后期的维护成本加大，行吧，咱也退一步。

说实话，现在很不屑于做这种项目，没有任何技术难点，没有任何挑战。但没办法，这就是你的工作。

一个多月时间，从项目架构、开发、多语言、CI/CD，错误上报/性能监控全流程搞了一遍，也算摸清了公司的流程。

更细节的内容在组内做了次分享，由于我司对信息安全这一块查的很严，也就不提了。

下面主要说做的性能优化吧，毕竟面试也会关注这一点（有句话：你在这家公司所做的一切都是为下次跳槽做准备），没有实际经验，单靠八股文还是心虚呀。

1. 代码切割，减小包体积。html中prefetch

2. 合并小文件，减少请求次数

小文件合并使用 webpackChunkName 注释， 同名的就会合成一个文件

• 合并前

• js

image.png

• css

  
  image (1).png

打包后发现有不少几kb的文件，可以将它们合并成一个，以空间换取时间。

合并之后

image (2).png image (3).png

3. Gzip 压缩

下面全是Nginx配置。

1. nginx 开启压缩

server {
  # 开启gzip 压缩 on 开启；off关闭*
  gzip on;
}

压缩前：

image (4).png

注意：Nginx没有压缩过的文件，ETag的值是没有 W/ 前缀的。即便返回的是前端提供的静态gzip文件，也是没有前缀的。

压缩后：

1.png

由Nginx压缩是需要消耗时间和性能的，可以前端进行压缩，然后配置Nginx。

2. 前端打包Gzip文件

• 安装插件 compression-webpack-plugin

  warn: 打包时报以下错误，降低插件的版本即可。（我是从最新版的7.1.2降低到5.0.2）

  
  7b27771d-3345-4ec1-922c-af583fec101a.png

• 配置

• 打包

webpack 压缩前后，生成的.gz文件

2.png

部署到nginx上。配置nginx，nginx会优先返回资源目录下存在的.gz文件

gzip_static on;

配置以后我怎么知道返回的压缩文件是由nginx返回的还是前端打包好的呢？

第一步介绍过前端没有打包生成gzip文件之前，由nginx压缩的文件的ETag具有/W前缀。

直接返回前端生成的压缩文件，ETag没有 /W前缀。

3.png

3. nginx配置

下面是Nginx的配置和说明。

server {
    # 开启gzip 压缩 on 开启；off关闭
    gzip on;
  
    # 检查是否存在请求静态文件的gz结尾的文件，如果有则直接返回该gz文件内容，不存在则先压缩再返回
    gzip_static on;
  
    # 压缩阈值 单位：字节 （从header头中的Content-Length中进行获取。）
    # 默认值是0 （即：都进行压缩）
    # 建议设置成大于10k的字节数，配合compression-webpack-plugin
    gzip_min_length 10k;
  
    # 对特定的MIME类型生效,其中'text/html’被系统强制启用
    gzip_types text/javascript application/javascript text/css application/json;
  
    # Nginx作为反向代理的时候启用，开启或者关闭后端服务器返回的结果
    # 匹配的前提是后端服务器必须要返回包含"Via"的 header头
    # off(关闭所有代理结果的数据的压缩)
    # expired(启用压缩,如果header头中包括"Expires"头信息)
    # no-cache(启用压缩,header头中包含"Cache-Control:no-cache")
    # no-store(启用压缩,header头中包含"Cache-Control:no-store")
    # private(启用压缩,header头中包含"Cache-Control:private")
    # no_last_modefied(启用压缩,header头中不包含"Last-Modified")
    # no_etag(启用压缩,如果header头中不包含"Etag"头信息)*
    # auth(启用压缩,如果header头中包含"Authorization"头信息)*
    # any - 无条件启用压缩
    gzip_proxied any;
  
    # 请求加个 vary头，给代理服务器用的，有的浏览器支持压缩，有的不支持，所以避免浪费不支持的也压缩
    gzip_vary on;
  
    # 越小压缩效果越差，但是越大处理越慢，一般取中间值
    gzip_comp_level 6;
  
    listen    80;
    server_name  m.staging.mibi.n.xiaomi.com;
    
    # html 文件
    location /dist {
      alias mibi;
      index  index.html index.htm;
    
      # 对于在地址栏直接访问 m.staging.mibi.n.xiaomi.com/dist/record/XXX**之类的路由
      # nginx在查找时就回去mibi下的record目录下找，显然没有，就会返回404
      # 所以需要配置nginx 找不到的一律打到mibi 下的index.html上，剩下的路由匹配就由前端接管处理了。
      # 解析：先根据地址找对应的文件，找不到再试探地址对应的目录，再找不到就返回 /dist/index.html
      try_files $uri $uri/ /dist/index.html;
    }
    
    # 静态资源
    location /assets {
      alias mibi;
    }
    # 接口映射
    location / {
      proxy_set_header Host $host;
      proxy_pass http://120.92.35.3:80/;
    }
    #error_page  404        /404.html;
    # redirect server error pages to the static page /50x.html
    #
    error_page  500 502 503 504  /50x.html;
    location = /50x.html {
      root  html;
    }
  }

因为支付涉及到很多调用方，需要兼容已有的地址，所有路径前缀和资源前缀不一致。关于路径前缀配置在vue-router中配置base即可。资源前缀在webpack中配置publicPath。而静态资源都放在服务器的mibi目录下，所以就会有上面html和静态资源的配置不一样的情况。

接口映射是因为前后端分离后，分开部署，所以接口需要做一次转发。

4. HTTP缓存

HTTP缓存是性能优化很重要的手段之一。

现在的项目一般都是SPA（多页面也一样），编译打包后生成的静态资源名都带有hash值。所以把html设置成协商缓存。如果资源内容改变，生成新的hash值，资源URL自然也变了，所以js、css、img等设置成强缓存。缓存有效期可以很长，但是也不要太久，一般30天，不然假如频繁更新前端资源，废弃的资源将一直存留在用户的磁盘，会搞死用户的。

 # 缓存配置
 # html配置
  location = /index.html {
    add_header Cache-Control no-cache;
  }
   # js/css配置。一般设置成30d。因为打包后文件名都是hash 缓存时间设置的太长，更新后不再使用的资源会一直占用用户的磁盘
  location ~ /(js/\*|css/\*|img/\*|font/\*) {
    expires 30d;
    add_header Cache-Control public;
  }

4.图片和字体图标

1. 图片不需要压缩，一方面我用熊猫压缩过了，另一方面图片自身已经做了最优化，压缩后反而大了
2. 格式为eot和ttf的字体图标可以进行压缩，效果还可以，而woff格式的，因为CompressionWebpackPlugin插件不支持压缩，即使配置了也没用。

以上就是本次项目做的一点性能优化。