NGW，前端新技术赛场：Serverless SSR 技术内幕

1、前言

最近 Serverless 又火了，有很多业务上云实装了 Serverless 云函数，取得了不错的落地效果，业界也在不断探索 Serverless 更多的落地场景。

那么对于前端来讲，Serverless 意味着什么？对于 Node 服务来讲，哪里能够落地 Serverless？

答：Serverless 同构直出渲染

Serverless + SSR = ?

Serverless 云函数: 云计算发展过程当中出现的一种计算资源的抽象，它以云计算平台为基础，为开发者提供业务程序的运行环境，开发者无需关注底层资源分配、扩容部署，代码执行所必要的所有服务由平台提供。

SSR 服务端渲染: 指在服务端将 HTML 渲染到前端，早期经常使用 php jsp 技术来在服务端生成 HTML，近年来 JS 同构化趋势演进下，逐步出现了在服务端上运行前端 JS 代码进行渲染的方案，如 React、Vue 等主流框架的同构渲染。

若能将 Serverless 技术落地到 SSR 场景，将会有以下优势：

• 云服务资源理论上无限扩容，前端没必要考虑业务量对 SSR 机器性能的影响

• 前端同窗无需关注 SSR 机器的运维、申请、扩容，减小部署运维成本，提升开发效率

目前腾讯 NOW 直播 IVWEB 团队正逐步将 SSR 业务迁移到腾讯云云函数平台上，精简部署运维成本。

2、Serverless的演进

阿 J 是一个前端开发仔，某天产品跟他说页面白屏加载接口的时间太长了，体验差，这对于优秀的前端开发仔的他并非难事，他有 99 种让页面加载变快的办法，所以他立马将利用团队直出框架，花了半天时间将页面接入了直出，接下来要将直出服务部署到现网，这时他犯难了：

1. 部署直出服务须要申请机器，申请多少台，申请几核的？

2. 这个业务量怎么样，有没有高并发场景，机器有没有扩容机制？

3. Nginx 配置怎么改才能接入直出，直出失败的话又要怎么接入兜底的静态页面？

一头雾水之时，他看见腾讯云的同事 maxlong 关于 Serverless 架构演进的 PPT….

从 IaaS 到 FaaS

在介绍 SCF 云函数以前，咱们先来 diff 一下传统 IaaS 业务架构和云函数 FaaS 业务架构：

基于虚拟机的业务架构 (IaaS)

而云函数架构是这样的：

基于云函数的业务架构 (FaaS)

阿 J 对比了二者架构以后发现，在基于云函数的业务架构下，开发者无需再关注业务基础层的相关配置，能够集中精力处理业务逻辑的开发，基础层由平台负责维护迭代，只要将咱们的直出服务部署上云就能够解决部署直出业务中的运维痛点了。

FaaS + BaaS 下的 Serverless

FaaS 的出现使得服务上云变得容易起来，可是 FaaS 并无解决「公共基础服务」的问题，而所谓公共基础服务，就是形如对象存储、KV存储、消息推送这样的基础服务，这个问题最终落到了云服务提供商这里，所以市面上的云服务无一例外的都提供了上面的「公共基础服务」，这样的服务模式叫作 BaaS（Backend as a Service）。

Serverless 直译过来叫无服务器，这里并非说不须要服务器，而是说开发者不须要关注服务器，这部分由平台维护提供，开发者仅需关注业务逻辑的开发便可。

Serverless 架构下的 App

在这样的一种架构下，开发者无须关注支撑应用服务运行的底层资源，以「函数」的形式承载业务逻辑，以「BaaS 服务」的形式支撑公共服务。

公有云基础设施上的 Serverless 演进

考虑到直出服务的特性，阿 J 认为直出业务十分适合上 Serverless，所以他立马开始了直出上云的预研，作 Serveless SSR 服务，免去运维部署烦恼，减小直出接入成本！

3、SCF 云函数开发

阿 J 认真研究了腾讯云的云函数（Serverless Cloud Function，SCF）发现云函数它能够将咱们的业务拆成更细的粒度「函数」，而函数的执行环境开发者不须要关注，由平台负责，如下是阿 J 对云函数执行的理解。

云函数执行过程

云平台在执行这些「云函数」的过程其实就是在对外提供服务，一般状况下，Serverless 函数会用于「响应 HTTP 请求」，即经过 HTTP 访问事件来触发云函数的执行，以下图所示：

云函数用户请求链路

而「函数的执行」不外乎：入参、上下文、返回值、反作用四个要素，如图所示：

函数执行的四个要素

四要素：

• 「入参」：

  云函数的入参即 HTTP 请求中的请求头、请求体

• 「上下文」：

  包含这次函数请求的 id、函数执行的环境变量等等

• 「反作用」：

  云函数执行可能调用外部服务，如数据库、对象存储、数据监控

• 「返回值」：

  即 HTTP 响应如 {retcode:0,msg:"ok"}

阿 J 还了解到根据必定配置部署完云函数以后，云平台会给你一个 URL，经过访问这个 URL 就能够「触发」对应云函数的执行，获得结果。

4、NGW Serverless 同构直出方案

正当阿 J 着手进行 Serverless 直出开发的时候，他猛然发现，Serverless 环境下跟原有的直出环境有较大出入，原有的直出环境是这样的：

1. 原方案直出是使用 TSW 执行 Koa App 的方式进行直出的，这意味着原方案须要监听端口而不是做为函数来运行，这个要怎么处理？

2. 老业务能不能作到无缝迁移到云函数？

   能不能作到新直出方案兼容老直出方案？

3. 云函数怎么作到工程化打包发布，接入到团队现有的 CI 流程中？

4. 原方案能够作本地调试，而云函数直出怎么作本地调试？

5. 云函数发布后，会获得一个 URL，那么这个 URL 要怎么接入咱们的业务域名下？

工程化打包

除去前端 webpack 打包以外，对于 Serverless 云函数平台，咱们还得在原来的打包产物基础上再作一些操做，其核心在于「打包为 zip 上传到云函数」，以下图所示：

云函数打包图示

从图示中能够看到，打包部署的流程由「CLI 工具」承担，缘由是为了提供命令式的部署原语，方便 CI 接入。

Serverless 下的同构环境

阿 J 考虑到原先业务的直出方案采用 TSW 来作，可是在 Serverless 下，咱们不能把 TSW 搬进云函数里执行，而是抽取了其中咱们须要的组件出来，如 ajax、monitor、logger 等经常使用组件，由于：

• 方便老业务无缝迁移到云函数直出，解决直出业务的运维痛点

• TSW 很大，压缩后近 20 MB，解压出来大不少，不利于云函数的性能

除此以外，还要本身去实现 window.REQUEST plug 相似这样的 TSW 全局注入的对象，由于旧有方案也依赖这些全局对象。

「流式」和「块式」

原来的方案须要 Koa 监听本地端口才能提供服务，而云函数的出入参是块式的，Koa 的出入参是流式的，所以这里须要处理一下云函数的入参。阿 J 的作法是根据云函数入参来动态构造 http 的 IncomingMessage 和 ServerResponse 的实例，而后透传给 app.callback() 进行直出渲染，最后从 ServerResponse 里取得渲染结果构造为云函数返回值返回。

NGW 做网关转发

阿 J 考虑到业务的可用性以及以前链路接入的痛苦，决定接入 NGW（Node Gateway）：

NGW 下的 Serverless 直出链路

经过 NGW 能够作到：

1. 实现兜底逻辑：

   云函数可能会 crash，这时候走静态页面接入机

2. 灰度逻辑：

   直出上现网的过程当中能够经过 NGW 的配置进行部分灰度测试

3. 链路日志收归：

   长期以来，前端很差查具体的链路信息，如今有了 NGW 一切皆有可能

云函数本地调试

云函数的无状态模型使得其很是易于进行本地调试，咱们只须要在本地构造函数的入参、上下文便可直接进行直出调试了，阿 J 在实际实现中是经过本地起一个 Koa 服务监听端口，利用这个端口的请求来构造入参、上下文，最后传入函数执行结果，返回到前端显示。

同构直出过程

在最后，阿 J 完成了 Serverless 直出方案，其直出过程以下图所示：

新方案下的同构直出三步

• 「Init」：

  初始化云函数环境、接受并处理云函数的入参

• 「Koa」：

  React 同构业务逻辑以 Koa App 的形式体现

• 「Clear」：

  清理云函数环境、处理 Koa Response 返回直出结果

特别须要提出的一点是，其中的 Koa 其实就是原方案的打包结果，新方案在此基础上做了一些环境迁移、重写，使其能够在云函数环境下执行渲染。

云函数的性能瓶颈和优化

阿 J 在完成了新直出方案以后立刻进行了压测，发现随着压测压力的增长，收包率会出现断崖式下跌，并且还发现部分函数执行耗费时间很是长，联系了云函数的同事看了下发现是「冷启动问题」，那什么是冷启动？

从云函数的架构中能够看到，云函数触发后并非立刻执行，它须要一个环境初始化的过程，这种启动叫作冷启动；还有种状况是，此次请求的函数执行以后立刻接到下一次请求，这时候就不用从新初始化云函数环境，而是直接启动，这种称谓热启动。

压测云函数 执行时间分布图

收包率优化先后（右边为优化后）

冷启动问题在压力低的状况下不明显，可是在高并发的状况下就会额外影响回包了，这里SCF 的同事进行了优化：提升最小实例数，减小冷启动，最小实例越多就越能扛住瞬时并发，优化效果如上图右边所示。

此外咱们还发现了内存的问题，这里联系了 SCF 的同事进行了 Node 内存模型的相关优化，优化后，已基本不存在 4xx 的问题。

（业务中的内存使用也能够进行优化，要避免 JS 内存泄漏）

内存超限致使 4xx 问题，压测压力越大越多这种错误

内存模型优化后的表现

到这一步，阿 J 终于初步完成了 Serverless 直出方案设计开发，并开始逐步在业务中使用推广。

现状和下一步计划

目前 NGW + Serverless SSR 已经应用到 NOW 直播、手 Q 附近、浏览器直播和手 Q 群送礼等多个项目中，实际业务开发中，Node 业务的部署和运维工做量下降了 80% 以上。

---------下方更多精彩----------

Node部署和运维工做量下降80%，腾讯NOW直播是怎么作到的？

（点击图片便可跳转）