前端路由服务及CI/CD流程

背景

公司各团队管理本身的项目，分别有卖家中心、管理中心、商城、h五、...等项目。项目多达40+个。须要统一规划配置项目对应的路由、构建后静态资源存放地址。

前端页面渲染过程

浏览器输入url请求页面，通过路由服务，根据路由配置去拉取OSS上相应的index.html

前端项目CI/CD、请求页面到渲染，都会根据路由服务中的路由配置，结构以下：

[
   {
      "gitRepo": "cassfrontend/seller-merchant-react", // 项目仓库地址
      "cdnRoot": "/www/seller/merchant", // 构建后项目CDN存放目录
      "url": ["/seller/merchant"] // 浏览器请求的url
   },
   {
      "gitRepo": "cassfrontend/seller-test-react",
      "cdnRoot": "/www/seller/test",
      "url": ["/any/path", "/alias/path"]
   }
]

为何路由服务在返回index.html以前须要改写PUBLIC_PATH呢？

由于生产构建时设置静态资源引用路径是'./'，相对于当前路径获取静态资源，根据上图描述也就是https://ec-test.casstime.com/seller/merchant/目录，可是/seller/merchant项目构建后存放的目录是/seller/merchant/prod/，域名也不同，应该是OSS的域名https://mstatic.cassmall.com。所以，路须要改写PUBLIC_PATH，向OSS请求静态资源。

webpack支持动态PUBLIC_PATH，在项目主入口文件index.ts中引入import './public-path';

// public-path.ts

declare var __webpack_public_path__: string;

__webpack_public_path__ = (window as any).__PUBLIC_PATH as string;

export default __webpack_public_path__;

路由服务返回index.html，向其中注入script脚本设置window.__PUBLIC_PATH = "xxx"

<!-- index.html 处理前 -->
<script src="/js/main.54b2835a.chunk.js"></script>

<!-- index.html 处理后 -->
<script>
window.__PUBLIC_PATH = "https://mstatic.cassmall.com/admin/merchant/prod/"
</script>
<script src="https://mstatic.cassmall.com/admin/merchant/prod/js/main.54b2835a.chunk.js"></script>

页面加载具体流程

部署及回滚方案

一、发布前端项目时，采用非覆盖式发布。每次构建后，入口文件index.html 按版本号复制一份。CDN目录结构以下：

/seller/merchant/prod
   css
   js/
       main.fade23.js
       main.aeb3ef.js
   index.html
   index-v2.0.0.html
   index-v1.0.0.html

二、每一个项目能够配置惟一的目录（cdnRoot），不一样环境的静态文件部署到cdnRoot对应的子目录中。

环境	目录
灾备环境	${cdnRoot}/backup/
演示环境	${cdnRoot}/demo/
生产环境	${cdnRoot}/prod/
测试环境	${cdnRoot}/test/

三、构建/发布示意图以下:

四、须要回滚到指定版本时，只须要将对应版本的html重命名为 index.html 便可快速回滚，回滚示意图以下：

解决了哪些问题

• 路由服务业务逻辑简单，但区分 admin、seller，须要为每一个项目单独编写路由，配置复杂。
• 部署目录不规范，项目多后很差管理
• 不一样环境的公共路径（publicPath）不一致，致使在不一样的环境须要单独构建。有可能存在测试环境和线上环境代码不一致的问题。
• 构建和发布在同一个流水线，存在外部环境影响构建结果的风险。
• 当回滚静态资源时，须要从新构建。

Q&A

• 为何忽略路由缓存

  内网获取OSS页面很是快（10ms内），并且页面请求量不会特别高（单页应用，应用内【项目内】切换页面不会刷新），不必作太复杂的缓存，缓存只做为容错的补救措施。

• 为何再也不构建时触发更新

  这种操做加大CI复杂度，发布的同时更新路由配置关系（Redis），系统变得复杂。路由服务但愿像通常反向代理同样，文件变化了，就给前端返回变化后的文件。文件自己的变化能够经过 HTTP 304 机制优化。