计算机网络连接来自世界各地的计算机。只要有可以上网的终端，比如手机或者电脑，就可以访问互联网上任意服务器的资源（包括静态资源和动态服务）。作为开发者，我们是这些资源和服务的提供者。将资源上传到服务器并运行服务的过程称为部署。代码部分的部署需要先构建，即编译打包，将产品传输到服务器的过程。最原始的部署方式是在本地搭建，然后通过FTP或者scp（基于SSH的远程拷贝文件拷贝）将产品传输到服务器。如果是后端代码，需要重启服务。每个人独立构建和上传，管理难度大，容易产生冲突，所以现在这个构建和部署都是用专门的平台，比如jenkins。我们的代码会提交到gitlab等代码库，然后jenkins会从这些代码库中下载代码进行构建，然后将产品上传到服务器。过程类似于直接在本地构建上传，但是方便管理冲突，历史记录等，也可以跨项目复用一些东西。构建和部署的过程最初是通过shell来写的，但是写的要求还是很高的，很少有人会写（不知道怎么写）。后来支持了可视化编排，把可以编排的构建和部署的过程称为流水线。比如这个是jenkins的pipeline的接口：除了build和deploying，还可以加入一些自动化测试，静态代码检查等任务。这种自动化的构建和部署过程称为CI（持续集成）和CD（持续部署）。我们还是使用scp/ftp上传代码进行部署，只是不同代码的运行环境不同。例如，节点。起来。那我们该怎么办呢？如何保证部署的代码运行在正确的环境中？将环境作为部署信息的一部分进行管理就足够了吗？现在流行的容器技术就是这样做的，比如docker，可以结合环境信息和服务的启动方式放在dockerfile中，build生成镜像，然后直接部署docker镜像。例如，当我们使用nginx作为静态服务器时，dockerfile可能如下所示：FROMnginx:alpineCOPY/nginx//etc/nginx/COPY/dist//usr/share/nginx/html/EXPOSE80这将管理运行环境起来。所以现在的构建产品不再是直接上传到服务器，而是生成一个docker镜像，上传到dockerregistry，然后将docker镜像部署到服务器。还有一个问题。现在前端代码和后端代码部署在我们的服务器上，共享服务器的网络带宽。前端代码不会变，但是流量非常大，使得后端服务的可用带宽发生变化。小的，受支持的并发下降。这部分静态资源请求能不能分开？最好部署到离用户较近的服务器上，这样访问会比较快。它确实如此，这就是CDN所做的。网上有专门的CDN服务商，他们有很多服务器分散在各处，可以提供静态资源托管。这些静态资源最终都是从我们的静态资源服务器上获取的，所以我们的静态资源服务器被称为源站。但是请求一次后就会缓存起来，下次就不需要再去请求源站了，这样就减轻了我们服务器的压力，加快了用户请求静态资源的速度。这样解决了静态资源分配太多网络带宽的问题，也加快了资源的访问速度。另外，静态资源的部署还需要考虑顺序问题。必须先部署页面使用的资源，然后再部署页面。另外还需要在文件名中加入hash来触发缓存更新等，这些都是比较细化的问题。我这里说的是网页的部署方式。对于APP/小程序，他们有自己的服务器和分发渠道。在我们构建它们之后，我们不会部署它们，而是将它们提交到他们的平台上进行审查。审核通过后，他们负责部署和分发。分配。综上所述，互联网让我们可以使用手机、PC等终端访问任何服务器的资源和服务。而提供这些资源和服务就是我们开发者所做的。将资源上传到服务器并运行服务称为部署。对于代码，我们可以在本地构建，然后通过FTP/scp等方式将构建产品上传到服务器。但是这种方式不好管理，所以我们会有专门的CI/CD平台来做，比如作为詹金斯。Jenkins支持管道的可视化排列，比写shell脚本好用多了。您可以在构建过程中添加自动化测试和静态代码检查等步骤。不同的代码在不同的环境中运行。为了管理环境，我们会使用容器技术，比如docker。将环境信息写入dockerfile，然后构建生成docker镜像，上传到registry，然后部署docker镜像。静态资源和动态资源共享服务器的网络带宽。为了减轻服务器压力，加快静态资源的访问速度，我们将使用CDN对静态资源进行加速，并使用我们的静态服务器作为源站。第一次静态资源请求会请求源站并缓存，后续请求不再需要请求源站，从而减轻源站压力。另外，静态资源的部署还需要考虑顺序和缓存更新等问题。网页也是这样，app/小程序等不需要我们负责部署，只要在他们的平台上提交审核，然后他们负责部署分发即可。当我们谈论部署时，这就是我们谈论的主要内容。
