🙋🏻♀️ 编者按：本文是蚂蚁集团前端工程师奇谈在支付宝体验科技沙龙暨数金荟上的演讲内容，欢迎享用～
大家好，欢迎来到支付宝体验科技沙龙，我是来自蚂蚁集团数字金融 余额宝体验技术组 的奇谈，今天我带来的分享是《基于 Serverless 的大前端轻研发平台 - 业务前端研发模式探索》。随着智能化、Serverless 等技术的发展，未来业务前端的发展趋势会是怎样呢？在蚂蚁大流量金融业务背景下，前端如何实现安全生产呢？本次分享会先介绍蚂蚁集团的前端研发体系现状，以及在大流量金融业务安全生产的背景下，前端研发工程师所要面临的研发效能和风险防控挑战等等一系列问题。最后会介绍我们基于Serverless 的轻研发模式在尝试和探索解决这些问题中的实践。希望大家能够从蚂蚁轻研发平台演进的设计思考中，获得一些启迪与新思路。
蚂蚁集团业务前端研发体系
先来看一下蚂蚁集团的业务前端研发体系，按照业务类型分，可以分为 PC web，H5，小程序，native 和 大屏，我们余额宝以 H5，BFF 和小程序居多。
在业务上首选前端低码平台，其次是前端应用框架。图下面可以看到有一块是服务端部署，在蚂蚁或者阿里内部，BFF 是前端的一个特点。那么什么是 BFF 呢？
BFF 是 Backend For Fronted，它可以做请求聚合、数据裁剪等工作，因为前端是我们开发的，我们可以组织数据让它更适合于前端的交互。上面大致介绍了蚂蚁业务前端的研发体系，下面我们看一看在实际的前端开发流程中，前端需要做哪些事情，以及哪些可以提效的点。
目前的前端开发流程
上面的流程大家应该都比较好理解，这里重点提一下“系分” "测分"，系分是系统分析设计，测分是关于测试的分析设计。那系分主要做什么呢？做需求的调研，功能的设计实现，以及需要注意的点，比如扩展性、可维护性、关键代码如何实现等等，总的来说就是你站在系统的角度要如何设计这个功能，同时又能最好的实现需求。
系分一般产出的有流程图，时序图，接口设计说明等等文档。既然有文档，那就有一个地方保存它们。大家在需求前期阶段应该遇到过需求变更的情况，需求变更带来的问题是我们的系分可能要更改，频繁的变更带来的问题是我们的系分文档不保鲜，不保鲜的意思是系分文档已经和最终的需求不一致了，可能是小的需求变更我们懒得去更改，脑子记住就好了，也可能是文档比较多，散落在各个地方，懒得去一个一个找了。
再来看编码过程，企业级的应用打包部署慢，企业级应用通常意味着代码复杂度较高，这是业务的复杂度带来的，另一方面是复杂度带来的依赖多。
最后看一下上线阶段。我们的用户基数大，对安全生产的要求高，带来的问题就是兜底代码多。这个兜底代码是什么呢？比如，如果某一天有个接口或者依赖挂了，我要有监控能主动感知到前端报错了，我们的页面不能直接崩溃，我们会有缓存、重试、降级等等方案来最大限度保证体验。在小公司我一个需求可能3天就搞完上线了，但是在蚂蚁，同样一个需求，我要花5天甚至6天，这多出来的时间就是在搞降级、监控等。总结起来就是，BFF 的引入+安全生产要求高（金融类业务）带来 前端研发复杂度增加。那我们如何解决这个问题呢？
轻研发平台能力
针对上面的 3 类可以提效的点，我们分别用 “文档即代码”，“函数级研发部署”，“一体化研发环境 插件能力” 核心思想来提效。先看第一个核心思想：“函数级研发部署”
我们将多应用级（前端+BFF）利用 Faas 技术变为函数级的研发部署。关于Faas的具体技术细节，可以参考齐穹的《手把手搞定渐进式Node Faas》，下附演讲视频。
针对 BFF 接口，函数级研发部署具有开箱即用，无环境依赖，独立部署等特点。你不需要在本地安装一大堆依赖，搞各种环境问题。也不用为了抢占环境部署代码，每个接口都可以独立部署。
函数级研发不只是能开发 BFF 接口，它还能开发前端一体化卡片。可以看下面这张图：
卡片是在页面上相对独立的一块区域。比如我上面这张，它的 UI 和数据高度内聚，是一个整体，我们可以把 UI 和数据一起下发。说到这里，我要重点介绍一下前端开发的历史转变。刚开始我们叫传统模式，典型的是 PHP、JSP 等，我们把静态页面开发好，交给后端，后端用脚本语言替换动态数据，最终把整个页面一起返回给浏览器。这种模式前后端非常耦合，不利用维护和并行开发，我们有了前后端分离模式。典型的是 Ajax 技术的兴起，前端专注开发页面，后端专注开发服务，前后端的交互通过 Ajax 请求传输数据，这样前后端就可以并行开发了。前后端开发让我们专注各自的领域，但经常我们前端为了让数据更适合于前端交互，会做一些请求聚合、数据裁剪等工作，后来有了 BFF，BFF 让我们可以使用统一的技术栈编写数据服务等一部分后端工作。但它仍然还是分成了前端和 BFF，既然技术栈都统一了，为什么还要分前后端呢？所以我们又回到了传统模式，前端 UI+ 数据一起下发，它可以解决前后端依赖问题。比如你不用担心忘记发布 BFF 接口导致的前端报错了，也不用担心历史的接口如何向前兼容的问题了，因为我们的数据和 UI 是一起下发的，没有接口这一层了。
上面的图演示了一体化卡片开发。下面来看核心思想 2 ：文档即代码。
我们将需求、视觉、系分、测分、代码等等集中管理起来，在一个上下文中，以此来解决文档代码不保鲜。我们还可以利用智能化等技术，自动从文档中生成关键代码、流程图、时序图等，让我们的文档和代码保持同步。
上面这张图演示了文档即代码，可以看到，在我们的研发体系化环境中，需求、视觉、网关配置、接口设计等等各种相关的文档集中在一起，你不需要在各个独立的文档中来回切换。一个小的需求变更，我们顺手就改掉了各个相关的地方。
文档即代码不是简单的把各种类型的文档聚合起来就好了，我们可以通过自动化、智能化等技术，将非结构化、结构化的文档生成我们想要的代码，提高我们的研发效率和质量。比如我们可以使用 D2C 能力，自动将视觉稿生成代码，通过文档中的配置信息，自动生成监控，应急预案等等。下面这个视频演示了 D2C 在一体化研发平台上，如何从一个视觉稿到代码，到调试的流程。👇🏾
那这些能力只能我们轻研发平台自己去做吗？显然不是，我们轻研发平台提供各个阶段的插件能力，你可以通过插件去定制适合你的工作流，也可以通过插件将现有的优秀的第三方能力复用进来。比如上面提到的 D2C 能力，就是基于保险团队的。
最后总结一下上面提到的，轻研发平台三大核心思想：1.文档即代码：将结构化、非结构化的文档集中管理起来，并通过智能化、自动化等技术生成代码2.函数级研发部署：BFF 接口和一体化卡片，独立部署、开箱即用、无环境依赖3.一体化环境插件能力：复用优秀三方能力，定制你的工作流
未来我们业务前端做什么？
最后的最后，未来我们业务前端做什么？下图是我们基于数字金融业务背景下的思考。
