作者|刘子健（繁易）阿里巴巴高级前端工程师
2019年，在阿里巴巴集团内部技术论坛上对于Serverless和FaaS的讨论非常火热。
而这些疑惑对于刚开始接触FaaS的我而言，只会多不会少。恰好，我所负责的“哇哦视频”业务是淘系第一个基于NodeFaaS开发的线上业务，在线上已经稳稳当当的跑了4个月，这期间不仅接手了Java同学的工作，同时也顺利的承接了日常与双十一需求。
哇哦视频是在手淘首页的短视频导购业务，业务核心目标如下：
打造围绕“人用物”为核心有“温度”的短视频；引导更多的商家视频，商家模板化生产;增加首页分发效率，让用户快速的且容易定位到自己想看的视频内容。
而其作为手淘的导购业务，具有“三高”的特点：
由于是身处手淘首页的业务，其流量相对于普通业务而言是比较高的，属于大流量业务。而流量高的特点也带来了稳定性高的要求，由于用户众多，因此线上的任何不稳定都有可能产生舆情。
而作为导购业务，业务本身还有一个迭代频率高的特性。为了能实现更好的导购效果，业务需要不断的推陈出新，快速建场，从而获得更好的导购效果。
在淘系，随着中台化战略的成熟与导购侧近几年的发展，导购业务的开发工作由独立开发各种能力向中台化支持转变。业务所需要的绝大部分能力均可以由中台提供。
在淘系导购业务现今的开发中，一般都由一位前端搭配一位后端一起完成，每个需求的开发，都需要遵循开发+联调+测试的完整流程去进行。
后端同学得益于中台能力的完善支持，许多代码可以复用，因此开发工作量会小一些。而前端则由于UI开发的特性，许多东西需要推倒重来，难以复用（首页改版，整体样式都换了），所以工作量会稍微大一些。
这一套流程实际上已经相当成熟，但成熟并不代表完美。实际上开发过程中，痛点还是有很多的。
首当其冲的痛点则是联调。在联调期中前后端需要不断对数据字段、业务逻辑进行确认，从而确保需求实现的正确性，而这种密集的沟通所带来的成本是非常高的。
如下图所示，在业务开发中我们发现联调成本一般要占到开发成本的30%左右。
居高不下的联调成本，一方面使得工程师们精疲力尽，另一方面也不利于业务的快速迭代。
值得一提还有前端资源化的痛点。
在目前前后端的分工模式中，前端只负责交互逻辑与相对应的UI实现，对于业务核心逻辑无需过多了解。虽然这使得前端团队可以快速完成某些业务，但同样也带来了前端资源化的隐患。而在强调前端要深入业务，具有商业化思考能力的今天，前端资源化实际上是不利于前端的自身发展的。
吐槽归吐槽，但是工作还是要继续的。既然每天的工作有这么多痛点，那么是否有办法去尝试解决它呢？
出于对自身能力升级的渴望，我主动梳理与分析了当前业务的特性，并且主动要求将哇哦视频作为NodeFaaS的首个试点业务。
哇哦视频后端分析：
哇哦视频是一个主打纯视频的导购业务，流量高。基于对后端代码与日常需求的剖析，总结其特点为：运营位多、强依赖算法推荐、数据源多、无状态服务四点。其中运营位多+强依赖算法推荐的特性，使得业务具有一定的复杂度，改造工作量主要在于理解业务规则，填充数据。
而数据源多则代表其引用的外部服务较多，如视频服务、话题、特斯拉资源位定投等。该部分工作量主要在于熟悉上下游系统。
最后无状态服务是改造FaaS的大利好消息，无状态则意味着横向拓展极其便利，完美契合FaaS的工作场景。（其他导购业务应该也类似）
总结：哇哦视频复杂度适中，无状态的业务模型十分契合FaaS的业务场景，且个人在通读完代码后，有把握能Hold住整个后端业务迁移FaaS的需求。因此我认为哇哦视频迁移FaaS平台是具有高可行度的。
非常顺利，也没有任何波折的，哇哦视频成为了淘系首个NodeFaaS试点业务。怀揣着对于能力升级的渴望，我开始尝试将现有的业务逻辑迁移至NodeFaaS实现。
期望达到的效果如下图所示：
在正式进行迁移前，我和业务方沟通了这个事情对于业务可能产生的影响以及后续规划。业务方对于技术侧的改造是没有意见的，只有一个诉求，那就是业务不受影响。
整个诉求看似简单，拆解下来包括以下三部分：
说起来就是既要快，又要稳，还要能扛住后续需求。
针对这个诉求与当时的实际情况，我采取了以下三个措施，来保障整个迁移对业务侧没有影响：
Copy&Paste听起来像是不光彩的事情，但这并不是一件需要遮遮掩掩的事情。相反我现在还很庆幸自己在迁移刚开始时选择了这样的方式，而没有愣头青一样选择另起炉灶，从零开始。毕竟学会跑之前得先学会走路。
选择从零开始固然炫酷，但是这样难以保障代码的稳定性，毕竟原有的业务代码不仅包含必要的业务逻辑，也包含了诸多的错误处理与边界处理，而技术侧改造是必须要考虑到稳定性问题的。
且对于原有Java代码的Copy也算是一种另类的学习方式了，在这个过程中对于Java开发也有了足够的了解，毕竟在整个集团都是Java技术栈的情况下，对于Java的学习与了解非常有利于后续工作的开展。
非常幸运的是，后端同学的代码质量很高，该有的注释一个不缺（如下图所示），因此整个读代码&Copy的过程非常流畅。
这其实算是一个开发中的小Tricks了，但却足够好用。
在之前的导购研发中，为了避免后端宕机对线上带来的影响，因此网关层做了一个CDN容灾方案，如下图所示：
注释：
对于前端同学而言，当请求线上接口失败时，前端的请求SDK就会根据当前请求数据，去CDN上获取最近成功的数据，从而确保对于用户端产品是可用的。
但目前导购侧的业务基本都接入了千人千面的算法，而CDN容灾的一个缺点便在于只是随机取一份成功数据存入CDN，并不支持千人千面。
非常不妙的是，在我迁移FaaS时，底层能力还相对羸弱，时不时会有宕机等问题，这时候即使有CDN容灾能保障产品可用，但用户侧的体验依然是有一定损失的，属于有损降级。
而此时其实产品需求并未发生较大的变更，原有的Java接口也能继续使用，因此灵机一动准备将Java作为兜底的数据源，确保在降级的请求用户体验是完整的。
整体思路其实非常简单，请求路径整理如下：
在完成代码迁移之后，便开始筹备上线的事情。上线的过程中倒是没有什么故事可以说，波澜不惊的按照既定节奏进行灰度、放量，慢慢的也就上线了。
在整个业务真正交接到自己手中的时候，我开始遇到了真正的麻烦。
随着技术侧改造的完成，业务交给我的新需求也得继续推进，于是迷迷蒙蒙的去参加了很多场业务需求会，接触了很多自己之前作为前端根本不会接触的方面。
遇到需求，首先做的不是一口答应承接下来，而是和业务确定具体要做的事情，然后拆分需求。根据业务方的指引与自己的认识，开始不断找各个对应的后端同学去学习和了解完成需求的方式。我记得有好几个下午，我都坐在之前哇哦视频后端同学的身边，不断询问和学习着后端完成问题的思路。
逐渐的，自己的状态从“这个需求我该怎么做”开始向“这个需求我觉得应该这么做”转变，整个人面对后端的工作状态从手忙脚乱像游刃有余转变。（其实这也算能力升级吧~毕竟可以Hold住更多的事情了）
在整个迁移的过程中，个人最深刻的感受便是“撕裂”。因为Serverless&FaaS并不仅仅只是一种编程方式，它更多的是给了你去Owner业务的机会。
而为了把握住这个机会，你需要或主动或被动的去Push自己学非常多的东西，也需要思考比之前多的场景，比如：
不断的学习新东西，不断的思考更多，不断的对原有自己造成更大的冲击。如果要给我迁移FaaS期间的感受下一个总结，那么一定是：“在撕裂中成长”。
回到我们最初的疑惑，我想我可以对第一个问题进行解答了：
Q：FaaS在业务中能落地吗？A：能，虽然过程很辛苦，但现在你们落地应该会好很多，因为坑都被我们填的七七八八了
而关于第二个问题：“FaaS能帮助前端同学实现能力升级吗？”，我想看完全文的你，心中已经有了答案。
Q：FaaS能帮助前端同学实现能力升级吗？A：能，且能力升级并不止于技术，更多的是业务思维的成长。FaaS使得前端有机会可以更深入业务，从而更好的去支持业务。技术能力与业务思维共成长，非凡不止一面。
淘系技术部-Node.js架构组招聘啦，招聘级别：P6/P7，工作年限2年以上。对Node.js感兴趣的小伙伴一定要抓住机会，我们需要优秀的你与我们一起，探索Node.js未来更多的可能性~