前端部署相关知识导览

文章开始之前，推荐一些别人写的很好的文章！感兴趣的也可以去读一下哦！

今日推荐：Electron以慢著称，为什么桌面QQ却选择它做架构升级？

文章链接：https://cloud.tencent.com/developer/article/2332111

最近在使用 electron 做本地资源管理器的时候，也在往优化方面思考，比如初始化加载页、多窗口的创建销毁、多窗口通信等。上文就给出了一些的优化思路。

基础部署

前端网页能被访问的前提，一个是网址对应的资源，一个是网络发现。

所以通常来讲，把 .html 等资源放到服务器上，然后使用 nginx 等工具做网络代理，即可将网址指向前端内容。

上传资源部分：

• 在本地 npm run build，得到了 dist/* 等资源文件。
• 若你买了个 windows 轻量服务器。
• 把资源文件 Ctrl+C 拷贝到服务器的 D://web/* 文件夹中。
• 而若你买的其他服务器，没有可视化界面了。
• 则需要一些 ssh 命令，比如 scp -r local_path username@ip:/usr/opt/web 等。
• 或者 WinSCP 之类的可视化工具来进行上传。

网络发现部分：

• 此时访问 [ip]/index.html 是访问不到的资源。
• 你可以进行 nginx.conf 配置比如 location / { root D://web; } 后，即可访问网址则能看到内容了。
• 也有其他方式，比如 windows 的 IIS 配置或 route add 命令等。

当然，你也可以不用自己的服务器，而是第三方的服务器：

• 比如 COS 文件服务器，用管理后台或相应 SDK 去上传即可。
• 比如托管服务，像 github pages、vercel、netlify 等也相当方便。

至于不想只是 IP 地址来访问，而是域名，则需要域名 DNS 解析即可，就是另个小课题了。

自动化上传

显然，多半情况下，网络发现配置仅配置一次即可，更需要频繁更新的是上传资源，那么自动化上传提上日程。

那么就需要两个考虑，一个是自动化程序，一个是上传时机。

上传时机方面：

上传时机主要靠的是 git hooks，比如 post-merge 之类的。

当然你说本地运行些 npm run deploy 的命令也行，但多半其实监听的也是 pre-push 之类的时机，或者比较手动的。

• 而像 github、工蜂 之类的代码托管的平台上，也多半有进行配置 git hooks 的地方，甚至有 tag push 等时机的拓展。
• 如果你是自建部署平台，比如 jenkins、bamboo 等各式持续集成工具，同样可以配置。
• 至于托管服务，比如 vercel、netlify 等，其实只是隐藏了上述内容，只需要更少的配置而已。

自动化程序方面：

程序就比较简单了，通常就是 NodeJs 脚本即可，只看你想在什么环境下去走这些流程，可见下一章。

另外，除了 build 和 upload 之外，这个阶段你还可以干很多事，比如加版本号、统计体积、自动化测试等。

自动化环境

如果是团队合作，一个用 mac 一个用 win，一个用 nodejs18 一个用 nodejs16，或者两人的 npm global 依赖版本不一致，

那么上述过程在本地运行，就会造成结果可能不一致，不同人部署的结果就不同。

所以，需要一个自动化环境，来保证打包结果的统一。

在上传时机板块就已经涉及到了，无论是第三方平台还是自建服务，都是比较独立的环境了。

使用第三方服务器

最简单的方式就是利用各种托管平台，

比如 github actions 能自己写脚本来触发 npm run deploy 等 node 命令，

或者 vercel、netlify 的项目配置中有个启动脚本的输入框等。

使用自有服务器

而自建部署平台，无论你用的简单 jenkins 还是什么能私有化的流水线平台，就得买个服务器了。

平台搭建完成后，去配置 git 仓库地址、配登录权限、配 git hooks 等，再写点自定义脚本即可。

还有个方式可以不使用平台，而是搞个 web hooks，去接收代码托管平台时机被触发时发过来的消息，再进行自动化部署。

分布式部署

如果你的网站访问量够大，需要分流到多台服务器，那么你可能需要分布式部署了。

扯到分布式就要先了解 docker 和 k8s，就要了解下容器化技术。

• 其中 docker 可以保证不管你的服务器无论是 win 还是 linux，始终是一样的 docker 中包含的环境。
• 而 k8s 可以保证当你新加服务器时能自动部署，减少服务器时不会让网络发现打空。

配置容器 & 构建容器

可以简单的把使用 docker 分为两个阶段，一个 build，一个 run。

比较推荐在 docker build 阶段你只放入 dist/* 打包结果文件，而非源码，这样可以让镜像更小，部署更快。

比如放的是源码，那么容器中还得有 NodeJs 软件被安装，运行容器时还有 npm install 的时间花销和 node_modules 的内存花销。

但如果是一套代码分渠道的场景，可能会使用不同的环境变量，那还是放入源码吧，在 run 阶段时就能响应一些变量的变化了。

这牵扯到 Dockerfile 的编写，按你的需求进行编写即可。

运行容器 & 调度容器

在 docker build 构建容器完成后，就是在集群中使用了

• 你可以 docker push 将容器推到镜像仓库去等待被拉取，前提是需要 docker login。
• 也可以 docker save 将容器转为 tar 压缩包，去上传到 COS 等待被拉取，或上传到 k8s 集群。
• 待集群使用时，去 docker pull，或下载然后 docker load，然后 docker run 即可。

版本

当出现线上问题又难以短期内解决时，你可能需要回滚版本，

而回退代码再重新部署还是繁琐了点，所以部署也需要版本管理。

使用了容器化技术

当然，如果是按上面的流程搭下来，你只需要处理最后 k8s 的部分即可，拉取或下载旧版本容器然后运行即可。

未使用容器化技术

但如果你的部署架构没搞容器化，那么你就需要冗余一批旧版本的打包结果了。

比如在服务器上有着 D://web-v1 和 D://web-v2 两个目录，只需改动 nginx 等的网络发现指向即可。

至于冗余多少冗余多久，就看你的需求了，或者等到服务器内存爆了再清理也不是不行。

缓存

其实部署后的内容，大概率在短期内不会变，所以加上缓存还是蛮有必要的。

咱们分两端来看，云端和客户端：

云端缓存

云端可以搞 CDN 缓存或自建网关服务，对指向的资源进行一定的缓存和分配。

客户端缓存

而客户端主要是，一个 HTTP 缓存，一个浏览器缓存。

关于 HTTP 缓存，主要要修改的是各种 request headers：

• 比如 Expires 和 Cache-Control 可以去设定过期时间。也即强缓存，后续两条为协商缓存
• 比如 Last-Modified 和 If-Modified-Since 可以对比变更时间来判断缓存是否更新。
• 比如 Etag 和 If-None-Match 可以对比变更文件的 md5 值来判断缓存是否更新。

关于浏览器缓存，主要就 service worker api，毕竟浏览器对资源处理的能力有限。

其他

单页面应用的注意事项

当打包结果为 SPA 应用且路由方式为 history 模式时，通常 / 能正常访问但 /xx 去刷新就会 404 了。

那是因为 /xx 所指向的东西没有资源，所以 nginx 中需要 try_files $uri $uri/ /index.html 的配置。

Node 服务的部署

比如你还搞了前端网关或 BFF 服务，你可以使用以上相同的逻辑去部署，

只是除了资源和网络发现外，又多了一个接口或路由的概念，但实质也可认为是资源，只是路由或接口是业务决定的，比如 koa、express 来做。

Node 服务的进程管理

另外，当部署 node 服务时，你可以用 pm2、forever 等来做进程管理，

提高单个服务器中对批量网络发现的并发能力，压榨一点服务器性能。

邀请人：一起重学前端