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

前言

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 的首个试点业务。

非常顺利，也没有任何波折的，哇哦视频成为了淘系首个 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 容灾方案，如下图所示：

对于前端同学而言，当请求线上接口失败时，前端的请求 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 语言技术相关的开源项目者优先。

有意向的同学可以发送简历至 [email protected]，我们会第一时间安排面试。