淘宝哇哦视频 x FaaS | 迁移前后的那些事儿
前言
作为一位技术同学，我相信你对于今年集团内部 Serverless 与 FaaS 的热度一定有所感知。
在看了那么多“技术原理/顶层设计/平台建设”相关的文章之后，我相信你对 FaaS 肯定产生过跃跃欲试的感觉，但也肯定存在诸多疑惑，例如：
FaaS 在业务中能落地吗？
FaaS 能帮助前端同学实现能力升级吗？
……
而这些疑惑对于刚开始接触 FaaS 的我而言，只会多不会少。恰好，我所负责的“哇哦视频”业务是淘系第一个基于 Node FaaS 开发的线上业务，在线上已经稳稳当当的跑了 4 个月，这期间不仅接手了 Java 同学的工作，同时也顺利的承接了日常与双十一需求。
关于上面的这些疑惑，经过了这四个月的考验，我想我已经有了自己的答案。接下来我将会向大家分享我这四个月的历程，带大家一起看看，在一名一线业务同学的眼中，FaaS 究竟会给前端同学带来什么？
背景
哇哦视频是在手淘首页的短视频导购业务，业务核心目标如下：
打造围绕“人用物”为核心有 “温度”的短视频；引导更多的商家视频，商家模板化生产;增加首页分发效率，让用户快速的且容易定位到自己想看的视频内容。
而其作为手淘的导购业务，其具有“三高”的特点：
由于是身处手淘首页的业务，其流量相对于普通业务而言是比较高的，属于大流量业务。而流量高的特点也带来了稳定性高的要求，由于用户众多，因此线上的任何不稳定都有可能产生舆情。
而作为导购业务，业务本身还有一个迭代频率高的特性。为了能实现更好的导购效果，业务需要不断的推陈出新，快速建场，从而获得更好的导购效果。
淘系导购研发模式
中台化
在淘系，随着中台化战略的成熟与导购侧近几年的发展，导购业务的开发工作由独立开发各种能力向中台化支持转变。业务所需要的绝大部分能力均可以由中台提供。
这么做带来的好处是显而易见的。大部分常见的导购业务，都可以通过中台能力的组装从而实现快速上线，避免重复开发带来的人力物力的浪费。如下图所示，此时在哇哦视频，后端绝大多数的工作在于调用中台的在线服务与离线服务，编写相关的业务逻辑来完成相关需求。
工作流
在淘系导购业务现今的开发中，一般都由一位前端搭配一位后端一起完成，每个需求的开发，都需要遵循开发 + 联调 + 测试的完整流程去进行。
而我也针对于哇哦视频最近的几次需求开发做了时间的分析，具体结果如下图所示：
后端同学得益于中台能力的完善支持，许多代码可以复用，因此开发工作量会小一些。而前端则由于 UI 开发的特性，许多东西需要推倒重来，难以复用（首页改版，整体样式都换了），所以工作量会稍微大一些。
这一套流程实际上已经相当成熟，但成熟并不代表完美。实际上开发过程中，痛点还是有很多的。
研发模式痛点
联调成本过高
首当其冲的痛点则是联调。在联调期中前后端需要不断对数据字段、业务逻辑进行确认，从而确保需求实现的正确性，而这种密集的沟通所带来的成本是非常高的。
如下图所示，在业务开发中我们发现联调成本一般要占到开发成本的 30% 左右。
居高不下的联调成本，一方面使得工程师们精疲力尽，另一方面也不利于业务的快速迭代。
前端资源化
值得一提还有前端资源化的痛点。
在目前前后端的分工模式中，前端只负责交互逻辑与相对应的 UI 实现，对于业务核心逻辑无需过多了解。虽然这使得前端团队可以快速完成某些业务，但同样也带来了前端资源化的隐患。而在强调前端要深入业务，具有商业化思考能力的今天，前端资源化实际上是不利于前端的自身发展的。
因为很多时候前端想去深入业务，想进一步升级自己的能力，但往往会苦于没有相关场景。至于说介入后端的工作领域，毕竟术业有专攻，很多事情也掺和不进去。
遇见 FaaS
吐槽归吐槽，但是工作还是要继续的。既然每天的工作有这么多痛点，那么是否有办法去尝试解决它呢？
恰好今年的四月份我开始参与淘宝导购体系 Node FaaS 相关建设的工作，开始接触到一些 Serverless & FaaS 相关的工作。在经过一段时间的基础建设后，我们需要一个业务作为试点业务来检验工作成果。
出于对自身能力升级的渴望，我主动梳理与分析了当前业务的特性，并且主动要求将哇哦视频作为 Node FaaS 的首个试点业务。
哇哦视频后端分析：
哇哦视频是一个主打纯视频的导购业务，流量高。基于对后端代码与日常需求的剖析，总结其特点为：运营位多、强依赖算法推荐、数据源多、无状态服务 四点。其中运营位多 + 强依赖算法推荐的特性，使得业务具有一定的复杂度，改造工作量主要在于理解业务规则，填充数据。
而数据源多则代表其引用的外部服务较多，如视频服务、话题、特斯拉资源位定投等。该部分工作量主要在于熟悉上下游系统。
最后无状态服务是改造 FaaS 的大利好消息，无状态则意味着横向拓展极其便利，完美契合 FaaS 的工作场景。（其他导购业务应该也类似）
总结：哇哦视频复杂度适中，无状态的业务模型十分契合 FaaS 的业务场景，且个人在通读完代码后，有把握能 Hold 住整个后端业务迁移 FaaS 的需求。因此我认为哇哦视频迁移 FaaS 平台是具有高可行度的。
非常顺利，也没有任何波折的，哇哦视频成为了淘系首个 Node FaaS 试点业务。怀揣着对于能力升级的渴望，我开始尝试将现有的业务逻辑迁移至 Node FaaS 实现。期望达到的效果如下图所示：
迁移进行中
在正式进行迁移前，我和业务方沟通了这个事情对于业务可能产生的影响以及后续规划。业务方对于技术侧的改造是没有意见的，只有一个诉求，那就是业务不受影响。
整个诉求看似简单，拆解下来包括以下三部分：
不会为技术侧改造预留时间，原定需求要按时完成。
迁移后线上不能出任何问题，线上对迁移无感知。
后端工作交接至前端后，对后续需求推进无影响。
说起来就是既要快，又要稳，还要能扛住后续需求。
针对这个诉求与当时的实际情况，我采取了以下三个措施，来保障整个迁移对业务侧没有影响：
快速 Copy Java 代码上线。
使用 Java 兜底，保障线上稳定性。
谨慎评估后续需求，确保需求可实现。
Copy Java 代码上线
Copy & Paste 听起来像是不光彩的事情，但这并不是一件需要遮遮掩掩的事情。相反我现在还很庆幸自己在迁移刚开始时选择了这样的方式，而没有愣头青一样选择另起炉灶，从零开始。毕竟学会跑之前得先学会走路。
前面也提过，哇哦视频是一个大流量导购业务。即使诸多能力已经中台化，但必要的胶水代码 + 相关的业务逻辑代码，总行数也高达 5000 行左右。选择从零开始固然炫酷，但是这样难以保障代码的稳定性，毕竟原有的业务代码不仅包含必要的业务逻辑，也包含了诸多的错误处理与边界处理，而技术侧改造是必须要考虑到稳定性问题的。
且对于原有 Java 代码的 Copy 也算是一种另类的学习方式了，在这个过程中对于 Java 开发也有了足够的了解，毕竟在整个集团都是 Java 技术栈的情况下，对于 Java 的学习与了解非常有利于后续工作的开展。
非常幸运的是，后端同学的代码质量很高，该有的注释一个不缺（如下图所示），因此整个读代码 & Copy 的过程非常流畅。
也因此在后续 FaaS 版本的哇哦视频提测时，是 0 BUG 直接上线的，节约了大量的返工时间，从而避免对业务需求造成影响。
使用 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 架构组高级前端工程师，负责 Serverless 框架的设计与落地等相关工作。个人热爱前端与 Node.js，目前主要关注 Serverless、云+端等技术方向。
本文缩略图：icon by ionchan
Tips：
# 点下“在看”❤️
# 然后，公众号对话框内发送“杯刷”，试试手气？????
# 本期奖品是来自淘宝心选的椰棕杯刷。