手机淘宝短视频业务「哇哦视频」迁移上 FaaS 笔记公开

作者 | 刘子健（繁易）  阿里巴巴高级前端工程师

前言

2019 年，在阿里巴巴集团内部技术论坛上对于 Serverless 和 FaaS 的讨论非常火热。

在看了那么多“技术原理/顶层设计/平台建设”相关的文章之后，我相信你对 FaaS 肯定产生过跃跃欲试的感觉，但也肯定存在诸多疑惑，例如：

• FaaS 在业务中能落地吗？
• FaaS 能帮助前端同学实现能力升级吗？
• ……

而这些疑惑对于刚开始接触 FaaS 的我而言，只会多不会少。恰好，我所负责的“哇哦视频”业务是淘系第一个基于 Node FaaS 开发的线上业务，在线上已经稳稳当当的跑了 4 个月，这期间不仅接手了 Java 同学的工作，同时也顺利的承接了日常与双十一需求。

关于上面的这些疑惑，经过了这四个月的考验，我想我已经有了自己的答案。接下来我将会向大家分享我这四个月的历程，带大家一起看看，在一名一线业务同学的眼中，FaaS 究竟会给前端同学带来什么？

背景

哇哦视频是在手淘首页的短视频导购业务，业务核心目标如下：

打造围绕“人用物”为核心有 “温度”的短视频；引导更多的商家视频，商家模板化生产;增加首页分发效率，让用户快速的且容易定位到自己想看的视频内容。

而其作为手淘的导购业务，具有“三高”的特点：

由于是身处手淘首页的业务，其流量相对于普通业务而言是比较高的，属于大流量业务。而流量高的特点也带来了稳定性高的要求，由于用户众多，因此线上的任何不稳定都有可能产生舆情。

而作为导购业务，业务本身还有一个迭代频率高的特性。为了能实现更好的导购效果，业务需要不断的推陈出新，快速建场，从而获得更好的导购效果。

淘系导购研发模式

1. 中台化

在淘系，随着中台化战略的成熟与导购侧近几年的发展，导购业务的开发工作由独立开发各种能力向中台化支持转变。业务所需要的绝大部分能力均可以由中台提供。

这么做带来的好处是显而易见的。大部分常见的导购业务，都可以通过中台能力的组装从而实现快速上线，避免重复开发带来的人力物力的浪费。如下图所示，此时在哇哦视频，后端绝大多数的工作在于调用中台的在线服务与离线服务，编写相关的业务逻辑来完成相关需求。

2. 工作流

在淘系导购业务现今的开发中，一般都由一位前端搭配一位后端一起完成，每个需求的开发，都需要遵循开发 + 联调 + 测试的完整流程去进行。

而我也针对于哇哦视频最近的几次需求开发做了时间的分析，具体结果如下图所示：

后端同学得益于中台能力的完善支持，许多代码可以复用，因此开发工作量会小一些。而前端则由于 UI 开发的特性，许多东西需要推倒重来，难以复用（首页改版，整体样式都换了），所以工作量会稍微大一些。

这一套流程实际上已经相当成熟，但成熟并不代表完美。实际上开发过程中，痛点还是有很多的。

研发模式痛点

1. 联调成本过高

首当其冲的痛点则是联调。在联调期中前后端需要不断对数据字段、业务逻辑进行确认，从而确保需求实现的正确性，而这种密集的沟通所带来的成本是非常高的。

如下图所示，在业务开发中我们发现联调成本一般要占到开发成本的 30% 左右。

居高不下的联调成本，一方面使得工程师们精疲力尽，另一方面也不利于业务的快速迭代。

2. 前端资源化

值得一提还有前端资源化的痛点。

在目前前后端的分工模式中，前端只负责交互逻辑与相对应的 UI 实现，对于业务核心逻辑无需过多了解。虽然这使得前端团队可以快速完成某些业务，但同样也带来了前端资源化的隐患。而在强调前端要深入业务，具有商业化思考能力的今天，前端资源化实际上是不利于前端的自身发展的。

因为很多时候前端想去深入业务，想进一步升级自己的能力，但往往会苦于没有相关场景。至于说介入后端的工作领域，毕竟术业有专攻，很多事情也掺和不进去。

遇见 FaaS

吐槽归吐槽，但是工作还是要继续的。既然每天的工作有这么多痛点，那么是否有办法去尝试解决它呢？

恰好今年的四月份我开始参与淘宝导购体系 Node FaaS 相关建设的工作，开始接触到一些 Serverless & FaaS 相关的工作。在经过一段时间的基础建设后，我们需要一个业务作为试点业务来检验工作成果。

出于对自身能力升级的渴望，我主动梳理与分析了当前业务的特性，并且主动要求将哇哦视频作为 Node FaaS 的首个试点业务。

哇哦视频后端分析：

哇哦视频是一个主打纯视频的导购业务，流量高。基于对后端代码与日常需求的剖析，总结其特点为：运营位多、强依赖算法推荐、数据源多、无状态服务 四点。 其中运营位多 + 强依赖算法推荐的特性，使得业务具有一定的复杂度，改造工作量主要在于理解业务规则，填充数据。

而数据源多则代表其引用的外部服务较多，如视频服务、话题、特斯拉资源位定投等。该部分工作量主要在于熟悉上下游系统。

最后无状态服务是改造 FaaS 的大利好消息，无状态则意味着横向拓展极其便利，完美契合 FaaS 的工作场景。（其他导购业务应该也类似）

总结：哇哦视频复杂度适中，无状态的业务模型十分契合 FaaS 的业务场景，且个人在通读完代码后，有把握能 Hold 住整个后端业务迁移 FaaS 的需求。因此我认为哇哦视频迁移 FaaS 平台是具有高可行度的。

非常顺利，也没有任何波折的，哇哦视频成为了淘系首个 Node FaaS 试点业务。怀揣着对于能力升级的渴望，我开始尝试将现有的业务逻辑迁移至 Node FaaS 实现。

期望达到的效果如下图所示：

迁移进行中

在正式进行迁移前，我和业务方沟通了这个事情对于业务可能产生的影响以及后续规划。业务方对于技术侧的改造是没有意见的，只有一个诉求，那就是业务不受影响。

整个诉求看似简单，拆解下来包括以下三部分：

• 不会为技术侧改造预留时间，原定需求要按时完成；
• 迁移后线上不能出任何问题，线上对迁移无感知；
• 后端工作交接至前端后，对后续需求推进无影响。

说起来就是既要快，又要稳，还要能扛住后续需求。

针对这个诉求与当时的实际情况，我采取了以下三个措施，来保障整个迁移对业务侧没有影响：

• 快速 Copy Java 代码上线
• 使用 Java 兜底，保障线上稳定性
• 谨慎评估后续需求，确保需求可实现

1. Copy Java 代码上线

Copy & Paste 听起来像是不光彩的事情，但这并不是一件需要遮遮掩掩的事情。相反我现在还很庆幸自己在迁移刚开始时选择了这样的方式，而没有愣头青一样选择另起炉灶，从零开始。毕竟学会跑之前得先学会走路。

前面也提过，哇哦视频是一个大流量导购业务。即使诸多能力已经中台化，但必要的胶水代码 + 相关的业务逻辑代码，总行数也高达 5000 行左右。

选择从零开始固然炫酷，但是这样难以保障代码的稳定性，毕竟原有的业务代码不仅包含必要的业务逻辑，也包含了诸多的错误处理与边界处理，而技术侧改造是必须要考虑到稳定性问题的。

且对于原有 Java 代码的 Copy 也算是一种另类的学习方式了，在这个过程中对于 Java 开发也有了足够的了解，毕竟在整个集团都是 Java 技术栈的情况下，对于 Java 的学习与了解非常有利于后续工作的开展。

非常幸运的是，后端同学的代码质量很高，该有的注释一个不缺（如下图所示），因此整个读代码 & Copy 的过程非常流畅。

也因此在后续 FaaS 版本的哇哦视频提测时，是 0 BUG 直接上线的，节约了大量的返工时间，从而避免对业务需求造成影响。

2. 使用 Java 兜底

这其实算是一个开发中的小 Tricks 了，但却足够好用。

在之前的导购研发中，为了避免后端宕机对线上带来的影响，因此网关层做了一个 CDN 容灾方案，如下图所示：

注释：

• XCtrl - 前端调用 mtop SDK
• TCE - 淘宝导购网关

对于前端同学而言，当请求线上接口失败时，前端的请求 SDK 就会根据当前请求数据，去 CDN 上获取最近成功的数据，从而确保对于用户端产品是可用的。

但目前导购侧的业务基本都接入了千人千面的算法，而 CDN 容灾的一个缺点便在于只是随机取一份成功数据存入 CDN，并不支持千人千面。

非常不妙的是，在我迁移 FaaS 时，底层能力还相对羸弱，时不时会有宕机等问题，这时候即使有 CDN 容灾能保障产品可用，但用户侧的体验依然是有一定损失的，属于有损降级。

而此时其实产品需求并未发生较大的变更，原有的 Java 接口也能继续使用，因此灵机一动准备将 Java 作为兜底的数据源，确保在降级的请求用户体验是完整的。

整体思路其实非常简单，请求路径整理如下：

• 之前的：Java 接口 - CDN容灾
• 现在：FaaS 接口 - Java 接口 - CDN 容灾

得益于这种设计，哇哦视频在上线后，顽强的活了下来。即使那段时间底层时常不稳定，但对于用户体验来说并没有多少损失（两个接口 RT 都很短，请求两次基本无感）。

迁移之后

在完成代码迁移之后，便开始筹备上线的事情。上线的过程中倒是没有什么故事可以说，波澜不惊的按照既定节奏进行灰度、放量，慢慢的也就上线了。

在整个业务真正交接到自己手中的时候，我开始遇到了真正的麻烦。

这个需求我该怎么做？

随着技术侧改造的完成，业务交给我的新需求也得继续推进，于是迷迷蒙蒙的去参加了很多场业务需求会，接触了很多自己之前作为前端根本不会接触的方面。

但事情的进展并不顺利，自己刚转型成后端，很多事情都是迷迷糊糊的，似懂非懂。于是那段时间每天最大的疑惑就是：“这个需求我该怎么做？”虽说导购业务都是调用中台，但是一个需求到我手上，哪些应该调中台，哪些应该自己完成我都是不清晰的。

于是那段时间整个人的工作都变的非常拘谨，开始主动 Push 自己去学习和了解更多业务知识，了解更多后端的业务中台。整个人面对需求，进入了一种“谨慎评估”的状态。

遇到需求，首先做的不是一口答应承接下来，而是和业务确定具体要做的事情，然后拆分需求。根据业务方的指引与自己的认识，开始不断找各个对应的后端同学去学习和了解完成需求的方式。我记得有好几个下午，我都坐在之前哇哦视频后端同学的身边，不断询问和学习着后端完成问题的思路。

逐渐的，自己的状态从 “这个需求我该怎么做” 开始向 “这个需求我觉得应该这么做” 转变，整个人面对后端的工作状态从手忙脚乱像游刃有余转变。（其实这也算能力升级吧~毕竟可以 Hold 住更多的事情了）

总结

在整个迁移的过程中，个人最深刻的感受便是“撕裂”。因为 Serverless & FaaS 并不仅仅只是一种编程方式，它更多的是给了你去 Owner 业务的机会。

而为了把握住这个机会，你需要或主动或被动的去 Push 自己学非常多的东西，也需要思考比之前多的场景，比如：

• 业务的完整链路
• 业务需求与最终目标的关系
• 后端的工作方式
• 中间件、数据库、运维……
• ……

不断的学习新东西，不断的思考更多，不断的对原有自己造成更大的冲击。如果要给我迁移 FaaS 期间的感受下一个总结，那么一定是：“在撕裂中成长”。

回到我们最初的疑惑，我想我可以对第一个问题进行解答了：

Q：FaaS 在业务中能落地吗？ A：能，虽然过程很辛苦，但现在你们落地应该会好很多，因为坑都被我们填的七七八八了

而关于第二个问题：“FaaS 能帮助前端同学实现能力升级吗？”，我想看完全文的你，心中已经有了答案。

Q：FaaS 能帮助前端同学实现能力升级吗？ A：能，且能力升级并不止于技术，更多的是业务思维的成长。FaaS 使得前端有机会可以更深入业务，从而更好的去支持业务。技术能力与业务思维共成长，非凡不止一面。

招聘

淘系技术部 - Node.js 架构组招聘啦，招聘级别： P6/P7 ，工作年限 2 年以上。对 Node.js 感兴趣的小伙伴一定要抓住机会，我们需要优秀的你与我们一起，探索 Node.js 未来更多的可能性~

岗位描述：

1. 负责 AliNode 的设计、研发和维护，支撑阿里集团旗下公司的 Node.js 生态
2. 负责 Serverless 场景 Node.js 函数运行时的设计和优化
3. 负责高性能 Node.js C++ Addon 开发（C++ 岗位要求）

岗位要求：

1. 有强烈的技术热情，工作责任感，具备迅速掌握解决问题所需技术的方法和能力；
2. 熟练掌握 Node.js 或 C++ 作为开发语言，具备优秀的编程素养；
3. 熟练掌握调试工具和调试方法，具备调试复杂软件的能力（比如虚拟机或编译器）者优先；
4. 具备下列一项或多项领域知识或设计和开发经验甚佳：V8/JSCore/SpiderMonkey/Chakra等任一脚本引擎、系统性能分析工具和方法、编译器设计和开发；
5. 有良好的表达能力，善于运营开源项目和开源社区，持有具备影响力和 Javascript 语言技术相关的开源项目者优先。

有意向的同学可以发送简历至 fanyi.lzj@alibaba-inc.com，我们会第一时间安排面试。

“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”

来源：oschina

链接：https://my.oschina.net/u/3874284/blog/3175330