爱奇艺官方网站(开发效率提升50)

01 背景让每一个用户获取到稳定、及时的页面体验,是前端工程师们一直以来努力的方向。作为一个拥有丰富内容资源的视频网站,爱奇艺官网主站需要频繁进行节目上线或者下线、各种活动配置等操作调整,对于页面SSR服务的可用性及稳定性,都有着极高的要求。在2019年之前,爱奇艺官网主站页面的SSR采用的是在CMS平台中书写Velocity模板,由Java编译,优点是渲染速度快,但缺点也非常明显:(1)在CMS平台中开发体验不好:没有传统IDE方便,不能配置快捷键、不能安装插件等等,导致开发效率低下。(2)前后端代码不同构:由于后端使用Velocity模板,而前端需要使用Vue,导致前后端代码不同构。(3)破坏Vue组件封装性:由于Java无法编译Vue组件,所有的Vue组件都需要用Slot的方式在CMS平台中书写以达到SEO和SSR的目的。基于以上所有原因,我们决定使用Node来进行SSR。因为我们的前端框架是Vue,因此我们选择了配套的Nuxt框架进行SSR。使用Nuxt进行SSR,难点并不在于如何使用Nuxt,而在于如何维护这个服务,保证其性能、稳定性等,因此,本文将不会介绍Nuxt的使用,其语法可以参考官网,这里将主要从性能、缓存、限流、灾备、日志等几个方面来介绍我们是如何保证Nuxt服务的可用性及稳定性的。02 Nuxt 稳定性提升之路 2.1 页面配置首先介绍一个很重要的配置文件。在我们的项目根目录下,创建了一个页面配置文件,用来存放每个页面的通用配置,例如页面的缓存配置、Purge信息、主题色配置、广告信息配置等等,该文件导出一个Object, 键值为页面的Router Name,Value值为页面的配置信息:// configs/pageinfo.js
export default {
'dianshiju-id': {…},
'zongyi': {
theme: 'dark', // 页面主题色配置
},
'home2020': {…},
'rank-hot': {…}
}然后我们在Nuxt插件中根据请求的路由信息,读取对应的页面配置,并将其注入到所有的组件实例中,方便随时取用:// plugins/pageinfo.js
import config from 'configs/pageinfo.js'
export default ({ route }, inject) => {
inject('pageInfo', config[route.name]) // 注入页面配置信息
}因此你可以在组件的任何地方获取到页面配置信息而不需要通过Props一层层传递,页面通用配置也不会散落在项目各个地方,方便统一管理。<div :class="$pageInfo.theme">我是综艺页面</div>2.2 浏览器兼容性虽然Nuxt理论上可以支持IE9,但IE9在很多方面都需要添加Polyfill,例如对History API的支持等,为了保持代码的简洁性,我们放弃了支持IE9-,但我们依然在框架中保留了一套机制来支持jQuery,使得高低版本可以共用HTML,而不需要单独为低版本写模板,从而最大程度的减少兼容低版本浏览器的成本。大致思路为,Nuxt提供了一个’render.route’的钩子函数,该钩子函数的执行时机在生成HTML后,返回给用户之前。在这个钩子函数中,我们可以根据用户请求的UA信息判断用户版本,如果是低版本浏览器用户则移除HTML中高版本JS并注入低版本打包后的入口文件即可。// nuxt.config.js
'render:route': (url, result, { req }) => {
if (isLowBrowser(req)) { // 根据用户ua信息判断是否是低版本
const $ = cheerio.load(result.html)
$('body script[src*=\'pcw/ssr\']').remove() // 移除高版本js
$('body').append('<script src="//stc.iqiyipic.com/jquery.js"></script') // 添加jquery
$('body').append('<script src="//stc.iqiyipic.com/index.js"></script') // 添加低版本入口js
result.html = $.html()
}2.3 性能优化2.3.1 数据过滤Nuxt有一个很重要的机制在于,它会将所有asyncData函数返回的数据挂在`window.__NUXT__`上,通过HTML返回给客户端,从而避免客户端再次请求这些数据,因此,asyncData函数中返回的数据量对性能的影响变得更加重要,它不仅影响了接口数据的传输时间,还影响了HTML的体积,因此,我们需要对这些数据进行压缩,在NUXT中,我们尝试了三种方案:(1)在asyncData中做数据过滤(2)GraphQL(3)数据过滤平台在asyncData中做数据过滤仅减少了HTML体积,却并无法减少冗余数据的传输。GraqhQL虽然解决了冗余数据的传输问题,但代码不利于维护,因为它需要写大量的查询参数, 查询参数太长时还需要使用POST。// 非常不利于维护的查询字符串
const query = `
query {
qipuGetVideoBriefList (
album_id: "${params.album_id}"
type: "EPISODE_LIST"
play_platform: "PC_QIYI"
order: "DESC"
) {
rpc_status
episode {
id
g_corner_mark_s
brief {
title
short_title
subtitle
page_url
}
release {
publish_time
}
}
}
}
`
axios.get(`http://xxx.iqiyi.com/graphql?query=${query}`)最终,我们搭建了一个数据过滤平台,以可视化的方式来配置接口数据源、数据的字段过滤和映射,最终生成一个接口,该接口从配置的数据源获取数据,然后经过字段映射和字段过滤,仅仅返回我们需要的字段,这样既过滤了冗余数据又不需要维护GraphQL的查询参数,而是将GraphQL的查询串可视化为配置。2.3.2 LayoutNuxt提供了Layout配置项,看似非常的方便,但通过分析Nuxt生成的.nuxt/App.js入口文件,我们发现所有的Layout不管有没有被使用到,都会被打包进来,例如A页面使用了LayoutA, B页面使用了LayoutB, C页面使用了LayoutC,则A、B、C三个页面的入口JS会有LayoutA、LayoutB、LayoutC的所有代码。// .nuxt/App.js
import _8daa19aa from '../src/layouts/a.vue'
import _8daa19a8 from '../src/layouts/b.vue'
import _8daa19a6 from '../src/layouts/c.vue'
import _6f6c098b from './layouts/default.vue'因此,如果Layout的逻辑很复杂,并且如果代码量很大,所有页面的JS体积就会变大许多。基于以上原因,我们放弃了使用Nuxt的Layout,而是自己封装了一个I71Layout组件来提供所有页面的通用功能,以减少冗余代码。2.4 缓存由于Vue SSR是基于虚拟DOM,而Java是基于字符串,所以性能上相比之前会慢一些,因此我们从页面和组件两个粒度上做了缓存策略。我们使用Nginx反向代理来控制页面级别的缓存,默认每个页面缓存5分钟,当Nuxt返回非200时,Nginx则使用过期缓存返回。组件缓存我们使用的是官方的@nuxtjs/component-cache模块,它提供了一个serverCacheKey配置项,Nuxt会以这个配置项的值作为缓存的Key。因此我们为每个需要缓存的组件定义了一个cache-key的Props, 传递后则会根据传递的值做缓存,未传递则无缓存。这样对于所有无缓存的页面在调用组件时,可以传递一个cache-key来使得组件被缓存,从而加速页面的SSR。2.5 purge对于有缓存的页面,我们需要对应的Purge接口来清除页面缓存。页面的Purge分为两个部分,一部分是我们Nginx反向代理的缓存Purge, 另一部分是CDN缓存的Purge,他们的Purge原理相同,因此这里我们只讲Nuxt服务的Nginx反向代理的缓存Purge。我们希望提供一个Purge接口,通过传递页面名参数来Purge指定的页面。我们的Nuxt框架本身是基于Koa搭建,所以我们只需要在SSR之前插入koa-router,就可以提供我们的Purge接口。// server/index.js
const app = new Koa()
const router = new Router()
router.get('/api/purge/page/:pageName', async (ctx) => { // 定义purge接口,支持传递pageName
ctx.body = await purgePage(ctx) // purge nginx缓存和cdn缓存
})
app.use(router.routes()) // 插入我们需要的api
app.use(ctx => { // nuxt 进行 ssr
nuxt.render(ctx.req, ctx.res)
})那我们如何知道每个pageName要Purge哪些URL呢?这里我们需要在之前提到的页面配置文件中进行配置来将pageName和Purge URL关联起来:// configs/pageinfo.js
zongyi: {
purge: {
purgeUrl: [
'https://zongyi.iqiyi.com/',
'https://www.iqiyi.com/zongyi'
],
},
}接下来我们只需要Purge所有服务上的这些URL,服务部署在公司的应用平台,一共有4个集群,上百个Docker容器,我们需要Purge所有宿主机上的Nginx缓存,具体操作如下:首先我们需要在Nginx中配置让其支持Purge:location / {
proxy_cache_purge PURGE from all;
}这样就可以通过调用http://{宿主机的域名}:{宿主机的端口}/purge/{uri}来Purge该宿主机上uri对应的缓存了。接下来我们只需要逐个调用所有宿主机上的Purge接口就可以Purge所有的宿主机上的页面缓存了。2.6 限流对于无缓存页面,为了谨防恶意刷量行为,要进行限流。我们从WAF, 单IP限流, IP黑名单进行了三方面的限制。2.6.1 WAF(Web Application Firewall)首先我们接入了公司的防火墙平台,通过智能识别以过滤掉一些恶意请求。其次,对于一些动态路由的页面,我们对请求的URL进行了正则匹配,不符合正则的请求全部拒绝访问并返回403。2.6.2 单IP限流为了防止单IP脚本刷量,我们在Nginx反向代理使用limit_req模块进行单IP限流。对于普通用户和爬虫,我们设置了不同的访问频次,超过频次的请求拒绝访问并返回503。2.6.3 IP黑名单除此之外,我们通过日志分析会发现一些很明显的刷量IP,对于这样的IP,我们希望直接封禁。如果直接在Nginx配置中添加Deny语句,会发现Deny并不会生效,是因为请求经过了网关,到我们的Nginx服务时,Remote Address变成了网关的IP,而我们Deny的是真实用户的IP,所以我们需要想办法让Nginx知道用户的真实IP是什么。通常用户的真实IP存储在x-forwarded-for字段中,为了拿到用户的真实IP,我们需要在Nginx中做以下配置:# nginx.conf
server {
real_ip_header X-Forwarded-For; # 告诉Nginx,用户的真实IP存储在x-forwarded-for字段中
real_ip_recursive on;
}但光有以上配置还不够,因为x-forwarded-for字段为一个字符串,每经过一个节点,这个节点就会向里面追加一个IP,所以到达我们的Nginx时,该字段的值为x-forwarded-for: {用户的真实IP},{网关的IP},而Nginx读取IP时,会默认从后往前读取IP, 如果这个IP是受信任的IP,则会继续往前读取,直到不被信任的IP就会当做是用户的真实IP,因此,如果没有额外配置,Nginx读取到的IP依然是网关的IP,因此,我们还需要将所有网关IP添加到信任IP的列表中,Nginx才能继续往前读取到用户的真实IP。我们可以将整个内网网段都设置成信任IP:# nginx.conf
server {
set_real_ip_from xxx.0.0.0/8; # 设置内网网段为信任IP
real_ip_header X-Forwarded-For; # 告诉Nginx,用户的真实IP存储在x-forwarded-for字段中
real_ip_recursive on;
}现在Nginx可以读取到用户的真实IP了,这时候我们只需要创建一个IP黑名单即可:# nginx.conf
server {
set_real_ip_from xxx.0.0.0/8; # 设置内网网段为信任IP
real_ip_header X-Forwarded-For; # 告诉Nginx,用户的真实IP存储在x-forwarded-for字段中
real_ip_recursive on;
include ip-blacklist.conf # 导入IP黑名单
}
# ip-blacklist.conf
deny xx.xx.xx.xx;2.7 灾备对于无缓存的页面,除了限流以外,我们还需要有灾备方案,否则一旦服务出错返回非200,用户将看到错误页面。我们部署了一套独立的灾备服务,使用Node脚本每隔三分钟从线上服务拉取所有重要页面,如果页面返回200,则将其存储为HTML文件,否则抛弃该页面,然后使用Nginx做反向代理来Serve灾备页面。CDN先从线上服务拉取页面,若返回非200,则从灾备服务拉取对应的页面返回给用户,以此保证用户永远不会看见出错的页面。2.8 服务端日志服务端日志主要用来记录Nuxt渲染页面的记录、错误信息等,它们对于排查问题、统计流量来说是非常重要的,我们的服务端日志分为两大部分:页面渲染日志、接口请求日志。页面渲染日志即每一次来一个页面请求,则写一条日志,记录页面的URL、Referer、用户Cookie、用户IP等信息,若页面渲染未出错则写入到logs/page/info.log中,若页面渲染出错,则写一条日志到logs/page/error.log中。接口日志是每一次页面渲染中发出的请求日志,封装在底层发送请求的HTTP函数中,记录了调用该接口的页面URL、接口URL、接口参数等信息,若请求成功,则写一条日志到logs/api/info.log, 若请求失败,则写一条日志到logs/api/error.log中。// nuxt.config.js
hooks: {
'render:setupMiddleware': app => { // 在nuxt初始化时插入一个中间件,每次请求都生成一个logParams对象
app.use(async (req, res, next) => {
req.logParams = {
requestId: generateRandomString(), // 生成requestId随机串
pageUrl: req.url
}
next()
})
},
'render:routeDone': (url, result, { req, res }) => { // 渲染完毕
logger.page.info({ type: 'render', …req.logParams}, req) // 写日志时带上requestId
},
'render:errorMiddleware': app => app.use(async (error, req, res, next) => { // 渲染错误
logger.page.error({ type: 'render', error, …req.logParams }, req) // 错误日志带上requestId
next(error)
}),
}为了让页面渲染日志、这一次渲染的接口日志关联起来,我们会在渲染前生成一个唯一的RequestId, 然后在该次渲染的所有日志中都带上这个RequestId,就可以通过一个RequestId查询到页面渲染日志,以及这个页面发出去的所有请求日志了。// http.js
class Resource {
async http (opts)
let data
try {
data = await axios(opts)
process.server && logger.api.info(opts, this.req.logParams) // api日志带上requestid
} catch (error) {
process.server && logger.api.error(opts, error, this.req.logParams) // api错误日志带上requestid
}
return data
}
}2.9 日志采集我们采用了Filebeat + Elasticsearch + Kibana进行日志管理,首先通过Filebeat进行实时日志采集,然后上报至指定 kafka 集群,然后对日志进行分析并建立索引,最终生成一个可视化的日志查询页面,这样我们就可以查看一段时间内符合查询条件的日志了。2.10 流量监控基于服务端日志,就可以据此统计流量经由了CDN的缓存、WAF的拦截、Nginx反向代理的缓存,最后计算出到达我们的Nuxt服务的实际流量到底有多少。我们可以根据日志的time字段筛选出指定时间段且type= 'render'的日志,就是该时间段内Nuxt服务承受的总流量了,如果想看各个页面的流量,还可以进一步对日志中的pageUrl字段进行筛选。03 总结Nuxt从根本上解决了之前在CMS平台使用Velocity开发遇到的所有问题,但同时也带来了一些别的问题,例如域名冲突的问题、服务端变量共享的问题、渲染性能问题等。不过总体来说,瑕不掩瑜,开发体验得到了质的提升,开发效率提升了50%以上;组件复用率更高、组件封装性更好,代码可读性、可维护性都得到了飞跃性的提升;在CDN缓存、Nginx反向代理缓存、组件缓存的强力加持下,页面的渲染性能也并没有下降;由于移除了一些由于前后端代码不一致、大量使用Slot等一些复杂逻辑后,首屏渲染性能反而提高了许多,服务器响应时间维持在平均0.5s左右,错误率维持在0.2%左右,而在有灾备服务兜底的情况下,可访问性也几乎达到100%。最后,期待Nuxt3的到来以及性能和开发体验上的进一步提升。

本文出自快速备案,转载时请注明出处及相应链接。

本文永久链接: https://kuaisubeian.cc/37927.html

kuaisubeian