看了这么多“技术原理/顶层设计/平台搭建”相关的文章，相信你一定渴望尝试FaaS，但你也一定有很多疑惑，比如：
FaaS能否落地到商业中？ FaaS能否帮助前端同学提升能力？ ……而这些疑惑对于刚开始接触FaaS的我来说，只是更多，而不是更少。无独有偶，我负责的“哇视频”业务是淘西首个基于Node FaaS开发的线上业务。已稳定上线4个月。在此期间，我不仅接手了Java学生的工作，同时还成功处理了日常和双十一的需求。
背景
哇视频是淘宝首页的短视频导购服务。核心业务目标如下：
围绕“人和事”为核心，创作以“温暖”为核心的短视频；指导更多商家视频和商家模板制作；提高首页分发效率，让用户可以快速便捷地找到自己想要观看的视频内容。
作为移动购物的导购业务，其具有“三高”特点：
因为是手机淘宝首页的业务，所以它的流量相对于普通业务来说是比较高的，属于高流量业务。高流量特性也带来了高稳定性要求。由于用户数量众多，网络上的任何不稳定都可能引发舆论。
作为导购业务，业务本身也具有迭代频率高的特点。为了达到更好的导购效果，商家需要不断创新，快速开拓市场，从而获得更好的导购效果。
淘系导购研发模式
1. 中台化
在淘宝，随着近年来中台化战略的成熟和导购端的发展，导购业务的开发工作已经从独立开发各种能力转向中台化支持。业务所需的大部分能力都可以由中台提供。
这样做的好处是显而易见的。大多数常见的导购业务都可以通过中台能力的组装来快速上线，避免重复开发造成的人力物力的浪费。如下图所示，此时在Wow Video中，后端大部分工作就是调用中台的线上服务和线下服务，编写相关业务逻辑，完成相关需求。
2. 工作流
目前淘宝导购业务的开发中，一般是由前端和后端完成的。每个需求的开发都需要遵循开发+联调+测试的完整流程。
并且我还对Wow Video近期的需求发展做了时间分析。具体结果如下图所示：
后端同学受益于中端能力的完整支持，很多代码可以复用，所以开发工作量会更小。至于前端，由于UI开发的特点，很多东西需要推翻重用，复用难度较大（首页修改，整体风格改变），所以工作量会稍大一些。
这套流程其实已经相当成熟了，但成熟并不意味着完美。事实上，开发过程中还存在很多痛点。
研发模式痛点
1. 联调成本过高
第一个痛点是联调。联调期间，前后端需要不断确认数据字段和业务逻辑，以保证需求的正确性。然而，这种密集沟通的成本非常高。
如下图所示，在业务开发过程中我们发现联调成本一般占到开发成本的30%左右。
联调成本高昂，一方面让工程师疲惫不堪，另一方面也不利于业务快速迭代。
2. 前端资源化
值得一提的是，前端资源利用也存在痛点。
目前前后端分工中，前端只负责交互逻辑和相应的UI实现，不需要了解太多核心业务逻辑。虽然这可以让前端团队快速完成某些任务，但也带来了前端资源消耗的隐患。在强调前端必须深入业务、具备商业化思考能力的今天，前端资源利用其实并不利于前端本身的发展。
因为很多时候前端想要深入业务，进一步升级能力，却常常苦于缺乏相关场景。至于涉足后端工作领域，毕竟行业有专业，很多东西是不能涉及的。
遇见 FaaS
投诉就是投诉，但工作还得继续。既然日常工作中存在如此多的痛点，有没有办法尝试解决呢？
恰巧的是，今年4月，我开始参与淘宝导购系统Node FaaS的建设，开始涉足一些Serverless FaaS相关工作。经过一段时间的基础设施建设，我们需要一个业务作为试点业务来检验工作成果。
出于提升自身能力的愿望，我主动梳理分析了当前业务的特点，主动请求哇视频作为Node FaaS的第一个试点业务。
Wow视频后端分析：
Wow Video是一家专注于纯视频的导购业务，流量较高。通过对后端代码和日常需求的分析，其特点总结为：操作岗位多、算法推荐依赖强、数据源多、服务无状态。
其中，操作岗位多、对算法推荐依赖强的特点，使得业务具有一定的复杂性。改造工作量主要在于理解业务规则和填写数据。
数据源多意味着引用了更多的外部服务，比如视频服务、话题、特斯拉资源位置固定投资等，这部分工作量主要在于对上下游系统的熟悉。
最后，无状态服务对于FaaS 转型来说是个好消息。无状态意味着水平扩展极其方便，完美契合FaaS的工作场景。 （其他导购业务应该类似）
总结：Wow Video的复杂度适中，无状态的业务模型非常适合FaaS业务场景。看完代码，我有信心能够把整个后端业务迁移到FaaS的需求。所以我认为Wow Video迁移FaaS平台是高度可行的。
非常顺利，没有任何波折。 Wow Video成为淘宝首个Node FaaS试点业务。怀着升级能力的愿望，我开始尝试将现有的业务逻辑迁移到Node FaaS 实现上。
想要的效果如下图所示：
迁移进行中
在正式迁移之前，我与业务方沟通了此事对业务可能产生的影响以及后续计划。业务方对于技术方的转型并不反对。需求只有一个，就是业务不受影响。
整个诉求看似简单，其实分为以下三个部分：
技术面改造不预留时间，必须按时完成原有要求；迁移后线上不会出现任何问题，线上感觉不到迁移；后端工作交给前端后，不会影响后续需求的推进。简单来说，就是要快速、稳定、能够承受后续的需求。
针对这个要求以及当时的实际情况，我采取了以下三个措施来保证整个迁移对业务端没有影响：
使用Java在线快速复制Java代码，确保在线稳定性，并仔细评估后续需求，确保需求可实现
1. Copy Java 代码上线
复制粘贴听起来是一件很丢脸的事情，但并不是什么需要遮遮掩掩的事情。相反，我还是很庆幸自己在迁移之初就选择了这种方式，而不是像个傻子一样从头开始。毕竟，你必须先学会走，然后才能跑。
前面说过，哇视频是一个高流量的导购业务。尽管平台中已经集成了很多能力，但必要的粘合代码+相关业务逻辑代码的总行数仍然高达5000行左右。
选择从头开始固然很酷，但很难保证代码的稳定性。毕竟原来的业务代码不仅包含必要的业务逻辑，还包含大量的错误处理和边界处理，必须考虑技术面的修改。稳定性问题。
而复制Java原始代码也算是一种另类的学习方式。在这个过程中，我也对Java开发有了足够的了解。毕竟整个组就是一个Java技术栈，学习和理解Java是非常困难的。非常有利于后续工作的开展。
幸运的是，后端同学的代码质量非常高，并且包含了所有必要的注释（如下图所示），因此整个阅读和复制代码的过程非常顺利。
因此，Wow Video后续FaaS版本测试时，直接0BUG上线，节省了大量返工时间，从而避免对业务需求造成任何影响。
2. 使用 Java 兜底
这实际上是一个正在开发的小技巧，但它足够有用。
在之前导购的研发中，为了避免后端宕机对线上线路的影响，网关层做了CDN容灾方案，如下图：
笔记：
– XCtrl – 前端调用mtop SDK
– TCE – 淘宝导购网关
对于前端同学来说，当请求线上接口失败时，前端请求SDK会根据当前请求数据从CDN获取最近一次成功的数据，从而保证客户端产品可用。
但目前导购端的业务基本都是和千人千面的算法打通。 CDN容灾的缺点之一是它只是随机取出一条成功的数据存储在CDN中，不支持千人千面。
非常糟糕的是，我在迁移FaaS的时候，底层能力还比较弱，时不时就会出现宕机等问题。这个时候，即使有CDN容灾来保证产品可用，用户端的体验仍然受到了一定的损失。这是有损降级。
此时产品需求其实并没有发生明显的变化，原来的Java接口可以继续使用。因此，我突然有了一个想法，使用Java作为底层数据源，以保证降级请求时用户体验完整。
总体思路其实很简单。请求路径组织如下：
上一篇：Java接口-CDN容灾现在：FaaS接口-Java接口-CDN容灾得益于这样的设计，哇视频上线后顽强地活了下来。尽管那段时间底层经常不稳定，但在用户体验上并没有太大损失（两个接口的RT都很短，请求两次基本没用）。
迁移之后
完成代码迁移后，开始准备上线。上线的过程中没有故事可讲。平静地按照既定节奏进行，慢慢上线。
当整个生意真正掌握在我手中时，我开始遇到真正的麻烦。
这个需求我该怎么做？
随着技术侧的改造完成，业务委托给我的新需求还要继续推进，所以我迷迷糊糊地参加了很多业务需求会议，接触到了很多我以前接触过的方面以前从未接触过前端。
但事情进展并不顺利。我刚刚转型做后端，很多事情都很迷茫。所以那段时间每天最大的疑惑就是：“这个需求我该怎么处理？”虽然导购业务都叫中台，但是当有需求到我这里来的时候，我不知道哪些要转给中台，哪些要自己完成。清除。
遇到需求，首先要做的不是同意下一步，而是和业务确定具体要做的事情，然后拆分需求。根据业务方的指导和自己的理解，我开始不断的寻找相应的后端同学来学习和了解如何完成需求。记得有好几个下午，我坐在以前的哇视频后端同学旁边，不断询问和学习后端完成问题的思路。
渐渐地，我的状态开始从“这个要求我该怎么办？”开始转变。到“我认为我应该按照这个要求来做这件事。”整个人的后端工作状态从匆忙变成了安心。 （其实这也算是能力的升级啦~毕竟可以装更多的东西）
总结
整个迁移过程中，个人最深刻的感受就是“撕裂”。因为Serverless FaaS 不仅仅是一种编程方法，它还为您提供了拥有业务的机会。
为了抓住这个机会，你需要主动或被动地推动自己学习很多东西，也需要比以前思考更多的场景，比如：
业务的完整环节，业务需求与最终目标的关系，后端的工作方式，中间件，数据库，运维……不断学习新的东西，不断思考更多，不断产生更大的影响原来的自己。如果非要总结一下FaaS迁移过程中的感受的话，那就是：“在泪水中成长”。
回到我们最初的疑惑，我想我可以回答第一个问题：
Q：FaaS可以落地到商业中吗？ A：是的，虽然过程很辛苦，但是现在落地了应该好多了，因为我们已经把所有的坑都填满了。
至于第二个问题：“FaaS能否帮助前端同学实现能力升级？”，我想看完全文你心中已经有了答案。
Q：FaaS能否帮助前端同学提升能力？ A：是的，而且能力的提升不仅仅是技术的提升，更是商业思维的成长。 FaaS让前端有机会深入业务，更好地支持业务。技术能力和商业思维共同成长，使其在多个方面都变得非凡。
招聘
桃溪技术部-Node.js架构团队正在招聘，招聘级别：P6/P7，工作经验2年以上。对Node.js感兴趣的朋友一定要抓住机会。我们需要优秀的你和我们一起探索Node.js未来的更多可能性~
岗位描述：
负责AliNode的设计、研发和维护，支撑阿里巴巴集团公司的Node.js生态。负责Serverless场景下Node.js函数运行时的设计和优化。负责高性能Node.js C++ Addon开发（C++岗位要求） :010 -1010 具有较强的技术热情、工作责任感，有快速掌握解决问题所需技术的方法和能力；精通Node.js或C++作为开发语言，具有优秀的编程素养；熟练掌握调试工具和方法，有调试复杂软件（如虚拟机或编译器）能力者优先；具有以下一个或多个领域的知识或优秀的设计和开发经验：V8/JSCore/SpiderMonkey/Chakra等任何脚本引擎、系统性能分析工具和方法、编译器设计和开发；良好的表达能力，善于运营开源项目和开源社区，具备以下资格影响力和Javascript语言技术相关开源项目的申请者将被优先考虑。感兴趣的同学可将简历发送至mailto:fanyi.lzj@alibaba-inc.com，我们将尽快安排面试。
用户评论
伱德柔情是我的痛。
哇视频迁移到FaaS笔记，感觉手机淘宝的短视频功能更强大了，期待看到更多精彩内容。
有6位网友表示赞同！
冷风谷离殇
手机淘宝的哇视频换成FaaS笔记，这操作太聪明了，感觉以后刷视频更顺畅了。
有13位网友表示赞同！
你很爱吃凉皮
哇视频迁移到FaaS笔记，这让我想起了以前的短视频平台，希望这次能带来更多创新。
有7位网友表示赞同！
蔚蓝的天空〃没有我的翅膀
手机淘宝的哇视频换成FaaS笔记，不知道会不会影响到我的收藏和点赞，有点担心。
有8位网友表示赞同！
嗯咯
哇视频迁移到FaaS笔记，这个改变让我有点不适应，希望不要影响到我的使用习惯。
有8位网友表示赞同！
浮世繁华
手机淘宝的短视频业务迁移，看来是在寻求新的发展，期待看到更多新功能。
有17位网友表示赞同！
哭着哭着就萌了°
哇视频迁移至FaaS笔记，这个操作挺有意思的，想看看FaaS笔记能带来哪些改进。
有10位网友表示赞同！
白恍
手机淘宝的哇视频改版，感觉像是跟不上时代的潮流了，有点失望。
有20位网友表示赞同！
陌然淺笑
哇视频迁移到FaaS笔记，这个决定有点突然，希望不要影响我的使用体验。
有6位网友表示赞同！
巴黎盛开的樱花
手机淘宝的短视频业务迁移，希望这次能带来更好的用户体验，期待新功能。
有15位网友表示赞同！
残花为谁悲丶
哇视频迁移至FaaS笔记，感觉像是手机淘宝在寻求新的突破口，希望这次能成功。
有5位网友表示赞同！
铁树不曾开花
手机淘宝的哇视频换成FaaS笔记，这让我想起了以前的短视频平台，希望这次能带来惊喜。
有5位网友表示赞同！
病态的妖孽
哇视频迁移到FaaS笔记，这个改变让我有些担忧，怕我的视频数据会丢失。
有5位网友表示赞同！
别在我面前犯贱
手机淘宝的短视频业务迁移，希望这次能带来更好的内容和服务，支持一下。
有20位网友表示赞同！
青衫故人
哇视频迁移至FaaS笔记，这个决定让我有些困惑，不知道该不该继续使用。
有15位网友表示赞同！
我绝版了i
手机淘宝的哇视频换成FaaS笔记，感觉像是手机淘宝在寻求新的发展，期待看到结果。
有13位网友表示赞同！
晨与橙与城
哇视频迁移到FaaS笔记，这个改变让我有些不适应，但还是会继续支持手机淘宝。
有20位网友表示赞同！
各自安好ぃ
手机淘宝的短视频业务迁移，希望这次能带来更好的用户体验，期待新的变化。
有17位网友表示赞同！
金橙橙。-
哇视频迁移至FaaS笔记，这个决定让我感到好奇，想看看FaaS笔记能带来哪些新功能。
有17位网友表示赞同！