注册

当我们谈部署时,我们在谈什么?

f94a1b308edb4569bf131c52a6e8094d~tplv-k3u1fbpfcp-zoom-crop-mark:1304:1304:1304:734.awebp?

计算机网络把各地的计算机连接了起来,只要有一台可以上网的终端,比如手机、电脑,就可以访问互联网上任何一台服务器的资源(包括静态资源和动态的服务)。

作为开发者的我们,就是这些资源、服务的提供者,把资源上传到服务器,并把服务跑起来的过程就叫做部署

30b809ba84844598aca3426b2da67d8a~tplv-k3u1fbpfcp-zoom-in-crop-mark:1304:0:0:0.awebp?

代码部分的部署,需要先经过构建,也就是编译打包的过程,把产物传到服务器。

最原始的部署方式就是在本地进行 build,然后把产物通过 FTP 或者 scp(基于 SSH 的远程拷贝文件拷贝) 传到服务器上,如果是后端代码还需要重启下服务。

db98771f427449e1a8078b11ada560ae~tplv-k3u1fbpfcp-zoom-in-crop-mark:1304:0:0:0.awebp

每个人单独构建上传,这样不好管理,也容易冲突,所以现在都会用专门的平台来做这件事构建和部署,比如 jenkins。

我们代码会提交到 gitlab 等代码库,然后 jenkins 从这些代码库里把代码下载下来进行 build,再把产物上传到服务器上。

流程和直接在本地构建上传差不多,只不过这样方便管理冲突、历史等,还可以跨项目复用一些东西。

3759e19ff1a744cf89cdf3f490c2d309~tplv-k3u1fbpfcp-zoom-in-crop-mark:1304:0:0:0.awebp?

构建、部署的过程最开始是通过 shell 来写,但写那个的要求还是很高的。后来就支持了可视化的编排,可以被编排的这个构建、部署的流程叫做流水线 pipeline。

1dd740c4cbb34accbb9b817634b922b1~tplv-k3u1fbpfcp-zoom-in-crop-mark:1304:0:0:0.awebp?

比如这是 jenkins 的 pipeline 的界面:

11cfdee3de474f289df24e18906fbc03~tplv-k3u1fbpfcp-zoom-in-crop-mark:1304:0:0:0.awebp?

除了构建、部署外,也可以加入一些自动化测试、静态代码检查等任务。

这种自动化了的构建、部署流程就叫做 CI(持续集成)、CD(持续部署)。

我们现在还是通过 scp / FTP 来上传代码做的部署,但是不同代码的运行环境是不同的,比如 Node.js 服务需要安装 node,Java 服务需要安装 JRE 等,只把代码传上去并不一定能跑起来。

那怎么办呢?怎么保证部署的代码运行在正确的环境?

把环境也给管理起来,作为部署信息的一部分不就行了?

现在流行的容器技术就是做这个的,比如 docker,可以把环境信息和服务启动方式放到 dockerfile 里,build 产生一个镜像 image,之后直接部署这个 docker image 就行。

比如我们用 nginx 作为静态服务器的时候,dockerfile 可能是这样的:

FROM nginx:alpine

COPY /nginx/ /etc/nginx/

COPY /dist/ /usr/share/nginx/html/

EXPOSE 80

这样就把运行环境给管理了起来。

所以,现在的构建产物不再是直接上传服务器,而是生成一个 docker image,上传到 docker registry,然后把这个 docker image 部署到服务器。

42878d90763d44feab428f67b007af2d~tplv-k3u1fbpfcp-zoom-in-crop-mark:1304:0:0:0.awebp

还有一个问题,现在前端代码、后端代码都部署在了我们的服务器上,共享服务器的网络带宽,其中前端代码是不会变动的、流量却很大,这样使得后端服务的可用带宽变小、支持的并发量下降。

能不能把这部分静态资源的请求分离出去呢?最好能部署到离用户近一点的服务器,这样访问更快。

确实可以,这就是 CDN 做的事情。

网上有专门的 CDN 服务提供商,它们有很多分散在各地的服务器,可以提供静态资源的托管。这些静态资源最终还是从我们的静态资源服务器来拿资源的,所以我们的静态资源服务器叫做源站。但是请求一次之后就会缓存下来,下次就不用再请求源站了,这样就减轻了我们服务器的压力,还能加速用户请求静态资源的速度。

12dc9c4e14e34827b291a1f7d41fff06~tplv-k3u1fbpfcp-zoom-in-crop-mark:1304:0:0:0.awebp

这样就解决了静态资源分去了太多网络带宽的问题,而且还加速了资源的访问速度。

此外,静态资源的部署还要考虑顺序问题,要先部署页面用到的资源,再部署页面,还有,需要在文件名加 hash 来触发缓存更新等,这些都是更细节的问题。

这里说的都是网页的部署方式,对于 APP/小程序它们是有自己的服务器和分发渠道的,我们构建完之后不是部署,而是在它们的平台提交审核,审核通过之后由它们负责部署和分发。

总结

互联网让我们能够用手机、PC 等终端访问任何一台服务器的资源、服务。而提供这些资源、服务就是我们开发者做的事情。把资源上传到服务器上,并把服务跑起来,就叫做部署。

对于代码,我们可以本地构建,然后把构建产物通过 FTP/scp 等方式上传到服务器。

但是这样的方式不好管理,所以我们会有专门的 CI/CD 平台来做这个,比如 jenkins。

jenkins 支持 pipeline 的可视化编排,比写 shell 脚本的方式易用很多,可以在构建过程中加入自动化测试、静态代码检查等步骤。

不同代码运行环境不同,为了把环境也管理起来,我们会使用容器技术,比如 docker。把环境信息写入 dockerfile,然后构建生成 docker image,上传到 registry,之后部署这个 docker image 就行。

静态资源和动态资源共享服务器的网络带宽,为了减轻服务器压力、也为了加速静态资源的访问,我们会使用 CDN 来对静态资源做加速,把我们的静态服务器作为源站。第一个静态资源的请求会请求源站并缓存下来,之后的请求就不再需要请求源站,这样就减轻了源站的压力。此外,静态资源的部署还要考虑顺序、缓存更新等问题。

对于网页来说是这样,APP/小程序等不需要我们负责部署,只要在它们的平台提交审核,然后由它们负责部署和分发。

当我们在谈部署的时候,主要就是在谈这些。

作者:zxg_神说要有光
来源:https://juejin.cn/post/7073826878858985479

0 个评论

要回复文章请先登录注册