![\"人人视频-马晓\"](\"https://img.serverlesscloud.cn/2020520/1589943794664-1589878075003-%E4%BA%BA%E4%BA%BA%E8%A7%86%E9%A2%91.jpg\")
人人视频之所以考虑 SSR 方案，首先是因为和百度的合作项目。
\n基于对搜索引擎爬虫的友好度考虑，也就是 SEO 优化，页面必须尽量保持是直出，方便蜘蛛爬取；其次，合作方要求用户 1.5 秒内必须能打开页面，所以技术侧必须保证用户打开页面的首开时间。另一方面，此次项目从立项到落地要求两周内上线，之前在客户端渲染方面，我们通过埋点观察过用户数据，觉得可能在短时间内既保障功能开发又能花大精力去磨这个优化可能不太现实，所以直接敲定了 SSR 方案。
\n我们公司目前技术团队分为大前端和大后端，公司将不同业务线分别独立运作。贯穿大前端和大后端不同的开发同学进行跨部门或跨业务线协作，大前端负责偏用户侧移动端的产品体验，大后端侧重于服务稳定以及数据侧深耕。技术栈方面后端业务基于 Java 生态以及 Python 大法，大前端比较「五花八门」，移动侧基于原生 object-c/swift，java/kotlin，Web 侧基于 Vue 全家桶，Node生态，php，typescript 等等，以及跨平台技术 Flutter 的相关引进。前端同学借助后端常规业务接口，通过 node 进行拼装过滤，或者独立开发一些业务类接口（常见的 BFF 玩法）。
因为团队项目主要是在 Vue 生态内折腾，所以首先想到了现在大家都在使用的Nuxt 框架。其次还有之前刷知乎了解到的 Egg 团队推出的 Egg Vue SSR方案，我们大致对比了一下，觉得都值得尝试。但是考虑到当时项目上线时间紧迫以及文档或者覆盖度问题，比如遇到问题能快速自主通过搜索查阅解决的可能性，我们最终还是先行在这个项目上选择了 Nuxt 框架。
\n另一方面，考虑完开发问题后，部署和监控也是一个重点，起初我们是以 pm2 方式去守护，另外在 CVM 层面打入探针去监控 node 进程以及性能相关数据，这方面对开发是一种考验，对运维侧也是一种负担，总体来说付出的心智成本感觉还是蛮高些，然后这时候想到了从上线之初就开始使用的云函数 SCF，以及去年在腾讯开发者大会上接触到的 Serverless Framework，通过官方文档查到了腾讯云 Serverless 团队最近支持了 Nuxt，便马上咨询腾讯云 Serverless 团队相关细节，决定将运维侧弹性伸缩业务保障这块能力交由更专业的团队去管理，解放这边的开发重心。
\n总体来说，这次项目业务结构还是蛮简单的，业务组件还是使用 vue 搭建开发，或者复用之前内部供给于移动端的 Web 组件库，依托于 Nuxt 框架实现 SSR 渲染，然后对不同组件进行了相关业务埋点，以及性能埋点，尤其是播放相关数据和 CDN 指标重点做了监控和主备方案。后面二期项目会对播放器模块做一次定制开发，以及防盗链方案做一次优化，顺便会对用户特征，对转码和 CDN 部署做一次重新梳理。
\n任何新技术的落地不可能是一帆风顺，SSR 也是如此。
\n首先就是对 SSR 性能我们自身能做到啥程度的一种顾虑，所以我们开始正式开发前先去拿某米的一个和我们业务比较像的 SSR 页面做了对比测试，因为平时也比较喜欢数码产品，经常围观这些网站，也观察这些科技大厂的技术栈迭代，所以找了个之前留意过的一个 SSR 项目页面，同时考虑到可能同样是 Nuxt，俺们第一次写出来的万一没那味，性能可能不如大厂成熟的经过好几轮优化的 SSR 页面项目，所以我们就拿 Nuxt 开始对着对方业务裸写，然后发布到线上，然后真实对比性能，找到差异再去分析对方的优化策略，直到和对方页面性能差不多的时候，我们开始上手真实写业务，也算是站在巨人的肩膀上前行吧。
\n后面甚至团队同学在项目上线后，自己通过压测和对比观察页面线上性能，最后 LRU 兜底了一层服务端页面，页面 QPS 大涨 20 倍，反向超越了一下前辈，可见后面着重发力一下 serverless 层，或者借助云自身的生态，这块还有进一步大的提升空间。
\n其次遇到的最大的问题就是各个手机厂商的浏览器对 video 的实现更加五花八门，也有不少厂商直接 hook 替换为原生播放器的，这边后面花了大量时间做适配；以及各家对 CDN 文件的缓存实现不一致，我们接口用了一层 cdn 去落地，最后实测发现有些厂商的浏览器缓存甚至会写入 SD 存储里，即使卸载重装浏览器缓存依然存在，对这种情况处理的也比较繁琐，最后严格控制了每个文件的 CDN 缓存时间。
\n另一个点是发版测试或者是灰度方面，起初使用腾讯云 serverless 的时候，我们是新建两个服务，一个用于测试，一个是正式生产环境，然后通过 API 网关绑定，能用是能用，就是感觉不太方便。在开发到后期的时候，腾讯云团队告知我们，他们灰度流量的方案上线了，通过控制流量比来实现新老版逐步切换，方便及时感知问题，甚至蓝绿测试那种方式来帮我们去优化掉这方面的使用体验，点个赞 👍。
\nSSR 不仅对 SEO 和性能有帮助，在团队内部也有不错的反响。
\n首先，让前端同学更愿意，也更安心的去把那些首开不是很满意的业务重构，另一方面前端同学更愿意一并去把接口相关业务同构掉，开发体验更加一体化，极大的简化了运维那边工作，节省了开发成本，提高了协同效率。
\n如果读者的团队还没有做 SSR，希望大家可以评估一下自身的业务特点，对首屏和 SEO 有刚需的，或者想再进一步优化用户体验的同学，可以尽早准备起来尝试一下，Serverless 下的 SSR 方案还是挺便捷的，整体开发体验上完成度还挺高，没有遇到过很大的坑，SSR 借助 Serverless 这种方式，相信在今年会越来越流行。
\n\n\n传送门：
\n\n
\n- GitHub: github.com/serverless
\n- 官网：serverless.com
\n
欢迎访问：Serverless 中文网，您可以在 最佳实践 里体验更多关于 Serverless 应用的开发！
","tableOfContents":"