背景

原来的技术栈是php+jq，前后端需要分离的大前提下，后端转为更快的go，前端转为Vue ，转型做了一年。

转为vue之后，丧失了seo的能力，所以用官方建议的node ssr的方式去做服务端渲染，通过slb分发到不同的线上渲染服务器。

赵淳煜 node专家

主要节点（里程碑）

找到试点页面（标签页）

出发点：
1 流量小，影响小
2 含有大量关键字，seo效果明显

找到流量页：首页

1 流量更大，影响更大
2 具有很多核心视频的入口和关键字，seo效果明显

容灾：在vue ssr官方方案中，服务端是否渲染好有标志位，当没有这个标志位的时候，用客户端渲染（客户端渲染兜底）

整体稳定性优化1

整个链路是：客户端 — web cdn （1200ms）— slb(800ms) — node ssr
分别设置响应时长：
1 cdn 超时使用上次的缓存过的html
2 slb发现超时的时候，使用降级的html

多应用版本的部署

设计方案，设计一个配置中心，配置中心返回对应的（最新）应用版本。
而各个分布式的渲染服务器，不会每次都请求配置中心，而是采用发布订阅的方式，在配置中心每次变化的时候，推送到渲染服务器更新获取最新的版本。底层是一个具有广播能力的消息队列。

同时，这种配置中心也支持了版本的回退，因为前端不同的发布版本，都会在部署服务器以及cdn上做缓存，当需要版本回退的时候，只需要修改配置中心的版本为历史版本即可。

访问量大，无法做cdn缓存 —- 如何优化

原因：如果前端发布版本，最终要通过cdn发布，但是cdn发布有延迟的问题，就是核心节点可能是最新版本，但是远端末端节点还是上一个版本，导致发版中的问题，这样数据就是不准确的，比如视频资源的问题，必须是同步的，还有相关的敏感信息等。

所以优化node 同构的性能优化是必须做的。（支持更高的并发）

出发点1 ：让渲染更高效
节点量级：原先的dom总数在1700，优化到1000左右
优化方式：
1 部分组件在客户端渲染
2 组件级别的缓存

node内存溢出的问题

问题排查：采用方式，render之后增加内存的监控。
1 前端请求axios，拦截器的使用导致内存增加
2 发现具有阶段性的爬虫攻击，
2.1 针对爬虫，返回固定的缓存的html，seo不友好
2.2 提升服务器的负载能力

视频页优化

1 视频为主键，缓存页面
2 灰度方案，以视频尾号划分灰度（未发现大问题）
3 部分接口用koa中间层后端处理，减少串行影响的加载时间
4 部分核心请求，在高并发时，可以针对url做接口返回数据的cdn缓存，当后端接口返回超时时使用cdn数据作为备用方案，结果原先一个100ms的接口请求放在中间件处理后，视频首帧时间减少1s.

高并发请求时，版本变更后缓存稳定性

每次发版本，服务端的缓存，针对页面的缓存，都会失效，需要重新缓存。

解决方案，针对缓存，额外设计，提供版本缓存和页面缓存。

当同时有两次请求时，第一个请求检查发现有更新标志，那么请求重新生成缓存，并置换更新服务端缓存；第二次请求进入时，发现最新版本的缓存已更新，直接请求缓存。

整体稳定性保证

1 降级方案，配置中心提供降级比例，比例越大，请求中会有越多的页面使用客户端渲染

2 检测node服务器的cpu异常，cpu异常之后，直接返回客户端渲染

3 检测node服务器是否崩溃，node服务崩溃之后，从cdn获取资源

4 接口的容灾，接口数据针对入参做接口数据的cdn存储

原视频地址