分享 vivo 互联网技术干货与沙龙活动,推荐最新行业动态与热门会议。
分类: JavaScript
2020-12-22 09:36:35
在前面几篇文章中,相信大家对vivo官网商城的前端架构演变有了一定的了解,从稳步推进前后端分离到小程序多端探索实践,团队不断创新尝试。
在本文中,我们来分享一下vivo官网商城在Node 服务端渲染(Server Side Rendering, SSR)方面的实战经验。本文主要围绕以下几个方面进行阐述:
vivo官网商城目前前后端分离采用的是SPA单页模式,SPA会把所有 JS 整体打包,无法忽视的问题就是文件太大,导致渲染前等待很长时间。特别是网速差的时候,让用户等待白屏结束并非一个很好的体验。因此 vivo 官网商城前端团队尝试引入了SSR技术,以此来加快页面首屏的访问速度,从而提升用户体验。
页面渲染主要分为客户端渲染(Client Side Render)和服务端渲染(Server Side Rendering):
服务端只返回一个基本的html模板,浏览器根据html内容去加载js,获取数据,渲染出页面内容;
页面的内容是在服务端渲染完成,返回到浏览器直接展示。
与传统 SPA (单页应用程序 (Single-Page Application)) 相比,SSR的优势主要在于:
CSR和SSR页面渲染对比:
vivo官网商城项目的技术栈是Vue, 考虑到从头搭建一套服务端渲染的应用比较复杂,所以选择了Vue官方推荐的 框架,这是基于 Vue 生态的更高层的框架,为开发服务端渲染的 Vue 应用提供了极其便利的开发体验。
这里不做基础使用的分享,有兴趣的同学可以到 学习基础用法;我们主要聚焦于在整个实践过程中,主要遇到的一些挑战:
虽然Vue SSR渲染速度已经很快,但是由于创建组件实例和虚拟DOM节点的开销,与基于字符串拼接的模板引擎的性能相差很大,在高并发情况下,服务器响应会变慢,极大的影响用户体验,因此必须进行性能优化。
a、页面缓存: 在创建render实例时利用 来缓存渲染好的html,当再有请求访问该页面时,直接将缓存中的html字符串返回。
nuxt.config.js增加配置:
1
|
serverMiddleware: ["~/serverMiddleware/pageCache.js"]
|
根目录创建serverMiddleware/pageCache.js
b、组件缓存: 将渲染后的组件DOM存入缓存,定时刷新,有效期内取缓存中DOM。主要适用于重复使用的组件,多用于列表,例如商品列表。
配置文件nuxt.config.js:
1
2
3
4
5
6
7
8
9
10
11
|
const LRU = require('lru-cache')
module.exports = {
render: {
bundleRenderer: {
cache: LRU({
max: 1000, // 最大的缓存个数
maxAge: 1000 * 60 * 5 // 缓存5分钟
})
}
}
}
|
缓存组件增加name及serverCacheKey作为唯一键值:
1
2
3
4
5
|
export default {
name: 'productList',
props: ['productId'],
serverCacheKey: props => props.productId
}
|
c、API缓存: Node服务器需要先调用后台接口,获取到数据,然后才能进行渲染,获取接口速度的快慢,直接影响到渲染的时间,对接口的缓存可以加快每个请求的处理速度,更快地释放掉请求,从而提高性能。API缓存主要适用于数据基本保持不变,变更不是很频繁,与用户个人数据无关的接口。
同一个页面,在Node层可能会同时调用多个接口,如果是串行调用,需要等待的时间会比较长,如果是并发请求,会缩小等待时间。
例如:
1
2
3
|
let data1 = await $axios.get('接口1')
let data2 = await $axios.get('接口2')
let data3 = await $axios.get('接口3')
|
可以改成:
1
2
3
4
5
|
let {data1,data2,data3} = await Promise.all([
$axios.get('接口1'),
$axios.get('接口2'),
$axios.get('接口3')
])
|
影响用户体验主要是首屏的白屏时间,而第二屏、第三屏...,并不需要立即显示。以商品详情页为例,如下图:
可以对页面结构进行拆分,首屏元素采用SSR,非首屏元素通过CSR;SSR数据需要通过asyncData方法来获取,CSR数据可以在mounted中获取。
CSR写法如下:
1
2
3
|
客户端渲染dom
|
并不是所有页面对体验、SEO要求都很高,像商城这样的业务,可以只对首页、商品详情页等核心页面做SSR,这样可以大大减少服务端的压力。
优化前:
优化后:
从上图可以看出,未经优化前QPS只有125,经过一系列优化QPS达到了6000,提升了接近 50倍。
这里的降级是指将SSR降级为CSR,使用Node做SSR,瓶颈在于CPU和内存,在高并发情况下,很容易导致CPU飙升,用户访问页面时间变长,如果Node服务器挂了,直接会导致页面访问不了。所以为了保证项目上线之后平稳运行,需要提供容灾、降级方案。
Nuxt.js可以同时支持CSR和SSR,我们在打包时,既生成SSR的包,同时生成CSR的包,分别进行部署。
项目中采用了以下几种降级方案:
Node服务器上启动一个服务,用来监测Node进程的CPU和内存使用率,设定一个阈值,当达到这个阈值时,停止SSR,直接将CSR的入口文件index.html返回,实现降级。
例如618,双11等大促期间,我们事先知道流量会很大,可以提前通过修改Nginx配置,将请求转发到静态服务器,返回index.html,切换到CSR。
当偶发性的Node服务器返回5xx错误码,或者Node服务器直接挂了,我们可以通过如下Nginx配置,做到自动切换到CSR,保证用户能正常访问。
Nginx配置如下:
1
2
3
4
5
6
7
8
9
10
|
location / {
proxy_pass Node服务器地址;
proxy_intercept_errors on;
error_page 408 500 501 502 503 504 =200 @spa_page;
}
location @spa_page {
rewrite ^/* /spa/200.html break;
proxy_pass 静态服务器;
}
|
在url中增加参数isCsr=true,Nginx层对参数isCsr进行拦截,如果带上该参数,指向CSR,否则指向SSR;这样就可以通过url参数配置来进行页面分流,减轻Node服务器压力。
基于公司的CI/CD,我们实现了Docker部署和Shell脚本部署两种自动化部署方案。
对于Shell脚本的方式,我们主要解决的问题是如何通过脚本来安装指定Node的版本,这里我们可以分为两步:
1
2
|
1、安装nvm, nvm 是Node.js 的版本管理器(version manager)
2、通过nvm安装或者切换成对于的Node版本
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
# 定义安装nvm的方法
install_nvm() {
echo "env $app_env install nvm ..."
wget --header='Authorization:Basic dml2b2Rldm9wczp4TFFidmtMbW9ZKn4x' -nv -P .nvm
unzip -qo .nvm/nvm-master.zip
mv nvm-master/* $NVM_DIR
rm -rf .nvm
rm -rf nvm-master
. "$NVM_DIR/nvm.sh"
if [[ $? = 1 ]];
then
echo "install nvm fail"
else
echo "install nvm success"
fi
}
|
1
2
3
4
5
6
7
8
9
10
11
|
# 定义安装Node的方法
install_node() {
# command_args为用户自定义的Node版本号
local USE_NODEVER=$command_args
echo "will install NodeJs $USE_NODEVER"
nvm install $USE_NODEVER >/dev/null
echo "success change to NodeJs version" $(node -v)
}
|
1
2
3
4
5
6
7
8
9
10
11
12
|
# Node环境安装
prepare() {
if [[ -s "$NVM_DIR/nvm.sh" ]];
then
. "$NVM_DIR/nvm.sh"
else
install_nvm
fi
echo "nvm version $(nvm --version)"
install_node
}
|
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的 Linux或Windows 机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
# 基础镜像
FROM node:12.16.0
# 创建文件存放目录
RUN mkdir -p /home/docker-demo
WORKDIR /home/docker-demo
COPY . /home/docker-demo
# 安装依赖
RUN yarn install
# 打包,并把静态资源进行md5压缩
RUN yarn prod
# 静态资源部署CDN
RUN yarn deploy
# 端口号
EXPOSE 3000
# 项目启动命令
CMD npm start
|
相比较而言,Docker部署具有很大优势:
监控是整个产品生命周期中非常重要的一环,事前及时预警发现故障,事后提供详实的数据用于追查定位问题。
在应用出现故障时,需要有合适的工具链来支撑问题的定位修复,我们引入了开源的企业级 Node.js 应用性能监控与线上故障定位解决方案Easy-Monitor,可以更好地监控 Node.js 应用状态,来面对性能和稳定性方面的挑战。我们在内网部署了这套系统,并进行了二次开发,集成了内网域登录,并可以通过内部聊天工具推送告警信息。
应用上线后,一旦发生异常,第一件事情就是要弄清当时发生了什么,比如用户当时如何操作、数据如何响应等,此时日志信息就给我们提供了第一手资料。因此我们需要接入公司的日志系统。
日志组件基于log4js封装,对接公司的日志中心
在nuxt.config.js中增加:
1
2
3
4
5
6
7
8
9
10
|
export default {
// ...
modules: [
"@vivo/nuxt-vivo-logger"
],
vivoLog: {
logPath:process.env.NODE_ENV === "dev"?"./logs":"/data/logs/",
logName:'aa.log'
}
}
|
1
2
3
4
5
6
7
8
|
async asyncData({ $axios,$vivoLog }) {
try {
const resData = await $axios.$get('/api/aaa')
if (process.server) $vivoLog.info(resData)
} catch (e) {
if (process.server) $vivoLog.error(e)
}
},
|
用户体验的提升是一个永久的话题,vivo官网商城前端团队一直致力于技术的不断创新,希望能通过技术的探索给用户带来更好的体验;以上是vivo官网商城前端团队在SSR技术方面实践的一些经验,分享出来希望能和大家一起学习、探讨。
作者:vivo 官网商城前端团队