Node直出理论与实践总结
joeyguo opened this issue · comments
直出是什么？到底是怎样的性能优化？本文将结合从在浏览器输入url，到展示最终页面的过程来对其进行一步步分析，并将在手Q web 中的实际应用实践进行总结。
模式 1 - 前后分离
从用户输入 url 到展示最终页面的过程，这种模式可简单的分为以下 5 部分
- 用户输入 url，开始拉取静态页面
- 静态页面加载完成后，解析文档标签，并开始拉取 CSS （一般 CSS 放于头部）
- 接着拉取 JS 文件（一般 JS 文件放于尾部）
- 当 JS 加载完成，便开始执行 JS 内容，发出请求并拿到数据
- 将数据与资源渲染到页面上，得到最终展示效果
具体流程图如下
这种处理形式应该占据大多数，然而也很容易发现一个问题就是请求数多，前后依赖大，如必须等待 JS 加载完成后执行时才会发起 数据请求，等待数据回来用户才可以展示最终页面，这种强依赖的关系使得整个应用的首屏渲染耗时增加不少。
模式 2 - 数据直出
数据请求在server端上提前获取，并和html一同返回，页面模板和数据的渲染在浏览器端上执行
在模式 1 中，第 1 点用户输入 url 时 server 端不做其他处理直接返回 html ，在第 4 点向 server 请求获取数据。那么，同样都是向 server 请求获取，如果在第 1 点中将请求数据放在 server 上，将拿到的数据拼接到 HTML 上一并返回，那么可减少在前端页面上的一次数据请求时间。 这就是模式 2 - 数据直出所做的事，处理方式也很简单
- 用户输入 url ，在 server 返回 HTML 前去请求获取页面需要的数据
- 将数据拼接到 HTML 上 并 一起返回给前端
（可以插入 script 标签将数据添加到全局变量上，或放到某个标签的 data 属性中，如 ） - 在前端的JS代码中判断是否已在服务端拿到数据，直接拿该数据进行渲染页面，不再做数据请求
具体可下面的流程图看出这种模式下
这种模式与模式1 相比，减少了这两种模式请求数据的耗时差距。这块差距有多少呢？
发起一个 HTTP 的网络请求过程
DNS解析（100~200ms可以缓存）
|
|
建立TCP链接 (三次握手100~200ms )
|
|
HTTP Request( 半个RTT )
|
|
HTTP Response( RTT 不确定优化空间 )
注: RTT 为 Round-trip time 缩写，表示一个数据包从发出到返回所用的时间。
HTTP 请求在前后端发出，差距有多少？
由上面对 HTTP 的网络请求过程可看到建立一次完整的请求返回在耗时上明显的，特别是外网用户在进行 HTTP 请求时，由于网络等因素的影响，在网络连接及传输上将花费很多时间。而在服务端进行数据拉取，即使同样是 HTTP 请求，由于后端之间是处于同一个内网上的，所以传输十分高效，这是差距来源的大头，是优化的刚需。
模式 3 - 直出 (服务端渲染)
数据请求在server端上提前获取，页面模板结合数据的渲染处理也在server上完成，输出最终 HTML
模式 2 中将依赖于JS文件加载回来才能去发起的数据请求挪到 server 中，数据随着 HTML 一并返回。然后等待 JS 文件加载完成，JS 将服务端已给到的数据与HTML结合处理，生成最终的页面文档。
数据请求能放到 server 上，对于数据与HTML结合处理也可以在server上做，从而减少等待 JS 文件的加载时间。 这就是模式3 - 直出 (服务端渲染)，主要处理如下
- server 上获取数据并将数据与页面模板结合，在服务端渲染成最终的 HTML
- 返回最终的 HTML 展示
可以从下图看出，页面的首屏展示不再需要等待 JS 文件回来，优化减少了这块时间
通过以上模式，将模式 1 - 常用模式中的第 3 和 4 点耗时进行了优化，那么可以再继续优化吗？
在页面文档不大情况下，可将CSS内联到HTML中，这是优化请求量的做法。直出稍微不同的是需要考虑的是服务端最终渲染出来的文档的大小，在范围内也可将 CSS 文件内联到 HTML 中。这样的话，便优化了 CSS 的获取时间，如下图
小结
直出能够将常用模式优化到剩下了一次 HTML 请求，加快首屏渲染时间，使用服务端渲染，还能够优化前端渲染难以克服的 SEO 问题。而不管是简单的 数据直出 或是 服务端渲染直出 都能使页面的性能优化得到较大提高，以下将从实际应用中进行说明。
以手Q家校群的数据直出优化为例
由于项目上线时间紧，所以在第一次优化上使用了数据直出的简单方式来优化首屏渲染时间。具体处理与 模式 2 数据直出方式 一致，与其不同的是这里使用了由 AlloyTeam 开发的 基于KOA的玄武直出服务 来作为前端与服务端间的中间层。形式如下
使用这种中间层的方式，在项目的开发过程中依然可使用前后端分离的方式，开发完后再将页面请求指向这个中间层服务上。中间层服务主要做了上述 模式 2 - 数据直出 中的处理
- 使用前端文件及调用服务端做好的拉取数据接口
- 将数据与前端文件结合并返回给请求来源
由于该中间层服务与具体server部署在相同的内网上，所以它们直接的数据交互是十分高效的，从而可达到 模式 2 - 数据直出 中所述的优化。
另一点，做为中间层玄武直出服务通过公司的L5负载均衡服务，完美兼容直出与非直出版本，即当直出服务挂掉了，也可以顺利走非直出版本，确保基本的用户体验，也能够更好的支持 A/BTest。
性能数据
简单的数据方式直出同样迎来了较大的性能提升，手Q家校群列表页在首屏渲染完成时间上，相比于优化前的版本，数据直出有大概 650ms 的优化，提升约 35% 的性能。
总结
在前后端没有分离时 使用后端渲染出模板的方式是与文中所述的直出方案效果是一致的，前后端分离后淡化了这种**，Node 的发展让更多的前端开始做后端事情，直出的方式也越来越被重视了。
历史的车轮滚滚向前，直出方案看似回到了服务端渲染的原点，实际上是在以前的基础上盘旋上升。有了更多的能力，便可以有更多的思考。期待前端会越来越强大，这不，react-native也让前端开始着手客户端的事儿了 ~
后记
手Q家校群使用 React + Redux + Webpack架构，既然是 React，肯定不可忽略 React 同构 （服务端渲染） 关于React 同构直出的具体实践，我将其总结在另外一篇文章上，可点击查看 React同构直出优化总结
对于文章一开始提及的前端路由，对路由的实现原理感兴趣的也可点击查看 前端路由实现与 react-router 源码分析
感谢指教！
好东西，感谢分享
流程图使用什么软件画的？
@xiongwilee PPT
前端小白不太懂，公司之前的网页是用php开发后台，前端发请求直接获取网页渲染后的内容，貌似是第二种直出的方式（因为只看过他们的部分代码，请求返回的就是页面结构的东西，并没有参与开发）。
现在新版本要求我用ionic2+angular2做跨平台开发，感觉还是请求数据，然后我这边写页面结构样式逻辑啊，步骤：数据ulr回车>请求组件的代码>渲染页面结构>请求服务器数据>数据渲染显示页面。感觉回到第一种方式了？？？
我在本地开启服务器截图network如下：
忘大神指点，meric:thumbsup:
@RunningV Hi, 是走了第一种方式。不过实际上，我们在第一期开发阶段都可以是以第一种方式来开发，这样前后端分离，开发效率会比较高些，后续如果要优化首屏时间，可以再优化做成第三种方式，不过需要考虑下angular2现在的服务端渲染方案是否成熟
请教下你们的Node服务是直接操作数据库（写 SQL 增删改查），还是有另外的服务提供接口？这个服务是如何访问的？HTTP 吗，那不是增加了一次 HTTP 交互？我一直不明白加个Node服务该怎么架构。
@xiaoyann 好问题。我这边是用Node服务作为中间层，是与另外服务进行HTTP请求的，这种方式接入是最快捷的。可从我的另外一篇文章 <React同构直出优化> 中可以看到这块HTTP耗时约60ms，主要是因为这两个server同处一个内网，所以交互非常快。当然，比速度的话是比不上直接操作DB的。
文章写的不错，很有启发。
好文！请教下：我们的后台，开发技术栈是java web，貌似只能做到模式一啊，如果想实现直出，是不是需要换后台的技术栈？
66666
顺便推荐下koa-grace，基于koa实现，专门用来做这种前后端分离架构的 https://github.com/xiongwilee/koa-grace
@jackgreentemp 可以用 node 做一个中间层和后台交互，像文中那样，起多一个中间层服务，让页面请求指向这个中间层，中间层可由前端来写，和前后端交互，这样成本低一些
手Q直出配合Node的这种，有小的example开源一下吗？
@oConnerCooper 是指中间层node吗？这个的话，和我们这边业务有比较强的耦合，后面需要再整理才能成开源版本 ：D
没啥，就来赞一下~
感觉一切又回到了原点啊：古老的jsp页面貌似就是服务端渲染好HTML之后，再和内联的css和js一并返回给客户端的。
模式一准确来说应该叫前后端解耦，而不是前后端分离。：）
这里指的直出就是入口页由服务端套页面的意思吧~
我想问下现在流行的框架vue和angular都是第一种模式，那么转为第二种模式是不是成本很高呢，你上面说的是不是只是首屏优化为第二种模式，其它的就不用呢
@wuyingfeng1992 第二种模式是不依赖框架的，只需要返回html时注入数据就行。第三种同构的方案 angular/universal 和 vue ssr 都可以支持。第二种和第三种都是首屏优化的方案
图画错了，第一种模式中用于纯前端渲染的html+js+css应该放cdn，是纯静态文件
@sopaco 这个与缓存策略有关，cdn一般设置的缓存时间较长，如果把html同放cdn上，会有html不及时更新的问题。当然如果业务无需要考虑及时更新的问题，那也是可以把html放到cdn上的。
@joeyguo 想请教一下，像这种服务端同构直出最重要的应用场景是什么，貌似大部分是为了首屏优化的，还有其他什么可适用的场合吗，PC端管理系统适用吗？最近一直在调研，请教大神
好文章！很清晰地理解了数据直出与同构直出的概念，感谢！
想请教一下，现在如果用这个node.js做同构的话，这个node.js肯定是要用来当服务器的。我不知道这个node.js 的稳定性以及抗压性怎么样。到现在还在使用forever等工具来保持服务稳定。我可以相信node吗，会不会出现频繁宕机的情况？
@SnowFlowers 可以的。另外也可以在同构服务挂了的时候让资源请求转发到正常服务上，即做一层防护。
写的真好，谢谢分享
@Mmzer 应该算作螺旋上升式的回归~
👍 谢谢分享
如果请求server的数据很慢的话，这种模式不是会导致白屏时间长吗？第一种模式至少已经可以看到页面的loading啊
@fanbinghuadev 中间层服务与具体server部署一般部署在相同的内网上，数据交互是很快的。如果场景是server很慢，是会导致白屏时间长。
React项目，如果以“可交互”为指标，应该是浏览器端渲染方案更好。 感觉首屏不可交互就是一个伪指标，用一个 logo-loading（类似twitter） 不是更好吗？