# SPA应用自动化部署_架构
昨天提了离职，今天本来是要开始交接工作的，但是跟我对接的人请假了。趁着这个空档，我捋了下我们的前端SPA应用的部署和管理方式。在此之前谈谈我认为的，理想的前端工程化的基础服务应该包含哪些东西：
- 脚手架创建项目
- 自动配置好开发 构建 上报 部署脚本 一系列东西
- 然后上报内容会加上 依赖库、构建的一些情况
- 平台按项目划分 每个项目分为项目基础、构建报告、单测报告、页面测试以及性能数据（白屏时间 网络加载情况）
- 还有预警 比如构建体积过大、构建时间突增、用了过期的库等等
# Version Ⅰ
为了表达得清楚，我画了思维导图：
# 说明
访问过程：浏览器请求Nginxweb服务器，Nginx经过负载权衡，转发请求至某一台java服务器，java请求我们的文件服务器即Projects Manager得到文件服务器指定的资源CDN地址，然后用Thymeleaf渲染最新的资源链接到模板html上。然后把完整的html交给浏览器。浏览器开始dom解析，遇到script标签包裹的资源链接请求CDN服务器得到前端js/css资源。
优势：
- 由于用户访问时，
java服务是实时获取的Projects Manager指定的前端资源，如果出现线上前端bug，前端开发在修复好后，可以直接打包上传到cdn，然后去Projects Manager的后台管理系统上，设置刚刚修复bug打包的资源为线上资源，线上bug就修复掉了。比起曾经需要长时间发布庞大的java项目，明显提高了修复效率以及减少了宕机风险。 - 每个前端项目都分配有一个id,
Projects Manager可以统一管理大量前端项目静态资源。
劣势
- 前端项目固定在了指定
java项目中，造成请求其他java服务有跨域问题。解决方式经常是请求自己所在的java项目，然后后端人员再去请求其他java服务。 java项目需要在yml配置中添加前端的Projects Manager访问地址和具体的前端项目id。经常有后端人员不知道这是什么，然后在新建测试环境的时候忽略他们。最后造成无法访问。
# Version Ⅱ
这个版本当然是为了解决上个版本的问题而诞生。如果说上个版本和后端项目还有一丝的联系，这个版本前后端就彻底分离了。
# 说明
Projects Manager除了管理项目资源，还承载了模板的渲染。虽然这个Node服务只用来渲染模板和转发请求有点浪费，但如果它管理了大量的单页应用，又似乎还说得过去。在正常的请求前添加标识符，然后在Projects Manager中配置标志符和java服务的映射，实现代理到不同的java服务。
# 需要做的事情
以 Version Ⅱ 为例，需提供：
- 实现提供上传文件到CDN的webpack插件 需要控制权限 需要强制备注上传原因
- 提供管理项目静态资源的管理后台，包括新增项目、新增用户权限、修改指定环境静态资源、域名管理、代理目标管理等功能
- 提供Node Server，用以渲染SPA应用的模板文件以及代理请求到其他服务器
- 提供对项目模板的个性化定制