哇哦视频 ❤️ FaaS - 迁移前后的那些事儿
作者:繁易 发布于:2019-11-13 14:59:06


前言


作为一位技术同学,我相信你对于今年集团内部 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 使得前端有机会可以更深入业务,从而更好的去支持业务。技术能力与业务思维共成长,非凡不止一面。