转发：千万级流量业务的 Serverless 实践，看 FaaS 给前端带来的变化
2019 年初，淘系技术部启动了 Serverless 研发模式升级计划。而哇哦视频作为首个落地的业务，迄今已有半年。
本次则会为大家分享哇哦视频在这半年中发生的故事，与大家一起看看在一线业务同学的眼中，Serverless 会给前端同学带来什么，而我们又能收获什么？
分享内容
本次分享我会从以下三个部分出发：
- 业务落地
- 从零到一
- 未来抉择
JavaScript 开发者报告中，关于测试框架一项，Mocha 的人气在持续的走低，而 Jest 作为近两年的新起之秀，人气在不断的升高。因此我们在原有的 Mocha 支持上，又新增了 Jest 的支持。
同时哇哦视频有着通过单测保障代码质量的需求，因此我们也打通了 FaaS 函数在内部 Ci 系统单元测试的链路。
错误处理
其实这部分与实际的代码书写风格相关，虽然说是战时盯着屏幕看监控，但是如何第一时间发现错误源于何处，是否需要处理其实是值得琢磨的问题。毕竟无效的监控一多，人就会陷入到报警疲劳中。
在这儿，哇哦视频采取对于错误采取了以下的几个小策略，确保线上可以快速定位问题：
- 错误分级：将错误分为 忽略/警告/重视 3 种等级，方便一眼确认重要错误
- 自定义错误名：将错误自定义名称，而非是笼统的 Error，方便迅速确认具体错误
- 携带关键信息：针对不同错误，携带不同关键信息，方便快速定位与复现问题
简单示例如下：
而在实际业务中的监控中，实际上会较容易的区分与定位错误：这样最终是对于线上问题的排查与修复是有帮助的。
Java 兜底
对于 Java 兜底，我现在就一个感觉，真香！
虽然这是一个临时性的方案，但是在你出问题时还有兜底的服务可以帮忙扛着，无比安心呀。
具体实现上非常简单，实际上就是在请求自己接口失败时，再去请求一次 Java 接口，确保可以提供服务。毕竟两个应用同时都宕机的几率是非常低的。
发布流程
这部分主要与代码的发布，我们提供了一站式的研发平台，来帮助你管理函数，实现版本管理与回滚等功能。
调试闭环
对于现代化的开发而言，调试是必不可少的一项能力。在此 Sandbox 平台 提供了一站式的调试闭环服务。我们可以在函数中启用远程调试，然后在预发去调试代码，从而帮助我们更快的去定位问题。
函数监控
关于函数监控，在此我们也提供了一站式全功能的 Node.js 治理平台，Sandbox。包括运维数据、链路分析、监控告警、白屏化日志四大功能。
运维数据
在此，我们可以通过 Sandbox 提供的功能，清楚的看到当前函数的运行数据。功能也非常简洁明了。
链路分析
在阿里做后端，怎么能缺少全链路分析的辅助。
在此，Sandbox 也对全链路分析做了支持。
对于函数的每个请求，我们可以查看到其链路的详情与对应的链路，帮助我们快速定位到链路问题。而针对于错误链路，在这里也能看到其对应的链路分析与错误的日志。
白屏化日志
Sandbox 也提供了白屏化日志的功能，通过查看实时日志，可以有效的了解函数情况。
监控报警
Sandbox 提供了监控报警的功能，在这里我们可以设定自己的报警项。在报警触发时，会通过短信电话等方式实时通知到同学。
配合之前提到的那些功能，可以使得快速发现并定位修复故障。
FaaS 的业务能力
基于以上的这些功能，与哇哦视频业务长达半年的实践与踩坑，我们可以说：
“FaaS 函数工具完备，完成业务就像是搭积木一样！”
如果有相关业务需求的同学，可以大胆的放心的使用 FaaS 去完成。
未来抉择
这部分是业务迁移 FaaS 半年后，个人的一些思考与总结。
研发模式升级推论
首先先看一个研发模式升级的推论。
- 因为：我们在技术上使用 Serverless
- 所以：实现前端能力升级
- 结果：助力业务先赢
这个推论听起来好像是很正确的一件事情，但却让我想起我之前听到的一个故事。
故事：科技改变生活
都说科技改变生活，以前我们遇到不懂的问题，要去图书馆查资料。
而现在，遇到不懂的问题，我们只需要掏出手机，然后，你就会忘记这个问题。
而这个故事和之前研发模式升级的推论，在我看来是差不多的。虽然我们有了新的方式去解决问题，但最后的结果可能天差地别。
在这里我就发现前端能力升级，并不一定能助力业务先赢，这也是困扰我长达半年之久的问题。
我在哇哦视频的选择
“研发模式升级究竟能否助力业务先赢？”
这个问题就像心魔一样在我心头萦绕，但遇到问题就要解决问题。总得试试看，因此在半年内，分为 3 个阶段，我做了如下的一些尝试。
支撑（19.06 - 19.09）
第 1 个阶段我称为支撑，时间是 19 年的 6 月份到 19 年的 9 月份。
在这期间我对自己的要求就只有一个，那就是“活下来”。因为首先要能做业务，才有后续与业务谈价值的可能性。否则都只是空中楼阁罢了。
对话（19.10 - 19.11）
第 2 个阶段我称为对话。
在能做业务的基础上，我开始尝试去理解业务数据，主动去沟通、学习、了解相关业务领域知识。并且在遇到问题时会习惯性与业务方进行沟通，看看这个问题，从业务视角出发是如何理解的。
助力（19.12 - 至今）
第 3 个阶段我称为助力。
在逐渐理解业务规划、与业务方也有了一定的信任后，我开始尝试参与部分业务规划，与业务方一同去挖掘痛点。同时同时站在技术的角度上做一些技术预研，尝试为业务带去更多的发挥空间。
抉择
在我刚提到的第一阶段“支撑期”时，我经历了非常长一段时间的思想抉择。
在我可以支撑业务时，当时的我面临着两个选择：
- 做一辈子的业务工具人：业务说什么我做什么，承接需求就好
- 尝试做一次业务合伙人：试着给自己提出的问题（研发模式升级究竟能否助力业务先赢？）找一个答案
当时的纠结在现在看来，主要是以下几点：
- 作为一名技术同学，尝试着做非常多看起来与技术不相关的事情，风险高难落地拿不到结果
- 受非技术因素影响多，业务的走向与起起落落，并非是技术可解的问题
- 做成了可能与技术无关，做不成却一定有自己的问题
但最终我还是选择尝试做一次“业务合伙人”，因为我觉得如果研发模式升级如果不能证明它能助力业务先赢，那么整个战役实际上是失败的。对于自己而言，也只是简单的完成了一次业务迁移的过程，而没有真正的去解决问题。
比起拿到迁移的结果，我更想知道研发模式升级的答案。
业务对话
在下决定后，我开始按自己的思路去做这一切的事情。
首先是对既有经验的一个学习。正好最近阿里经济体前端委员会在阿里技术论坛出品了《技术与业务同行》这个专题，里面有非常多业务思考的文章，细细拜读后收获颇多。
在拜读相关文章后，我开始主动去了解业务的数据，目标与未来的规划，且在此基础上，我开始主动要求与产品经理，去做一个沟通，希望能去与业务方，共同了解整个产品业务的规划与交流。
在这之后，我被邀请去参与哇哦视频用户调研活动。这也是我第一次面对面的去与用户对话，了解用户的真实需求。
而在与用户面对面沟通后，我发现自己业务思考上的诸多盲区。这件事情也是一个警醒，虽然我自诩为前端是离用户最近的岗位，但实际上与用户面对面之后，才知道实际上相差甚远，比起自嗨，我们仍然需要更多的去倾听用户的声音。
例子：承接手淘 Push
哇哦视频的业务方之前一直存在一个痛点，那就是业务入口流量不足。在与业务频繁对话的那段时间，这个问题时常会被提起。
针对这个问题，我开始尝试与业务方讨论有没有相应的解法，最终将目标锁定在使用手淘 Push 消息的能力来为业务导流。
与业务方沟通并达成一致后，技术侧迅速开始了改造，为哇哦视频新增了承接手淘 Push 的能力，且随着消息的推送，不断进行相应的调整与优化。
在多日的持续优化下，哇哦视频通过手淘 Push 实现 UV 单日最高提升 20%+的结果。
而在经过这件事情后，我想我找到了“研发模式升级究竟能否助力业务先赢”这个问题的答案：Serverless 是前端撬动业务场景的一把利剑。
总结：FaaS 给前端带来的变化
在我之前写的文章《哇哦视频 ?? FaaS - 迁移前后的那些事儿》中，公司的同事留了一句评论：
