Vue SSR 从入门到 Case Study

最近两个项目同时开发，使用了Vue2的SSR，这样后端渲染页面首屏能够加快页面呈现，增长SEO和用户体验，可是项目上线后却发现了严重的性能问题，因而在三天内两次重大调整，最后只能放弃Vue SSR，本文从Vue SSR实现开始，逐渐复盘整个事件。
两周前就预告了要写一篇Vue SSR的文章，可是没想到上周四上线以后，周六放量以后发现性能问题，这周一到周三，作了两次重大调整，最终仍是放弃了SSR，而且作了此次事件复盘。

技术选型

调研Vue已经好久了，随着Vue2正式发布，使用Vue来作项目又燃起了但愿，不是为了一时的技术理想和情怀（了解个人人都知道，我不是这样的人），主要是出于下面几方面考虑：

1. 用artTemplate+Sass+JS作的components方案已经作了好久了，沉淀了不少组件，随着Node服务开始上线，一直想在此基础上作同构，而公司Node框架Yog2的view层选择偏向于Smarty模板的Swig，修改比较麻烦
2. 既然改不了，那么要换不如直接选择新的components方案，此次最强烈需求是：组件化和支持SSR，而Vue2以后支持SSR
3. 此次两个项目同时进行，并且仅仅给两周的开发时间，组件化有效提升工做效率，能够把通用的组件抽象出来，多个页面之间业务组件复用率也很高，并且业务组件在后续的运营活动也能够直接复用
4. 手百产品形态复杂，页面即在手百内使用又有手百外使用，手百内页面被多个Webview隔开，不适合SPA形式，而手百外适合SPA形式，因此一套代码须要适配两种状况，Vue 能够适应这两种方式
5. Vue的SPA形式能够方便进行PWA和Hybrid改造（继续关注本公众号Hybrid系列）

因此，最后决定：上Vue！技术栈：Vue2+Yog2。

再介绍下两个项目：

• 项目A是老项目进行重构，产品需求要跟功能所有保留，架构跑通使用的是Vue2.1，因此A项目代码相对复杂，一直没有使用Vue2.2
• 项目B是新项目，开始使用Vue2.1，上线后发现已经有Vue2.2，因而升级Vue2.2，而且把项目目录结构调整一番，Webpack config等均可配
  Vue SSR入门到上线

先看下Vue SSR的实现流程图：

简单解释一下：

1. app.js是Server和Client公用的
2. webpack会根据server-entry.js和client-entry.js打包出来两个文件：server-bundle和client-bundle
3. server-bundle用于后端渲染（2.1是js文件，2.2变成json，引入更加方便）

可是这张图没有说明在调用API接口方面，先后端是怎么公用代码的。前端走的是Ajax请求，后端走的是http请求（百度内部是RAL接口服务管理），结合上图补充完整的代码执行流程图以下：

webpack区分接口请求方式

在浏览器内使用ajax请求，而在服务端须要调用内部API请求或者直接读取存储（RAL）。ajax请求到达服务端依次通过：action层、model层，最后走到仍是API请求或者读取数据（这里重点读三遍。。）。

这里咱们将服务端和客户端API的请求方法写在不一样的文件内，可是封装暴漏的接口都是同样的（接口模式）。在webpack里面，针对server和client提供不一样的alias：

这样 require('api/demo') 的时候，会区分开server和client。

server内直接使用yog2 modal内的获取数据方法，好比：

而client内，直接使用ajax请求：

Vue内使用Vuex来获取数据

即下图的流程：

在渲染的时候，prefetch阶段经过dispatch触发Store的Action（Action内容许异步），Action内调用 api/demo 获取数据成功后commit mutation，这样整个数据就跑通了。

server.js

server.js是第一次渲染使用的入口action，核心代码以下：

//vue2.2
const vueServerRender = require('vue-server-renderer');
const bundle = require('../vue-ssr-bundle.json');
const renderer = vueServerRender.createBundleRenderer(bundle, {
    template: '<!--vue-ssr-outlet-->',
    cache: require('lru-cache')({
        max: 1000,
        maxAge: 1000 * 60 * 15
    })
})
// 先渲染tpl(swig模板)，内容相似vue ssr demo的index.html
// 这里渲染使用chunk，先输出不依赖数据的头部html
res.render('page/index.tpl', { isSendSpeedCode }, (err, html) => {
    if (!err) {
        var htmls = html.split('<!--vue-ssr-outlet-->')
        //先渲染头部html
        res.write(htmls[0])

        // swig渲染时间
        var time1 = Date.now()
        const renderStream = renderer.renderToStream(context)
        renderStream.on('data', chunk => {
            // 边解析，边渲染html
            res.write(chunk)
        })
        renderStream.on('end', () => {

            if (isSendSpeedCode) {
                // 统计vue 渲染时间
                var time2 = Date.now()
                var code = ` <script>if(window.alog){ alog('speed.set', 'p_swig', ${time1 - time0}); alog('speed.set', 'p_vue', ${time2 - time1}); }</script> `
                res.write(code)
            }
            // 渲染尾部html
            res.end(htmls[1])
        }).on('error', errorHandler)
    } else {
        errorHandler(err)
    }
})复制代码

Webpack和FIS3两次编译

webpack是vue「全家桶」的后遗症，项目太急没办法去掉。咱们项目的目录结构以下：

项目须要两次打包：

1. 第一次是webpack，webpack把 vue-src文件夹内容根据 server-entry和 client-entry打包出来，分别放进yog2的client和server对应的文件，以后 vue-src在执行环境就不须要了
2. 第二次是FIS3的打包，会按照Yog2的规范release出来能够上线的内容

这里有个细节：webpack打包出来的静态资源路径须要跟FIS3打包的静态资源路径一致，否则就无法经过FIS3进行静态资源定位，好比替换为CDN地址。
因为vue2.2打出来的server-bundle是json格式文件，因此FIS没法将json内的静态资源进行统一管理，须要webpack判断生产环境直接替换为CDN地址

碰见的其余问题和技巧

client代码在server上跑

手百的通用库Bdbox是client代码，代码中有一些window全局变量的使用，而咱们知道Node是没有 window的，在Node执行SSR的时候，会报错，好比下面的代码：

// 自执行
isAndroid: /(Android);?[\s\/]+([\d.]+)?/.test(navigator.userAgent)复制代码

有两种改法：

1. 把.isAndroid由属性变成方法：.isAndroid()，放到mount内执行
2. 给vue-server-renderer传入带有navigator.userAgent的context

利用resolve.alias

目录结构深了，尤为是Vue里面还须要调用yog model的代码，会各类../../很蛋疼，能够利用alias简化写法：

须要注意的是static的写法是：<img src=“~static/img/logo.png”

利用Yog2 的 Mock功能进行测试

订好接口请求参数和返回数据格式以后，后端RD进行API的编写同时，咱们能够利用Yog2的Mock功能，对ral返回的数据进行假数据测试，实现后端和前端RD解耦，大大提升开发效率。

Vue SSR从上线到Case Study

如今来复盘下整个事件：

1. 4月5日，完成代码开发，全功能提测，开始倒腾上线，晚上第一次上线成功，基本功能回归没问题，
2. 紧接着几回bug修复上线，6号周四上线日，基本没有问题了
3. 4月7日开始APP审核经过，放量开始，这时候发现随着流量上升，服务器扛不住了
4. 8日（周六）紧急添加实例，周末算是硬扛过去了
5. 10（周一）排查缘由，发现内存可能存在泄漏和性能问题，增长打点统计后端渲染时间，可是VM相对来讲是黑盒，性能很差排查
6. 11日（周二）增长lru-cache，细化组件缓存，下午上线后，晚上发现内存曲线更加严重，因而晚上10点回滚lru和组件缓存代码，随版本收敛影响，流量继续上涨，增长机器实例
7. 12日（周三）采起降级方案，第一次进入页面将API数据放到以变量形式放到页面，而后增长beforeCreate阶段代码，将页面数据直接commit给mutation进行渲染，曲线开始平缓
8. 13日（周四）观察一晚曲线没有问题，中午开始缩容（下线实例）

从周一到周三通过两次大的调整，终于服务稳定了，其中代码review阶段，咱们也发现了不少代码不规范的现象。下面来讲下咱们使用vue ssr的一些压测等数据。

单实例QPS、内存和CPU数据

从上线以后，内存积累到必定时间就飙升，内存飙升同时，CPU也进行飙升，具体曲线以下：

从12日（周三19点）上线以后，就开始平稳了，13日中午缩容后，CPU稍有上扬。

同期QPS的数据以下：

查看全文，关注微信公众号：「三水清」（sanshuiqing123）