Serverless SSR 技术在「腾讯在线教育」中的实践

立即点击-> 选择您最常用的编程语言，免费体验 Serverless Demo

我们的团队

IMWeb 团队隶属腾讯公司，是国内最专业的前端团队之一。
我们专注前端领域多年，负责过 QQ 资料、QQ 注册、QQ 群等亿级业务。
目前聚焦于在线教育领域，精心打磨腾讯课堂、腾讯企鹅辅导及 ABCmouse 三大产品。

技术方案的摸索尝试

腾讯在线教育团队在传统的 Web 应用方向其实有很多技术方面的尝试，包括传统离线包、PWA 离线应用等，但是每个技术栈都有其优点与缺点，目前团队的技术方案对比如下：

从上述表格可以看到，SSR 在首屏渲染以及 SEO 等方面都有不错的表现，这也是团队想在 SSR 技术方面深挖的初衷。SSR 方案选择上主要考虑:

1. SSR 应用的性能

我们知道类 React 的应用的 SSR 的本质为在服务端调用 React 的 renderToString 方法将 React 组件渲染成 HTML 字符串，那么对于复杂的 SSR 应用来说，可能存在大量的 CPU 密集型计算，这并不是 Node 所擅长的领域，那么如何优化这方面的性能问题也是我们所关注的重点。同时因为离线包的环境依赖性（依赖 App），那么在传统的 Web 环境内是否可以有一套完整的解决方案来缓存相关的页面，从而提高首屏的性能，也是关注点之一。

2. SSR 的运维成本

对于大多数前端工程师来说，在服务的运维方面都可能有时并不那么得心应手，所以在服务的可用性方面，也是在做技术选型时所考虑的重点方向之一。

根据以上两个方面，可以把我们的考虑因素总结为以下两个点：

腾讯在线教育团队 SSR 架构方案介绍

先从整体来了解下团队 SSR 技术的架构图：

接下来我们从以下几个方面来详细讲解下团队现有方案。

代码组织

我们在 PC/H5 项目中均采用了同构的模式来构建 SSR 应用。

在同构的模式下面，业务开发者更关注与业务的功能本身，而不用太过关心运行时的问题，但是也要注意以下几个问题：

传统浏览器中的常量使用，比如 window 、document 等。
http 数据请求库必须同时支持服务端和客户端。
合理使用 React 应用的生命周期。
通过注入环境变量来区分当前运行时环境。

性能优化

接口动静分离

我们知道页面的渲染一般要依赖于后端的相关数据，数据这里可以拆分为两个部分：动态数据与静态数据。静态数据指的是页面中不经常变更的数据，比如企鹅辅导产品产品的课程标题、课程描述等；动态数据指的是页面种与用户登录态相关的数据，比如课程是否已经购买、当前课程的折扣等。

对接口做动静分离的意义在于，我们可以利用静态数据的时延性敏感度低的特性做缓存，在服务端利用静态数据渲染页面，之后在服务端利用动态数据做二次渲染，主要逻辑如下：

我们利用 Redis 对静态数据渲染出来的页面做缓存，这样不仅可以加快 SSR 的渲染时间，同时可以提高单机的 QPS（renderToString 在一定意义上为 CPU 密集型操作）。

浏览器中利用 PWA 做离线缓存

同时在客户端中，我们可以利用 PWA 来做离线缓存，缓存静态数据直出的 HTML 页面，从而进一步的提高了直出页面的首屏性能。

运行上下文

因为后端应用的运维复杂性、维护成本较高等问题，这里我们使用了 Serverless（腾讯云 SCF）来做直出应用的部署。

得益于 Serverless 架构模式的天然优势，我们不用在关心服务的运维、服务的扩容等问题，这也是我们为什么选择其的重要原因。

如上图所示，我们 SSR 应用本质为一个 Node 应用，但是 SCF 的调用本质为一个 Event 事件，那么如何去兼容这两种模式呢？这里我们对自研 Node 框架（imserver）做了一层 Serverless 的封装，由于腾讯云 Serverless Framework 提供了很多标准化的接口，在封装自研 Node 框架（imserver）的过程中也比较省心。同时在入口做了 Event 到 Koa Request Context 的兼容。

SSR 技术方案落地中遇到的问题

1. 云函数拆分

我们业务中有多个页面是通过 SSR 来实现的，采用了腾讯云云函数 SCF 来做 SSR 之后，就会遇到一个问题：是合并到一个云函数中（业务级），还是拆分为多个云函数（页面级）。答案肯定是页面级会比较好，主要的优点如下：

云函数互相独立，假设页面 A 云函数挂掉，并不会影响到业务 B 的云函数。
云函数包的大小会降低，因为 SCF 的冷启动过程，代码的包的大小对函数的冷启动时间也有一定的影响。

这里我们基于当前的项目做了云函数的自动化构建，通过 .scfssr.json 的配置文件自动生成相应的云函数，对现有的开发是没有任何影响的，只是在构建的时候生成多个云函数，这样既降低了应用的维护成本，又降级了应用的开发成本。同时得益于云函数的构建过程，我们可以对单个云函数的代码做瘦身，通过对 package.json 中的依赖分析，剔除一些云函数容器中已经内置的工具包，以及对云函数所依赖的第三方包做相应的引入分析，去重冗余。

2. 云函数发布优化

上图为我们设计的基于 SCF 的多云函数直出方案逻辑，可以看到当我们有版本更新的时候，其实发布流程还是比较复杂的，步骤也是相当繁琐：

配置过程：初始化进行一次

函数中创建 release、prohub 别名，可预先指向 $LATEST 版本。
API 网关中创建服务 A，配置 API，指向函数 B release 别名，并发布到 API 服务的 release stage 中
修改 API，指向函数 B prehub 别名，并发布到 API 服务的 prehub stage 中
修改 API，指向函数 B 的默认流量，并发布到 API 服务的 dev stage 中；至此 API 网关的配置完成，后续无需在 API 网关上再次修改及发布配置

开发测试发布过程：持续开发测试发布上线