炫技，从 12.67s 到 1.06s 的网站性能优化实战

0.引言

做为互联网项目，最重要的即是用户体验。在举国“互联网+”的热潮中，用户至上也已经被大多数企业所接收，特别是在现在移动端快速发展的时代，咱们的网页不只只是呈如今用户的PC浏览器里，更多的时候，用户是经过移动产品浏览咱们的网页。加之有愈来愈多的开发者投入到Web APP和Hybrid APP的开发队伍中，性能这一问题又再一次被提上了程序员们重点关注的要素。我曾经看到过这样一句话：一个网站的体验，决定了用户是否愿意去了解网站的功能；而网站的功能，决定了用户是否会一票否决网站的体验。这是改版自网络上的一句流行语，但却把网站性能这件事说的十分透彻，特别是在网站这样的项目中，若是一个用户须要超过5s才能看见页面，他会绝不犹豫地关闭它。性能优化，做为工程师界的“上乘武功”，是咱们在开发中老生常谈的话题，也是一名开发者从入门向资深进阶的必经阶段，虽然咱们看到过不少的标准、军规，但在真正实践中，却经常力不从心，不知道落下了什么，不知道性能是否还有进一步优化的空间。

对于网站的性能，在行业内有不少既定的指标，但就之前端er而言，咱们应该更加关注如下指标：白屏时间、首屏时间、整页时间、DNS时间、CPU占用率。而我以前本身搭建的一个网站（网址：jerryonlyzrj.com/resume/ ，近日因域名备案没法打开，几往后即恢复正常），彻底没作性能优化时，首屏时间是12.67s，最后通过多方面优化，终于将其下降至1.06s，而且还未配置CDN加速。其中过程我踩了不少坑，也翻了许多专业书籍，最后决定将这几日的努力整理成文，帮助前端爱好者们少走弯路。文章更新可能以后不会实时同步在论坛上，欢迎你们关注个人Github，我会把最新的文章更新在对应的项目里，让咱们一块儿在代码的海洋里策马奔腾：github.com/jerryOnlyZR… 。

今天，咱们将从性能优化的三大方面工做逐步展开介绍，其中包括网络传输性能、页面渲染性能以及JS阻塞性能，系统性地带着读者们体验性能优化的实践流程。

1.网络传输性能优化

在开始介绍网络传输性能优化这项工做以前，咱们须要了解浏览器处理用户请求的过程，那么就必须奉上这幅神图了：

这是navigation timing监测指标图，从图中咱们能够看出，浏览器在获得用户请求以后，经历了下面这些阶段：重定向→拉取缓存→DNS查询→创建TCP连接→发起请求→接收响应→处理HTML元素→元素加载完成。不着急，咱们对其中的细节一步步展开讨论：

1.1.浏览器缓存

咱们都知道，浏览器在向服务器发起请求前，会先查询本地是否有相同的文件，若是有，就会直接拉取本地缓存，这和咱们在后台部属的Redis和Memcache相似，都是起到了中间缓冲的做用，咱们先看看浏览器处理缓存的策略：

由于网上的图片太笼统了，并且我翻过不少讲缓存的文章，不多有将状态码还有何时将缓存存放在内存（memory）中何时缓存在硬盘中（disk）系统地整理出来，因此我本身绘制了一张浏览器缓存机制流程图，结合这张图再更深刻地说明浏览器的缓存机制。

这里咱们可使用chrome devtools里的network面板查看网络传输的相关信息：

（这里须要特别注意，在咱们进行缓存调试时，须要去除network面板顶部的Disable cache 勾选项，不然浏览器将始终不会从缓存中拉取数据）

浏览器默认的缓存是放在内存内的，但咱们知道，内存里的缓存会由于进程的结束或者说浏览器的关闭而被清除，而存在硬盘里的缓存才可以被长期保留下去。不少时候，咱们在network面板中各请求的size项里，会看到两种不一样的状态：from memory cache 和 from disk cache，前者指缓存来自内存，后者指缓存来自硬盘。而控制缓存存放位置的，不是别人，就是咱们在服务器上设置的Etag字段。在浏览器接收到服务器响应后，会检测响应头部（Header），若是有Etag字段，那么浏览器就会将本次缓存写入硬盘中。

之因此拉取缓存会出现200、304两种不一样的状态码，取决于浏览器是否有向服务器发起验证请求。只有向服务器发起验证请求并确认缓存未被更新，才会返回304状态码。

这里我以nginx为例，谈谈如何配置缓存:

首先，咱们先进入nginx的配置文档

$ vim nginxPath/conf/nginx.conf

在配置文档内插入以下两项：

打开咱们的网站，在chrome devtools的network面板中观察咱们的请求资源，若是在响应头部看见Etag和Expires字段，就说明咱们的缓存配置成功了。

【！！！特别注意！！！】 在咱们配置缓存时必定要切记，浏览器在处理用户请求时，若是命中强缓存，浏览器会直接拉取本地缓存，不会与服务器发生任何通讯，也就是说，若是咱们在服务器端更新了文件，并不会被浏览器得知，就没法替换失效的缓存。因此咱们在构建阶段，须要为咱们的静态资源添加md5 hash后缀，避免资源更新而引发的先后端文件没法同步的问题。

1.2.资源打包压缩

咱们以前所做的浏览器缓存工做，只有在用户第二次访问咱们的页面才能起到效果，若是要在用户首次打开页面就实现优良的性能，必须对资源进行优化。咱们常将网络性能优化措施归结为三大方面：减小请求数、减少请求资源体积、提高网络传输速率。如今，让咱们逐个击破：

结合前端工程化思想，咱们在对上线文件进行自动化打包编译时，一般都须要打包工具的协助，这里我推荐webpack，我一般都使用Gulp和Grunt来编译node，Parcel太新，并且webpack也一直在自身的特性上向Parcel靠拢。

在对webpack进行上线配置时，咱们要特别注意如下几点：

①JS压缩：（这点应该算是耳熟能详了，就很少介绍了）

②HTML压缩：

④提取css并压缩：

在使用webpack的过程当中，咱们一般会以模块的形式引入css文件（webpack的思想不就是万物皆模块嘛），可是在上线的时候，咱们还须要将这些css提取出来，而且压缩，这些看似复杂的过程只须要简单的几行配置就行：

（PS:咱们须要用到mini-css-extract-plugin ，因此还得你们自行npm install）

若是你能按照上述六点将webpack上线配置完整配置出来，基本能将文件资源体积压缩到极致了，若有疏漏，还但愿你们能加以补充。

最后，咱们还应该在服务器上开启Gzip传输压缩，它能将咱们的文本类文件体积压缩至原先的四分之一，效果立竿见影，仍是切换到咱们的nginx配置文档，添加以下两项配置项目：

【！！！特别注意！！！】 不要对图片文件进行Gzip压缩！不要对图片文件进行Gzip压缩！不要对图片文件进行Gzip压缩！我只会告诉你效果拔苗助长，至于具体缘由，还得考虑服务器压缩过程当中的CPU占用还有压缩率等指标，对图片进行压缩不但会占用后台大量资源，压缩效果其实并不可观，能够说是“弊大于利”，因此请在gzip_types 把图片的相关项去掉。针对图片的相关处理，咱们接下来会更加具体地介绍。

1.3.图片资源优化

刚刚咱们介绍了资源打包压缩，只是停留在了代码层面，而在咱们实际开发中，真正占用了大量网络传输资源的，并非这些文件，而是图片，若是你对图片进行了优化工做，你能马上看见明显的效果。

1.3.1.不要在HTML里缩放图像

不少开发者可能会有这样的错觉（其实我曾经也是这样），咱们会为了方便在一个200✖200的图片容器内直接使用一张400✖400的图片，咱们甚至认为这样能让用户以为图片更加清晰，其实否则，在普通的显示器上，用户并不会感到缩放后的大图更加清晰，但这一切却致使网页加速速度降低，同时照成带宽浪费，你可能不知道，一张200KB的图片和2M的图片的传输时间会是200m和12s的差距（亲身经历，深受其害(┬＿┬)）。因此，当你须要用多大的图片时，就在服务器上准备好多大的图片，尽可能固定图片尺寸。

1.3.2.使用雪碧图（CSS Sprite）

雪碧图的概念你们必定在生活中常常听见，其实雪碧图是减少请求数的显著运用。并且很奇妙的是，多张图片聘在一块后，整体积会比以前全部图片的体积之和小（你能够亲自试试）。这里给你们推荐一个自动化生成雪碧图的工具：https://www.toptal.com/developers/css/sprite-generator （图片来自官网首页）

只要你添加相关资源文件，他就会自动帮你生成雪碧图以及对应的CSS样式。

其实咱们在工程中还有更为自动的方法，即是一款雪碧图生成插件webpack-spritesmith。首先，先简单介绍一下使用插件生成雪碧图的思路：

首先，咱们会把咱们所须要的小图标放置在一个文件夹内以便于管理：

（这里的@2x图片是为了适配视网膜二倍屏的图片资源，webpack-spritesmith内有专门为适配多倍屏提供的配置项，稍候将会讲到）

而后，咱们须要插件去读取这个文件夹内的全部图片资源文件，以文件夹名称为图片名称生成一张雪碧图到指定位置，而且输出可以正确使用这些雪碧图的CSS文件。

现在，webpack-spritesmith这款插件能实现咱们想要的一切，先奉上配置内容：具体可参照webpack-spritesmith官方文档

执行webpack以后，就会在开发目录里生成上面两张图的结果，咱们能够看看common.css里面的内容：

咱们能够看到，全部咱们以前放在common文件夹里的图片资源都自动地生成了相应的样式，这些都不须要咱们手动处理，``webpack-spritesmith`这款插件就已经帮咱们完成了！

1.3.3.使用字体图标（iconfont）

不管是压缩后的图片，仍是雪碧图，终归仍是图片，只要是图片，就仍是会占用大量网络传输资源。可是字体图标的出现，却让前端开发者看到了另一个神奇的世界。

我最喜欢用的是阿里矢量图标库（网址：www.iconfont.cn/），里面有大量的矢量图…

图片能作的不少事情，矢量图都能做，并且它只是往HTML里插入字符和CSS样式而已，和图片请求比起来资源占用彻底不在一个数量级，若是你的项目里有小图标，就是用矢量图吧。

但若是咱们作的是公司或者团队的项目，须要使用到许多自定义的字体图标，可爱的设计小姐姐们只是丢给你了几份.svg图片，你又该如何去作呢？

其实也很简单，阿里矢量图标库就提供了上传本地SVG资源的功能，这里另外推荐一个网站——icomoon。icomoon这个网站也为咱们提供了将SVG图片自动转化成CSS样式的功能。（图片来自icomoon首页）

咱们能够点击Import Icons按钮导入咱们本地的SVG资源，而后选中他们，接下来生成CSS的事情，就交给icomoon吧，具体的操做，就和阿里矢量图标库类同了。

1.3.4.使用WebP

WebP格式，是谷歌公司开发的一种旨在加快图片加载速度的图片格式。图片压缩体积大约只有JPEG的2/3，并能节省大量的服务器带宽资源和数据空间。Facebook、Ebay等知名网站已经开始测试并使用WebP格式。

咱们可使用官网提供的Linux命令行工具对项目中的图片进行WebP编码，也可使用咱们的线上服务，这里我推荐叉拍云（网址：www.upyun.com/webp）。可是在实际…

1.4.网络传输性能检测工具——Page Speed

除了network版块，其实chrome还为咱们准备好了一款监测网络传输性能的插件——Page Speed，我们的文章封面，就是用的Page Speed的官方宣传图（由于我以为这张图再合适不过了）。咱们只须要经过下面步骤安装，就能够在chrome devtools里找到它了：chrome菜单→更多工具→拓展程序→chrome网上应用商店→搜索pagespeed后安转便可。

（PS：使用chrome应用商店须要***，怎么***我就不便多说了）

这就是Page Speed的功能界面：

咱们只须要打开待测试的网页，而后点击Page Speed里的 Start analyzing按钮，它就会自动帮咱们测试网络传输性能了，这是个人网站测试结果：

Page Speed最人性化的地方，即是它会对测试网站的性能瓶颈提出完整的建议，咱们能够根据它的提示进行优化工做。这里个人网站已经优化到最好指标了(•́⌄•́๑)૭✧，Page Speed Score表示你的性能测试得分，100/100表示已经没有须要优化的地方。

优化完毕后再使用chorme devtools的network版块测量一下咱们网页的白屏时间还有首屏时间，是否是获得了很大的提高？

1.5.使用CDN

Last but not least，

再好的性能优化实例，也必须在CDN的支撑下才能到达极致。

若是咱们在Linux下使用命令$ traceroute targetIp 或者在Windows下使用批处理 > tracert targetIp，均可以定位用户与目标计算机之间通过的全部路由器，不言而喻，用户和服务器之间距离越远，通过的路由器越多，延迟也就越高。使用CDN的目的之一即是解决这一问题，固然不只仅如此，CDN还能够分担IDC压力。

固然，凭着咱们单我的的资金实力（除非你是王思聪）是一定搭建不起来CDN的，不过咱们可使用各大企业提供的服务，诸如腾讯云等，配置也十分简单，这里就请你们自行去推敲啦。

2.页面渲染性能优化

2.1.浏览器渲染过程（Webkit）

其实你们应该对浏览器将的HTML渲染机制比较熟悉了，基本流程同上图所述，你们在入门的时候，你的导师或者前辈可能会告诉你，在渲染方面咱们要减小重排和重绘，由于他们会影响浏览器性能。不过你必定不知道其中原理是什么，对吧。今天咱们就结合《Webkit技术内幕》（这本书我仍是很推荐你们买来看看，好歹做为一名前端工程师，你得知道咱们每天接触的浏览器内核是怎样工做的）的相关知识，给你们普及普及那些深层次的概念。

PS：这里提到了Webkit内核，我顺带提一下浏览器内部的渲染引擎、解释器等组件的关系，由于常常有师弟或者一些前端爱好者向我问这方面的知识，分不清他们的关系，我就拿一张图来讲明：（若是你对着不感兴趣，能够直接跳过）

浏览器的解释器，是包括在渲染引擎内的，咱们常说的Chrome（如今使用的是Blink引擎）和Safari使用的Webkit引擎，Firefox使用的Gecko引擎，指的就是渲染引擎。而在渲染引擎内，还包括着咱们的HTML解释器（渲染时用于构造DOM树）、CSS解释器（渲染时用于合成CSS规则）还有咱们的JS解释器。

2.2.DOM渲染层与GPU硬件加速

若是我告诉你，一个页面是有许多许多层级组成的，他们就像千层面那样，你能想象出这个页面实际的样子吗？这里为了便于你们想象，我附上一张以前Firefox的3D View插件的页面Layers层级图：

对，你没看错，页面的真实样子就是这样，是由多个DOM元素渲染层（Layers）组成的，实际上一个页面在构建完render tree以后，是经历了这样的流程才最终呈如今咱们面前的：

①浏览器会先获取DOM树并依据样式将其分割成多个独立的渲染层

②CPU将每一个层绘制进绘图中

③将位图做为纹理上传至GPU（显卡）绘制

④GPU将全部的渲染层缓存（若是下次上传的渲染层没有发生变化，GPU就不须要对其进行重绘）并复合多个渲染层最终造成咱们的图像

从上面的步骤咱们能够知道，布局是由CPU处理的，而绘制则是由GPU完成的。

其实在chrome中，也为咱们提供了相关插件供咱们查看页面渲染层的分布状况，以及GPU的占用率：（因此说，平时咱们得多去尝试尝试chrome的那些莫名其妙的插件，真的会发现好多东西都是神器）

chrome开发者工具菜单→more tools→Layers（开启渲染层功能模块）

chrome开发者工具菜单→more tools→rendering（开启渲染性能监测工具）

执行上面的操做后，你会在浏览器里看到这样的效果：

太多东西了，分模块讲吧：

（一）最早是页面右上方的小黑窗：其实提示已经说的很清楚了，它显示的就是咱们的GPU占用率，可以让咱们清楚地知道页面是否发生了大量的重绘。

（二）Layers版块：这就是用于显示咱们刚提到的DOM渲染层的工具了，左侧的列表里将会列出页面里存在哪些渲染层，还有这些渲染层的详细信息。

（三）Rendering版块：这个版块和咱们的控制台在同一个地方，你们可别找不到它。前三个勾选项是咱们最常使用的，让我来给你们解释一下他们的功能（充当一次免费翻译）

①Paint flashing：勾选以后会对页面中发生重绘的元素高亮显示

②Layer borders：和咱们的Layer版块功能相似，它会用高亮边界突出咱们页面中的各个渲染层

③FPS meter：就是开启咱们在（一）中提到的小黑窗，用于观察咱们的GPU占用率

可能你们会问我，和我提到DOM渲染层这么深的概念有什么用啊，好像跟性能优化没一点关系啊？你们应该还记得我刚说到GPU会对咱们的渲染层做缓存对吧，那么你们试想一下，若是咱们把那些一直发生大量重排重绘的元素提取出来，单独触发一个渲染层，那样这个元素不就不会“连累”其余元素一块重绘了对吧。

那么问题来了，什么状况下会触发渲染层呢？你们只要记住：

video元素、WebGL、Canvas、CSS3 3D、CSS滤镜、z-index大于某个相邻节点的元素都会触发新的Layer，其实咱们最经常使用的方法，就是给某个元素加上下面的样式：

这样就能够触发渲染层啦(__) 。

咱们把容易触发重排重绘的元素单独触发渲染层，让它与那些“静态”元素隔离，让GPU分担更多的渲染工做，咱们一般把这样的措施成为硬件加速，或者是GPU加速。你们以前确定听过这个说法，如今彻底清楚它的原理了吧。

2.3.重排与重绘

如今到咱们的重头戏了，重排和重绘。先抛出概念：

①重排（reflow）：渲染层内的元素布局发生修改，都会致使页面从新排列，好比窗口的尺寸发生变化、删除或添加DOM元素，修改了影响元素盒子大小的CSS属性（诸如：width、height、padding）。

②重绘（repaint）：绘制，即渲染上色，全部对元素的视觉表现属性的修改，都会引起重绘。

咱们习惯使用chrome devtools中的performance版块来测量页面重排重绘所占据的时间：

①蓝色部分：HTML解析和网络通讯占用的时间

②黄色部分：JavaScript语句执行所占用时间

③紫色部分：重排占用时间

④绿色部分：重绘占用时间

不管是重排仍是重绘，都会阻塞浏览器。要提升网页性能，就要下降重排和重绘的频率和成本，尽量少地触发从新渲染。正如咱们在2.3中提到的，重排是由CPU处理的，而重绘是由GPU处理的，CPU的处理效率远不及GPU，而且重排必定会引起重绘，而重绘不必定会引起重排。因此在性能优化工做中，咱们更应当着重减小重排的发生。

这里给你们推荐一个网站，里面详细列出了哪些CSS属性在不一样的渲染引擎中是否会触发重排或重绘：

csstriggers.com/ （图片来自官网）

2.4.优化策略

谈了那么多理论，最实际不过的，就是解决方案，你们必定都等着急了吧，作好准备，一大波干货来袭：

（一）CSS属性读写分离：浏览器每次对元素样式进行读操做时，都必须进行一次从新渲染（重排 + 重绘），因此咱们在使用JS对元素样式进行读写操做时，最好将二者分离开，先读后写，避免出现二者交叉使用的状况。最最最客观的解决方案，就是不用JS去操做元素样式，这也是我最推荐的。

（二）经过切换class或者style.csstext属性去批量操做元素样式

（三）DOM元素离线更新：当对DOM进行相关操做时，例如innerHTML、appendChild等均可以使用Document Fragment对象进行离线操做，待元素“组装”完成后再一次插入页面，或者使用display:none 对元素隐藏，在元素“消失”后进行相关操做。

（四）将没用的元素设为不可见：visibility: hidden，这样能够减少重绘的压力，必要的时候再将元素显示。

（五）压缩DOM的深度，一个渲染层内不要有过深的子元素，少用DOM完成页面样式，多使用伪元素或者box-shadow取代。

（六）图片在渲染前指定大小：由于img元素是内联元素，因此在加载图片后会改变宽高，严重的状况会致使整个页面重排，因此最好在渲染前就指定其大小，或者让其脱离文档流。

（七）对页面中可能发生大量重排重绘的元素单独触发渲染层，使用GPU分担CPU压力。（这项策略须要慎用，得着重考量以牺牲GPU占用率可否换来可期的性能优化，毕竟页面中存在太多的渲染层对于GPU而言也是一种没必要要的压力，一般状况下，咱们会对动画元素采起硬件加速。）

3.JS阻塞性能

JavaScript在网站开发中几乎已经肯定了垄断地位，哪怕是一个再简单不过的静态页面，你均可能看到JS的存在，能够说，没有JS，就基本没有用户交互。然而，脚本带来的问题就是他会阻塞页面的平行下载，还会提升进程的CPU占用率。更有甚者，如今node.js已经在前端开发中普及，稍有不慎，咱们引起了内存泄漏，或者在代码中误写了死循环，会直接形成咱们的服务器奔溃。在现在这个JS已经遍及先后端的时代，性能的瓶颈不仅仅只是停留在影响用户体验上，还会有更多更为严重的问题，对JS的性能优化工做不可小觑。

在编程的过程当中，若是咱们使用了闭包后未将相关资源加以释放，或者引用了外链后未将其置空（好比给某DOM元素绑定了事件回调，后来却remove了该元素），都会形成内存泄漏的状况发生，进而大量占用用户的CPU，形成卡顿或死机。咱们可使用chrome提供的JavaScript Profile版块，开启方式同Layers等版块，这里我就再也不多说了，直接上效果图：

咱们能够清除看见JS执行时各函数的执行时间以及CPU占用状况，若是我在代码里增长一行while(true){}, 那么它的占用率必定会飙升到一个异常的指标（亲测93.26%）。

其实浏览器强大的内存回收机制在大多数时候避免了这一状况的发生，即使用户发生了死机，他只要结束相关进程（或关闭浏览器）就能够解决这一问题，但咱们要知道，一样的状况还会发生在咱们的服务器端，也就是咱们的node中，严重的状况，会直接形成咱们的服务器宕机，网站奔溃。因此更多时候，咱们都使用JavaScript Profile版块来进行咱们的node服务的压力测试，搭配node-inspector 插件，咱们能更有效地检测JS执行时各函数的CPU占用率，针对性地进行优化。

（PS：没修炼到必定水平，千万别在服务端使用闭包，一个是真没啥用，咱们会有更多优良的解决办法，二是真的很容易内存泄漏，形成的后果是你没法预期的）

4.【拓展】负载均衡

之因此将负载均衡做为拓展内容，是由于若是是你本身搭建的我的网站，或者中小型网站，其实并不须要考虑多大的并发量，可是若是你搭建的是大型网站，负载均衡即是开发过程不可或缺的步骤。

4.1.Node.js处理IO密集型请求

如今的开发流程都注重先后端分离，也就是软件工程中常提到的“高内聚低耦合”的思想，你也能够用模块化的思想去理解，先后解耦就至关于把一个项目分红了前端和后端两个大模块，中间经过接口联系起来，分别进行开发。这样作有什么好处？我就举最有实际效果的一点：“异步编程”。这是我本身想的名字，由于我以为先后解耦的形式很像咱们JS中的异步队列，传统的开发模式是“同步”的，前端须要等后端封装好接口，知道了能拿什么数据，再去开发，时间短，工程大。而解耦以后，咱们只须要提早约定好接口，先后两端就能够同时开发，不只高效并且省时。

咱们都知道node的核心是事件驱动，经过loop去异步处理用户请求，相比于传统的后端服务，它们都是将用户的每一个请求分配到异步队列进行处理，推荐你们去看这样一篇博文：Node.js : 我只须要一个店小二。特别生动地讲解了事件驱动的运行机制，通俗易懂。事件驱动的最大优点是什么？就是在高并发IO时，不会形成堵塞，对于直播类网站，这点是相当重要的，咱们有成功的先例——快手，快手强大的IO高并发究其本质必定能追溯到node。

其实如今的企业级网站，都会搭建一层node做为中间层。大概的网站框架如图所示：

4.2.pm2实现Node.js“多线程”

咱们都知道node的优劣，这里分享一份连接，找了挺久写的还算详细：https://www.zhihu.com/question/19653241/answer/15993549。其实都是老套路，那些说node不行的都是指着node是单线程这一个软肋开撕，告诉你，咱们有解决方案了——pm2。这是它的官网：pm2.keymetrics.io/ 。它是一款node.js进程管理器，具体的功能，就是能在你的计算机里的每个内核都启动一个node.js服务，也就是说若是你的电脑或者服务器是多核处理器（如今也少见单核了吧），它就能启动多个node.js服务，而且它可以自动控制负载均衡，会自动将用户的请求分发至压力小的服务进程上处理。听起来这东西简直就是神器啊！并且它的功能远远不止这些，这里我就不做过多介绍了，你们知道咱们在上线的时候须要用到它就好了，安装的方法也很简单，直接用npm下到全局就能够了$ npm i pm2 -g具体的使用方法还有相关特性能够参照官网。这里我在build文件夹内添加了pm2.json文件，这是pm2的启动配置文件，咱们能够自行配置相关参数，具体可参考github源码，运行时咱们只要在上线目录下输入命令$ pm2 start pm2.json便可。

下面是pm2启动后的效果图：

4.3.nginx搭建反向代理

在开始搭建工做以前，首先得知道什么是反向代理。可能你们对这个名词比较陌生，先上一张图：

所谓代理就是咱们一般所说的中介，网站的反向代理就是指那台介于用户和咱们真实服务器之间的服务器（说的我都拗口了），它的做用即是可以将用户的请求分配到压力较小的服务器上，其机制是轮询。听完这句话是否是感受很耳熟，没错，在我介绍pm2的时候也说过一样的话，反向代理起到的做用同pm2同样也是实现负载均衡，你如今应该也明白了二者之间的差别，反向代理是对服务器实现负载均衡，而pm2是对进程实现负载均衡。你们若是想深刻了解反向代理的相关知识，我推荐知乎的一个贴子：www.zhihu.com/question/24… 。可是你们会想到，配服务器是运维的事情啊，和咱们前端有什么关系呢？的确，在这部分，咱们的工做只有一些，只须要向运维提供一份配置文档便可。

也就是说，在和运维对接的时候，咱们只须要将上面这几行代码改成咱们配置好的文档发送给他就好了，其余的事情，运维小哥会明白的，不用多说，都在酒里。

可是，这几行代码该怎么去改呢？首先咱们得知道，在nginx中，模块被分为三大类：handler、filter和upstream。而其中的upstream模块，负责完成完成网络数据的接收、处理和转发，也是咱们须要在反向代理中用到的模块。接下来咱们将介绍配置代码里的内容所表示的含义

4.3.1.upstream配置信息：

upstream关键字后紧跟的标识符是咱们自定义的项目名称，经过一对花括号在其中增添咱们的配置信息。

ip_hash 关键字：控制用户再次访问时是否链接到前一次链接的服务器

server关键字：咱们真实服务器的地址，这里的内容确定是须要咱们去填写的，否则运维怎么知道你把项目放在那个服务器上了，也不知道你封装了一层node而得去监听3000端口。

4.3.2.server配置信息

server是nginx的基本配置，咱们须要经过server将咱们定义的upstream应用到服务器上。

listen关键字：服务器监听的端口

location关键字：和咱们以前在node层说到的路由是起一样的功能，这里是把用户的请求分配到对应的upstream上