feat: 更新前端部署的演进

articles/minds/improve-of-deploy.md

@@ -5,16 +5,16 @@
 前端网页能被访问的前提，一个是网址对应的资源，一个是网络发现。<br />
 所以通常来讲，把 `.html` 等资源放到服务器上，然后使用 `nginx` 等工具做网络代理，即可将网址指向前端内容。
 
-比如**上传资源**部分：
+##### 上传资源部分：
 
 * 在本地 `npm run build`，得到了 `dist/*` 等资源文件。
 * 若你买了个 `windows` 轻量服务器。
 * 把资源文件 `Ctrl+C` 拷贝到服务器的 `D://web/*` 文件夹中。
 * 而若你买的其他服务器，没有可视化界面了。
-* 则需要一些 `ssh` 命令，比如 `scp -r local_path username@ip:path` 等。
+* 则需要一些 `ssh` 命令，比如 `scp -r local_path username@ip:/usr/opt/web` 等。
 * 或者 `WinSCP` 之类的可视化工具来进行上传。
 
-而**网络发现**部分：
+##### 网络发现部分：
 
 * 此时访问 `[ip]/index.html` 是访问不到的资源。
 * 你可以进行 `nginx.conf` 配置比如 `location / { root D://web; }` 后，即可访问网址则能看到内容了。
@@ -33,20 +33,20 @@
 
 那么就需要两个考虑，一个是自动化程序，一个是上传时机。
 
-**上传时机**方面：
+##### 上传时机方面：
 
 上传时机主要靠的是 `git hooks`，比如 `post-merge` 之类的。<br />
 *当然你说本地运行些 `npm run deploy` 的命令也行，但多半其实监听的也是 `pre-push` 之类的时机，或者比较手动的。*
 
 * 而像 `github`、工蜂 之类的代码托管的平台上，也多半有进行配置 `git hooks` 的地方，甚至有 `tag push` 等时机的拓展。
-* 如果你是自建部署平台，比如 `Jenkins`、`Bamboo` 等各式持续集成工具，同样可以配置。
+* 如果你是自建部署平台，比如 `jenkins`、`bamboo` 等各式持续集成工具，同样可以配置。
 * 至于托管服务，比如 `vercel`、`netlify` 等，其实只是隐藏了上述内容，只需要更少的配置而已。
 
-**自动化程序**方面：
+##### 自动化程序方面：
 
 程序就比较简单了，通常就是 `NodeJs` 脚本即可，只看你想在什么环境下去走这些流程，可见下一章。
 
-另外，除了 `build` 和 `upload` 之外，这个阶段你还可以干很多事，比如加版本、统计体积、自动化测试等。
+另外，除了 `build` 和 `upload` 之外，这个阶段你还可以干很多事，比如加版本号、统计体积、自动化测试等。
 
 ## 自动化环境
 
@@ -56,15 +56,96 @@
 所以，需要一个自动化环境，来保证打包结果的统一。<br />
 在上传时机板块就已经涉及到了，无论是第三方平台还是自建服务，都是比较独立的环境了。
 
-最简单的方式就是利用托管平台，只是看它是否提供了自定义脚本的方式。<br />
-如果能自己写脚本那触发 `npm run deploy` 之类的命令即可，如果不能就只能另搭服务提供给它 `Webhooks` 了。
+##### 使用第三方服务器
 
-而自建部署平台，无论你用的简单 `jenkins` 还是什么能私有化的流水线平台，就得买个服务器了。
+最简单的方式就是利用各种托管平台，<br />
+比如 `github actions` 能自己写脚本来触发 `npm run deploy` 等 `node` 命令，<br />
+或者 `vercel`、`netlify` 的项目配置中有个启动脚本的输入框等。
+
+##### 使用自有服务器
+
+而自建部署平台，无论你用的简单 `jenkins` 还是什么能私有化的流水线平台，就得买个服务器了。<br />
+平台搭建完成后，去配置 `git` 仓库地址、配登录权限、配 `git hooks` 等，再写点自定义脚本即可。<br />
+
+还有个方式可以不使用平台，而是搞个 `web hooks`，去接收代码托管平台时机被触发时发过来的消息，再进行自动化部署。
 
 ## 分布式部署
 
+如果你的网站访问量够大，需要分流到多台服务器，那么你可能需要分布式部署了。
+
 扯到分布式就要先了解 `docker` 和 `k8s`，就要了解下容器化技术。
 
 * 其中 `docker` 可以保证不管你的服务器无论是 `win` 还是 `linux`，始终是一样的 `docker` 中包含的环境。
 * 而 `k8s` 可以保证当你新加服务器时能自动部署，减少服务器时不会让网络发现打空。
 
+##### 配置容器 & 构建容器
+
+可以简单的把使用 `docker` 分为两个阶段，一个 `build`，一个 `run`。
+
+比较推荐在 `docker build` 阶段你只放入 `dist/*` 打包结果文件，而非源码，这样可以让镜像更小，部署更快。<br />
+比如放的是源码，那么容器中还得有 `NodeJs` 软件被安装，运行容器时还有 `npm install` 的时间花销和 `node_modules` 的内存花销。
+
+但如果是一套代码分渠道的场景，可能会使用不同的环境变量，那还是放入源码吧，在 `run` 阶段时就能响应一些变量的变化了。<br />
+这牵扯到 `Dockerfile` 的编写，按你的需求进行编写即可。
+
+##### 运行容器 & 调度容器
+
+在 `docker build` 构建容器完成后，就是在集群中使用了<br />
+
+* 你可以 `docker push` 将容器推到镜像仓库去等待被拉取，前提是需要 `docker login`。<br />
+* 也可以 `docker save` 将容器转为 `tar` 压缩包，去上传到 `COS` 等待被拉取，或上传到 `k8s` 集群。
+* 待集群使用时，去 `docker pull`，或下载然后 `docker load`，然后 `docker run` 即可。
+
+## 版本
+
+当出现线上问题又难以短期内解决时，你可能需要回滚版本，<br />
+而回退代码再重新部署还是繁琐了点，所以部署也需要版本管理。
+
+##### 使用了容器化技术
+
+当然，如果是按上面的流程搭下来，你只需要处理最后 `k8s` 的部分即可，拉取或下载旧版本容器然后运行即可。
+
+##### 未使用容器化技术
+
+但如果你的部署架构没搞容器化，那么你就需要冗余一批旧版本的打包结果了。<br />
+比如在服务器上有着 `D://web-v1` 和 `D://web-v2` 两个目录，只需改动 `nginx` 等的网络发现指向即可。<br />
+至于冗余多少冗余多久，就看你的需求了，或者等到服务器内存爆了再清理也不是不行。
+
+## 缓存
+
+其实部署后的内容，大概率在短期内不会变，所以加上缓存还是蛮有必要的。
+
+咱们分两端来看，云端和客户端：
+
+##### 云端缓存
+
+云端可以搞 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 了。<br />
+那是因为 `/xx` 所指向的东西没有资源，所以 `nginx` 中需要 `try_files $uri $uri/ /index.html` 的配置。
+
+##### Node 服务的部署
+
+比如你还搞了前端网关或 `BFF` 服务，你可以使用以上相同的逻辑去部署，<br />
+只是除了资源和网络发现外，又多了一个接口或路由的概念，但实质也可认为是资源，只是路由或接口是业务决定的，比如 `koa`、`express` 来做。
+
+##### Node 服务的进程管理
+
+另外，当部署 `node` 服务时，你可以用 `pm2`、`forever` 等来做进程管理，<br />
+提高单个服务器中对批量网络发现的并发能力，压榨一点服务器性能。