前言
原文参考哇哦视频 ❤️ FaaS - 迁移前后的那些事儿
本文只做了流程的归纳和个人梳理
基础概要
什么是Faas？
FaaS（Functions as a Service）函数即服务，FaaS是无服务器计算的一种形式，当前使用最广泛的是AWS的Lambada。
现在当大家讨论Serverless的时候首先想到的就是FaaS，有点甚嚣尘上了。FaaS本质上是一种事件驱动的由消息触发的服务，FaaS供应商一般会集成各种同步和异步的事件源，通过订阅这些事件源，可以突发或者定期的触发函数运行。现如今互联网上炒的很热的中台概念和FaaS技术很相似。
哇哦视频迁移经历
参考自手淘繁易同学文章
业务前提背景
哇哦视频属于手淘首页导购业务，视频占用流量大；由于用户众多，对于稳定性的要求也极高；占用首页资源需要不断推陈出新，因此迭代频率高也是必然。
在淘系，开发工作由独立开发逐渐向中台化转变，业务所需要的绝大部分能力均可以由中台提供。
研发痛点
- 联调成本过高：在联调期中前后端需要不断对数据字段、业务逻辑进行确认，从而确保需求实现的正确性，而这种密集的沟通所带来的成本是非常高的。居高不下的联调成本，一方面使得工程师们精疲力尽，另一方面也不利于业务的快速迭代。
- 前端资源化：在目前前后端的分工模式中，前端只负责交互逻辑与相对应的 UI 实现，对于业务核心逻辑无需过多了解。虽然这使得前端团队可以快速完成某些业务，但同样也带来了前端资源化的隐患。而在强调前端要深入业务，具有商业化思考能力的今天，前端资源化实际上是不利于前端的自身发展的。因为很多时候前端想去深入业务，想进一步升级自己的能力，但往往会苦于没有相关场景。至于说介入后端的工作领域，毕竟术业有专攻，很多事情也掺和不进去。
于是作者他开始了将哇哦视频作为 Node FaaS 的首个试点业务的迁移之旅。
业务前提
- 不会为技术侧改造预留时间，原定需求要按时完成
- 迁移后线上不能出任何问题，线上对迁移无感知
- 后端工作交接至前端后，对后续需求推进无影响
这三点我认为同样适用于其他场景。因为任何代码重构、迁移等技术层面的改动不应该影响到现在的线上场景和未来的业务推进。
推进步骤
-
快速 Copy Java 代码上线
拷贝粘贴大法听起来不光彩，但时候很多时候比起愣头青式从零开始会好很多。虽然已经中台化，但必要的胶水代码 + 相关的业务逻辑代码， 毕竟在整个集团都是 Java 技术栈的情况下，对于 Java 的学习与了解非常有利于后续工作的开展。同时他们的后端同学java代码质量很高该有的注释一个不缺。
-
使用 Java 兜底，保障线上稳定性
网关层做了一个CDN容灾方案。虽然用户侧的体验是有损降级，但是体验任然是完整的。
之前的：Java 接口 - CDN容灾
现在：FaaS 接口 - Java 接口 - CDN 容灾 谨慎评估后续需求，确保需求可实现
需求该怎么做？笔者描述了一个前端刚转移到后端的同学所面临的困难，哪些该用中台哪些该自己去实现。
和业务确定具体要做的需求，拆分需求，学习后端完成需求的思路。
“这个需求我该怎么做” 开始向 “这个需求我觉得应该这么做” 转变
总结
哇哦视频成为了淘系首个 Node FaaS 试点业务。
整个迁移过程中，Serverless & FaaS 并不仅仅只是一种编程方式，它更多的是给了你去 Owner 业务的机会，需要思考更多的场景：
- 业务的完整链路
- 业务需求与最终目标的关系
- 后端的工作方式
- 中间件、数据库、运维……
- ……
Q：FaaS 能帮助前端同学实现能力升级吗？
A：能，且能力升级并不止于技术，更多的是业务思维的成长。FaaS 使得前端有机会可以更深入业务，从而更好的去支持业务。技术能力与业务思维共成长，非凡不止一面
心得体会
文章虽然没有详细描述每一步迁移如何去做的，但是提供了思路和方向，可以避免一些可能会遇到的坑。同时做了java兜底，技术迁移最重要的前提就是维持前台展示保持不变。
现如今被炒的很热门的”中台“一词，和Fass其实有相类似的关联。而开发人员可以专心写业务这一点，也有助于前端同学更好的去接触到业务逻辑而不是单单停留在展示渲染层面。毕竟任何技术归根结底还是围绕业务去服务的。
