Serverless SSR 技术在猎豹移动的实践

做者：董文枭 | 策划：王俊杰

为了追求速度体验和极致的 SEO 效果，愈来愈多的技术管理者和架构师倾向于采用 SSR (Server Side Rendering) 技术来构建前端项目，以支持同构代码的服务器端渲染。而在云的时代，更多的应用将迁移到云端部署，Serverless 云技术因其下降开发成本、按需自动扩缩容、免运维等诸多优点，已经大量被开发者采用以更快的构建云上应用。

本篇文章整理自猎豹移动负责平台前端部负责人董文枭老师的采访。经过董老师的讲述，咱们进一步了解到猎豹移动前端团队是如何基于腾讯云 Serverless 技术在其前端项目中应用 SSR 的。

做者简介

采访实录

问：董老师您好，请简要介绍一下您所在的团队。

答：个人团队是平台前端部，负责公司 AI、机器人、广告系统等业务和对外网站业务，团队成员包括前端工程师和 Node 全栈工程师。

问：基于什么背景和问题，您的团队考虑采用 SSR 的技术方案？

答：固然是追求极致的用户体验，虽然 HTML、CSS、JS 以及其余资源都作到了按需加载，但这里的 SSR 更是 Isomorphic（先后端同构），把 SSR (Server Side Rendering) 和 CSR (Client Side Render) 的优势结合，让用户浏览网页的时候不论是首屏仍是随后操做的其余页都能更快的展现响应。

问：您的团队使用 SSR 技术方案时，有没有进行一些调研？

答：咱们团队在 2016 年的时候开始使用 React，2017 年就开始研究并尝试 React Server Render，同期 Facebook 的网站已经采用 Isomorphic 技术实现，性能很是好。为了知足公司业务需求和技术传承，咱们自研了猎豹的前端技术框架 Koot.js，目前已成为猎豹前端的主要技术方案。

问：可否从技术的角度介绍一下目前使用的 SSR 方案的前端技术框架 Koot.js，是基于什么样的架构，有哪些模块？

答：Koot.js 包含了 SSR，也是咱们团队自研的方案，因此都是在用它.

Koot.js 是基于 React、Koa、Webpack 来架构的，其中用 Koa 搭建的 Node 做为开发服务和部署时候的 SSR 服务，页面渲染主要是用 React+Redux 完成的一套代码在浏览器环境和 Node 环境通用，利用 Webpack 可编程性动态生成配置并执行，打包出多场景（开发、测试和线上环境等）多端代码（前端、服务端）部署。

同时在开发过程当中配合了自研工具和模块来辅助开发，如 koot-router、koot-redux、koot-webpack 进行了封装简化调用方法，提高开发效率；koot-cli 完成脚手架模板选择、项目配置等；koot-i18n 提供了多模式多语言方案，能够作到正常开发，打包后多语言内容按需加载的效果；集成了 koot-analyze 分析代码、预制 eslint 规范的 koot 版本等知足了平常工做所需的大部分技术点。

具体落地的时候，咱们把自研的 Koot.js 使用 Serverless Framework 进行了封装，作了一个 Serverless 组件，这样在其余业务场景须要用的时候就能够直接复用，能够节省很多成本，避免了重复造轮子，下降了出错的几率。

问：SSR 的技术方案在落地时过程是否顺畅，遇到了哪些问题，是如何解决的？

答：SSR 项目落地的时候一般不是很顺畅，项目部署的时候须要具有服务器技术能力才能和运维顺畅沟通，因此项目落地不只要前端同窗掌握后端开发能力还要对运维技术、并发等问题多方面考虑，这对前端技术同窗的技术全面行有较高要求。

在这种状况下，去年咱们开始接触 Serverless 技术，Serverless 技术能够下降前端对服务端和运维的技术能力但要求，更适合大部分要作 SSR 的前端团队。调研了几大云厂商 Serverless 服务，最后综合比较后，选择了腾讯云做为咱们实现 SSR 的 Serverless 服务支持。

腾讯云 Serverless 提供了比较全面的组件支持，与 Serverless Framework 基本是无缝结合，周边社区和生态支持也比较到位，使用过程应该会少踩一些坑。在选定了平台以后就比较顺畅了，由于 Serverless Framework 提供了不少标准化的接口，在封装 Koot.js Serveless 组件的过程当中也比较省心。

问：目前的 SSR 方案推进了您所在团队哪些协做模式或分工的优化？

答：咱们很早就作了前端分离的开发，先后端彻底使用 API 对接，协做改变不大。由于咱们作了 Isomorphic，因此对 API 的要求变高，用户的请求不止来源于 Node 服务器，还有来自浏览器的请求，对安全性要求会高一些。

问：从您的视角，目前 SSR 方案是否还须要一些改进？

答：我认为未来的 SSR 都应该是 Isomorphic 的模式，带来的好处是减小传输成本，分摊渲染压力，用户体验也会有所提高。体验的提高其实很是小，网路状况好时，用户几乎感知不到，但小小的提高在技术开发中却作出了很是多的工做，所以咱们会把技术框架作的愈来愈完善，让业务开发同窗可以快速开发出需求，同时又享有 Isomorphic 带来的技术体验。

问：对于还未开始作 SSR 的团队您有什么建议吗？

答：若是要作 ToC 的产品，建议作 SSR 尝试，让用户尽快的看见页面内容老是更好的。

前端的 SSR 必定会考虑是否须要 Isomorphic，若是小团队建议先从比较流行的框架着手尝试，如 Next.js、Nuxt.js 等，也推荐体验咱们的 Koot.js。Next.js、Nuxt.js 这些框架在腾讯云 Serverless Framework 都现成的组件支持，Koot.js 也能够用咱们的方案。不管是 SSR 仍是 Serverless，最好都是基于现有框架，从零开始搭建框架坑太多了，若是没有足够业务支持不要浪费精力本身去作框架，学会一个框架的成本要远小于维护一个框架的成本。

最后，感谢董老师接受 Serverless 中文社区的采访。

Serverless Framework 30 天试用计划

咱们诚邀您来体验最便捷的 Serverless 开发和部署方式。在试用期内，相关联的产品及服务均提供免费资源和专业的技术支持，帮助您的业务快速、便捷地实现 Serverless！

详情可查阅： Serverless Framework 试用计划

One More Thing

3 秒你能作什么？喝一口水，看一封邮件，仍是 —— 部署一个完整的 Serverless 应用？

复制连接至 PC 浏览器访问： https://serverless.cloud.tenc...

3 秒极速部署，当即体验史上最快的 Serverless HTTP 实战开发！

传送门：

• GitHub: github.com/serverless
• 官网：serverless.com

欢迎访问：Serverless 中文网，您能够在 最佳实践 里体验更多关于 Serverless 应用的开发！

---

推荐阅读： 《Serverless 架构：从原理、设计到项目实战》