前端工程师的自我修养-SSR在可视化大屏搭建中的实践

前言

​ 这篇关于SSR的文章计划好久了，但是一直没着落。一方面，网上已经有很多相关的文章，还写的挺不错；另一方，之前对SSR也一直处于理论阶段，没有实操，担心写出来误导群众。从去年10月份开始，一直在做大屏搭建相关的工作，在这过程中积累了一些SSR的使用心得，这里拿出来和大家分享一下，与君共勉。

背景介绍

话不多说，直接上图

这张图就是我去年下半年一直在做的事儿。通过可视化的方式搭建出一张数据大屏。目的有两个：

1. 组件复用
2. 快速部署
3. 节约成本，毕竟某云的可视化解决方案也不便宜

在之前的文章中我同事分享过一篇可视化搭建数据大屏系统BIG的文章，这里不再详细介绍，有兴趣的可以转场去看看。这张图展现的是如何通过可视化操作将一个个组件组合在一起，行成一面具有信息价值的大屏。今天要讲的是这张图背后，关于服务端渲染(SSR)在搭建场景中的应用。接下来会从下面几个方面来讲：

1. SSR在搭建可视化页面中扮演的角色
2. 如何让SSR覆盖多场景
3. 如何在服务端渲染时何实现组件加载
4. SSR在搭建系统中有什么不一样

系统使用的技术栈是Vue+Nodejs+Mysql，下面的讲解也是基于使用的技术栈。

##SSR在搭建可视化页面中扮演的角色

每种技术都有他的特定使用场景，在使用前一定要搞明白一个问题，那就是我们的业务到底是否需要它。SSR目前被人熟知的使用场景有两个：

1. 页面对SEO有强烈诉求
2. 追求极致的内容到达

那么搭建系统是否满足这两种场景呢？答案是肯定的。搭建系统主要负责营销活动和门户大厅页的搭建，这些页面对SEO和更快的内容到达时间都有诉求。所以在搭建系统中引入SSR方案，没毛病。那么SSR在整个搭建系统中扮演者什么角色呢？这有点废话的意思，当然是渲染咯，不然怎么叫服务端渲染。

服务端渲染在搭建系统中扮演下面两种角色：

1. 动态直出
2. 静态直出

动态直出

动态直出就是当页面请求到达时服务端时，服务端实时获取页面所需数据和页面模板，动态的将页面渲染出来。最后返回给客户端，大致架构如下：

这样的好处是可以获取实时数据进行渲染。缺点在高并发的场景下需要考虑负载、健壮性、降级等一系列问题，因为在这个时候流量全部打到了Node服务上。

静态直出

相比较于动态直出，静态直出就要简单许多。就是在可视化界面上搭建好页面后，将页面数据保存到数据库，在发布页面的时候，将对应的数据和页面模板通过SSR生成静态页面保存起来。当页面请求到达服务端的时候不再走服务端渲染，直接通过静态服务返回已经生成好的静态页面。这样这样的好处就是可以大大降低服务端的压力和维护成本。缺点就是页面内容相对固定，为什么说是相对固定呢？后面再讲。

上面这两种方案，在我们的搭建系统中都有用到。动态直出用在了搭建系统的编辑和预览场景下。静态直出用在了发布场景下。下面具体讲讲为什么要这么用。

编辑和预览

编辑页：

预览页：

首先说一下编辑和预览为什么用到了SSR方案。从实现的角度的来说，做成CSR也没毛病。但是为什么要考虑服务端渲染呢？两个原因

1. 页面渲染效率

   通过CSR的方式，需要先获取需要编辑页面数据，然后根据数据按需异步加载用到的组件，这个过程是需要时间的，页面使用的组件越多，编辑页面渲染完成的时间就越长，体验就越差。那是不是可以考虑把所有组件都同步加载进来，进行全局注册呢？答案是肯定不行，因为组件库中的组件每天在不断的增长，一方面不利于组件的更新和扩展，另一方面全部打包进来bundle得多大呀。

2. 可以尽可能保证编辑页面和最终发布页面的代码逻辑一致

   两者都是通过SSR渲染，所以在代码层面两者可以最大程度做到一致。

所以编辑和预览场景下选择了SSR方案去实现。那为什么要选择动态直出，而不是静态直出呢？编辑页和预览页都是临时生成的一个页面，从实现上讲，动态直出和静态直出都没问题，但是关键是"临时"二字，"临时"代表这个页面的存在时间比较短，编辑是在搭建页面才用到，预览也是临时看一下页面的整体效果，动态渲染一次性输出完事儿，无需存档。当然也不存在渲染压力，就内部使用一下能有多大压力，毛毛雨啦。

发布场景

懒得画图了，直接盗用一张公司鲁班之父的之前画的

发布后的页面为什么是通过SSR渲染成静态页面，而不是动态渲染一把梭？一句话就是"没必要"。静态直出已经能满足我们的当前的