背景介绍
从2019年开始，作为集团FaaS的实践先锋队，大淘宝技术行业团队在FaaS领域摸爬滚打了三年，并在iFashion、天猫运动等多个业务场景落地。这篇文章是想分享一下我们在FaaS化过程中的经验，尝试回答关于FaaS的Why、What、How三个问题，给对FaaS有兴趣的同学提供一些实践经验。
业务背景
▐ 行业业务特点
大家可以在手机淘宝搜索“淘宝吃货”、“iFashion”等关键词，会进入一个轻应用，这些轻应用都是行业运营的阵地。
上图展示了轻应用的典型数据逻辑。这些轻应用的主要逻辑都在BFF层，大量的需求都是进行接口和数据的拼装，比较适合FaaS接入。以运动频道的Feeds模块为例，其流程如上图所示。其中蓝色部分是运营小二的离线配置，红色部分为在线链路，这个流程对大部分的频道模块都是适用的。
行业数据逻辑的特点是大部分的数据能力都是已有的中台能力，我们只是在BFF层做数据的拼装。“重流程编排，轻数据资产”的特性，决定了行业频道的Java部分大部分时候都是在做一些接口的聚合调用，把数据组织成前端模块需要的结构占开发工作很大的比重。这种场景比较适合前端用FaaS来全部承接，去掉前后端对接的过程，即可以减少总体人力投入，又可以使前端能够深入业务底层逻辑。
▐ 生产关系的转变
如上图所示，在FaaS化之前，传统的前后端分离的生产关系存在天然的缺陷。由于数据拼装本身和UI逻辑是强耦合的，分成两个人去做，会导致存在天然的边界不清、联调成本高等问题，导致整个需求的开发周期变长。我们希望把逻辑拼装交给前端来做，而后端下沉到数据中台，专心做对他们来讲价值更好的中台服务。这样可以实现三方共赢。改变之后的生产关系如下图所示：
▐ FaaS化进展和收益
大淘宝行业除了个别业务外，前后有超过10个轻应用完成了FaaS化，大部分需求由前端独立承接。前端在业务中从一个写页面的工具人，变成了深入业务逻辑，有业务话语权，并能推动业务发展的合伙人。
FaaS化对前端来说，本质上是进行了生产关系的转变，而这个生产关系的转变，不仅仅是我们抢了后端的活。任何团队在思考FaaS的时候，第一个想到的肯定不是怎么做，而是为什么这么做？带来的价值是什么？
我想从3个层次来说明FaaS化打来的价值，而这三个维度正如上图所示，其实是一个递进的关系：
- 赋能前端：从前端自己的角度来讲，通过FaaS扩大职责边界，可以更加深入业务，从一个业务资源变成业务的主人，才有可能真正为业务的目标起到自己的作用（而不是简单的接需求）。
- 提升总体研发效率：传统前后端分离的研发方式，每个需求都需要至少2个技术同学参加，且有大量时间在进行沟通和联调。现在需求只需要一个前端同学参与，且自己定义前后端接口和逻辑，更加灵活方便。
- 成为业务合伙人：对于产品运营来说，他们不是很关注研发效率，如何帮助促成业务目标，比如提升总成交额，是他们比较关心的。生产关系的转变，最终需要回归业务，需要思考如何为业务创造价值。这方面我们还在探索中，有一个方向是通过数据分析驱动精细化运营。
大淘宝FaaS解决方案
从19年的哇哦视频FaaS化开始（传送门 哇哦视频FaaS），FaaS解决方案经过3年的不断探索发展，已经有比较成熟解决方案，这是一个简化版的FaaS架构：
- Serverless研发平台提供了完善的FaaS研发链路，包括从创建、发布到运维的完整能力，并提供了多个个性化解决方案和租户自定义能力
- 基础设施层提供了FaaS Serverless 解决方案，包括：FaaS编程平面、丰富的中间件、运行时容器、高可用性保障等。
- 底层服务包括通用的算法、数据存储能力，行业团队自定义的服务以及二方三方的通用能力，这些能力都可以通过中间件进行调用
行业的实践经验
▐ 怎么判断我的业务场景是否合适
虽然每个业务场景都有自己的特色，要不要用FaaS取决于两个方面：成本和收益。我们分别说说这两个方面应该如何考量。
成本 |
人力成本 |
由于前端做了更多的事情，无论总体研发效率是否提升，前端的工作量都是会提升的，当前团队是否有足够的时间和精力？ |
| 技术难度 |
|
|
| 收益 |
研发效率 |
通过减少联调、代码同构等方式提升研发效率 |
| 前端能力 |
前端可以通过FaaS扩大职责边界，更加深入业务。 |
正如前文所说行业团队目前是选择在“重逻辑编排、轻数据资产”的行业频道中进行FaaS实践，实际上除了做BFF编排之外，根据业务需要我们也做了离线任务、数据存储等大前端之外的工作。大家可以从上面的几个维度，来衡量RIO，再决定是否使用FaaS。
▐ 如何从零开始在业务中落地FaaS
如果是新业务，评估过成本和收益的合理性后，用FaaS承接一般不存在问题。这里主要针对老业务，一般情况下我们都是对已有的业务进行FaaS化改造，有两种方案推进的方案：
- 一次性全部迁移
- 在天猫V榜、iFashion等业务中，我们采取的是全盘重构的方案，专门抽出一个月左右的时间把所有的Java代码翻译成等价的FaaS代码。
- 这个方案的好处是可以一次性解决历史遗留问题，以后可以专心做FaaS。难点是复杂的业务可能迁移时间很长，如果同时进行业务需求就会很被动，并且进行这么大的改动有较大风险。
- 新需求逐步迁移
- 运动、吃货等频道采取的是这个方案，在接新需求的同时，把已有的Java代码迁移成FaaS，一些改动很大的需求直接重写。对于没有需求的老模块，保持原状直到有新需求。
- 这样做的好处是循序渐进渐进，工作量和风险都可控；不足之处是持续时间比较长，且每次业务需求都会花额外时间进行代码迁移导致需求交付周期变长。
方案1都是早期进行时采取的，可以比较快拿到结果，但风险也较高。目前我们都是采用方案2，在业务中逐步进行FaaS化改造，也推荐大家采用方案2。
FaaS的研发链路相比于传统的前端研发，也多出了很多环节。如上图所示，其中灰色的环节大家比较熟悉，橙色的环节对部分前端同学来说可能比较陌生。FaaS和前端最大的区别在于，我们需要关注2个新的方面：
- 数据逻辑：我们需要知道数据从哪里来，怎么接入，如何组织数据。
- 大流量场景：需要评估流量有多大，大流量下对整个系统的承载能力要有一定的要求。需要通过压测来保障大流量场景的稳定性
- 运维：即使Serverless少了很多运维工作，对数据的监控以及应急处理线上故障的工作还是必不可少的。
▐ 稳定性保障
首次上线FaaS函数后，最担心的情况就是线上时不时会出现一些错误率、RT等告警，让人寝食难安。前端同学对传统后端的稳定性保障缺少经验，我总结了下，大家可以从如下几个方面保障业务的稳定性：
这里重点说一下流量评估和兜底方案。
- 流量评估：流量评估有两个目的，一是为了计算出对下游依赖服务的流量，二是为了计算出需要的容器数。
- 如何评估峰值流量QPS？对于大促场景，我们一般会结合去年同期的大促流量加上今年的预期做一个评估；对于一些日常流量比较稳定且均匀的业务，一般会可以用这个经验公式计算平均QPS：
平均QPS = 日均PV/5万，用平均QPS乘以一个安全的系数作为峰值QPS - 单容器并发能力？单容器的并发能力可以通过小流量的压测来确定，不过大部分时候不用特别精确，因为很可能业务需求的变更就会导致容器并发能力的变化，对于流量比较小的业务，很多时候就用默认值即可
- 兜底方案：线上接口无法做到100%的成功率，一方面因为任何Serverless容器都无法保障100%的稳定性，以阿里云为例，承诺SLA为99.975%（云服务器ECS服务等级协议）；另一方面是接口依赖的下游服务也存在一些不稳定性。对于这种系统层面的风险，我们通过兜底方案来解决。兜底服务的原理，是每隔固定一段时间，就会把接口的成功数据写到服务器缓存和CDN中，如果接口出现问题，就会从缓存或者CDN中去读上一次写入的兜底数据。降级后的数据存在的一个问题就是无法做到千人千面，因为千人千面去存数据的话量太大。
云服务器ECS服务等级协议地址： https://terms.aliyun.com/legal-agreement/terms/suit_bu1_ali_cloud/suit_bu1_ali_cloud201909241949_62160.html?spm=a1zaa.8161610.0.0.291545367B6t5A
▐ 其他一些经验
- 性能优化：FaaS函数理论上应该能达到和Java函数同等的性能指标，比如典型的招排补逻辑， RT 一般是在
250ms左右。性能优化体现在两个方面：编码和架构。编码层面上应该尽量避免串行请求，减少不必要的字段解析和传输，灵活应用缓存。架构层面可以结合SSR、边缘计算等方式提升首屏性能。 - 人员能力：一些前端同学对于后端架构了解不深，在刚开始做FaaS的时候面对大量的后端名词时候，往往会一头雾水，甚至无法正常评审业务需求。如果每次碰到不同的地方再去学习，很容易陷入到碎片知识总中，缺少对整个体系的整体认知。我们在很久以前对团队做过一个专题培训，并沉淀了一个系列文档，从大的框架上阐述了整个数据架构。
- 资产沉淀：FaaS实践中，约一半的工作都在进行各种字段的补全，我们把这些补全都根据实体的不同，沉淀到实体数据模型中。另外还有有一些通用的faas函数可以做成服务给其他的业务调用。这些都是比较有价值的FaaS资产。
低代码探索经验
在源码研发的过程中发现，行业业务大部分都具有一样的逻辑模式：召回->补全->排序。我们尝试通过一种低代码的方式，能减少这种重复的编码工作，用可视化的界面编排出这种数据逻辑。经过大半年的探索，我们创建了织郎平台，并在三个BU中生产了1000+接口，服务100+用户。
织郎平台提供了如下一些能力：
- 可视化编排：通过可视化操作编排出FaaS接口。
- 完整研发链路：创建、编辑、发布、监控等完整的研发流程，并且能大幅缩短构建发布时间。
- 运行时环境隔离：在相同容器中，运行时对租户和函数的隔离，可以极大提升容器的利用率。
- 开放协议：织郎定义了一套JSON协议和配套的SDK，业务方可以在这套能力上构建出符合自己需求的上层产品
总结
Node FaaS 对于前端工程师的意义在于它可以拓展我们的能力边界，让我们有能力用自己熟悉的知识去做更多的事情。而一旦我们用Node FaaS去做一些事情，那就不仅仅是我们自己的工作变了，而是整个研发的生产关系发生了变化。怎么从这个变化的生产关系中找到实际的价值，是我们需要深入思考和探索的。如果大家有做FaaS的打算，不要盲目开始，除了文中说的价值判断原则外，可以先问自己一个灵魂问题：
你们搞Node FaaS不就是抢了Java的活么？
