过去两年，飞猪前端一直在积极地进行Serverless建设和实践，年-年我们和集团Node架构组、研发平台一起完成了基础能力的建设和业务试点，成为集团率先落地Serverless实践的BU，年-年我们开始大规模地在飞猪推广使用Serverless的能力，从导购全链路到核心中后台，都能够看到Serverless的身影，这一年我们完成了Serverless从业务试点到生产力工具的转变，本文将主要分享飞猪基于Serverless的实践成果以及未来想要做的事情。
Serverless的使用规模
年-年飞猪Serverless的规模和重要度都有很大的变化，主要表现在三方面：
一是函数组规模增长一倍以上，Qps峰值增长%。二是使用FaaS开发的人员规模增长%，其中前端人员80%以上参与到FaaS的开发中。三是影响力的表现，目前不仅飞猪前端都对Serverless很熟悉，客户端也有很多人参与到FaaS的开发，更重要的是后端和产品同学也知道我们有Serverless进行服务开发的能力。
具体的数据如下：
为什么要引入Serverless
飞猪为什么这么迫切地要引入Serverless？这主要是出于前后端研发模式升级以及前端职能扩展的考虑，下面回顾一下飞猪前端架构的发展和研发模式的演进。
1.飞猪前端架构的发展
飞猪前端架构总结下来就是从最初纯粹的前端开发，到解决多端一致性的跨端开发，再到接管视图服务端逻辑的前台开发，Serverless就是前端升级转变的核心一环。
2.研发模式的演进历程
前端人员为什么一定要参与服务侧开发？从前后端研发模式的演进来看，主要经历了以下三个大的阶段： 阶段是资源解耦，这个阶段前端把静态资源分离出来部署到cdn，解决了和后端服务同机部署的耦合。第二阶段是模板解耦，我们之前提到的前后端解耦大部分指的就是模板的解耦，一种不彻底的解法就是渲染解耦，服务端放一个空模板内容部分全靠CSR，彻底的解法就是前端接管模板，可以独立部署模板也可以使用node.js替代。第三个阶段就是试图解耦，一方面是由于客户端体系和前端的离线体系的限制，端侧对于视图的动态性要求极高，没有服务侧能力的前端只能将视图的动态性放在服务端做，另一方面由于端侧架构对于数据接口协议的特殊要求，需要服务端来进行协议的转换，也就是服务端常说的Do到Vo的处理，这就造成了前后端视图的耦合，为了去除这部分耦合，前端通过Node.js做BFF层来接管视图层的逻辑，Serverless则是给了前端做BFF开发的 选择。
3.为什么一定是Serverless
其实在Serverless出现之前，前端也尝试了用node应用来做BFF层的开发，飞猪也是在年通过Midway+ReactSSR的架构将飞猪PC主链路首页、搜索、商品详情、订单详情Node化，但是应用级别的开发在前端存在以下几个问题：
开发成本高：Node应用级别的开发对于新手前端还是具备一定的开发成本，之前做过粗略的估计，上手成本至少需要3人/日，还不包括后续的性能优化、内存泄漏排查等一系列能力。运维成本高：Docker、镜像、机器日志查看、域名申请、机器替换等一系列运维能力对于前端来说具备非常高的复杂度，也是注定无法推广的一个重要原因。机器成本高：前端在使用应用开发时过度偏向于前端架构设计带来的应用离散和机器利用率低的问题，根本原因是前端在用页面开发的思维去做应用开发，导致新建一堆应用占用大量闲置机器。
-年也是集团Node开发停滞的两年，这个阶段由于上述问题的闲置，Node开发无法在移动端铺开，前端使用Node主要在中后台的开发，这时矛盾主要表现在前端迫切渴望研发模式转变和涉足服务端开发的高昂成本，直到Serverless浪潮的出现让我们看到了曙光，下面来看下Serverless能给前端带来什么样的变化：
NodeFaaS通过将中间件集成到Runtime的上下文中，开发通过Api的方式调用来实现极低上手和开发成本，只要会写js就能在0.5人/日内上手FaaS开发，同时Serverless容器底层通过机器统一管理、镜像统一、灵活调度、按需付费等方式向开发者屏蔽容器的运维，两者结合完美地帮我们解决了之前Node应用开发遇到的三大问题，至此前后端研发模式升级的 一块拼图集齐，前端开始云+端的变革。
飞猪云+端的核心落地场景
1.落地场景总览
从飞猪首页到搜索、频道，再到大促会场，ServerlessFaaS实现了在飞猪导购全链路的覆盖，成为飞猪前端的常用生产力工具之一。另外中后台开发已全面使用FaaS开发，并且赋能客户端同学，下图右侧的包体积平台就是飞猪客户端同学使用NodeFaaS开发完成。
2.云+端场景-数据协议处理
数据协议处理是BFF层最为常见的场景，包括接口合并、Do到Vo的转换等，飞猪80%以上的C端FaaS场景都是用作数据协议的处理，通过FaaS来做协议转换能够解放服务端，同时增强前端对视图层的控制，可谓一举两得。
一个 的例子（如下图所示），这是一个飞猪的内容详情页，页面涉及内容中台、评价中台、互动、算法等5个以上接口，这些接口都是现成的分散在各个系统，对于前端来说肯定是不想在端上调5次接口，不管是从性能还是架构设计上考虑，都是不合理的，这时就需要一个服务端接口的合并，FaaS就非常适合做这样的事情，通过原子能力的拼装，无需服务端介入，极大缩短了需求的交付周期。
3.云+端场景-SSR同构渲染
SSR同构渲染并不是一个新的概念，最早在React支持SSR的时候，前端就具备一套代码在Server和Client端执行的能力，飞猪这边早在年就在pc端上线了Midway+ReactSSR的页面。移动端由于流量比PC大很多，且在Server侧执行Js是一个极耗机器资源的操作，通过Node应用的方式做SSR机器和运维成本跟随着页面流量指数级上升，ROI并不高，但是ServerlessFaaS的自动托管，能帮前端解决机器利用率和运维成本的问题。再配合客户端的文档预加载，我们可以做到客户端预加载直出率（ms下）%，端外渲染2s达标率90+%，性能提升80%以上。
4.云+端场景-一体化应用
一体化研发是一种更加符合前端人员习惯的开发模式，常见的分为中后台一体化和Rax+FaaS一体化，将FaaS代码和Assets代码在一个仓库下开发，调试和部署能够极大地提高开发效率，目前飞猪用得最多的就是中后台一体化开发。
Serverless研发配套建设
在基础建设方面定义为两部分：研发态效率的提升和运行时稳定性的保障。
1.研发态效率
开发阶段主要涉及的操作是新建项目、调试和发布，飞猪通过已有的Clam工程体系集成FaaS的脚手架模板，对接defapi打通创建项目、迭代和发布的能力，让前端同学开发FaaS能有和开发页面一样的体验，降低上手和开发成本，同时封装Mtop调用和容灾SDK，封装常用FaaSUtils集合的方式提高代码的复用度。
2.运行时稳定性
通过函数监控Alinode、网关监控Sunfire以及全链路日志的排查能力，做到问题的快速发现和定位。
通过tair容灾和cdn容灾，保障大部分场景在函数或者网关挂掉的情况下，仍能够正常展示页面。
未来
年-年我们完成了Serverless向生产力工具的转变，年-年总体来看是彻底完成飞猪研发模式转变的目标，让FaaS成为前后端都习以为常的一环，规划还没做具体，有以下几个关键的事情要做：
中后台和长尾函数0-1的弹起尝试：这块考虑到一些中后台函数和长尾函数每天可能只有几十个Uv够不到Qps级别，目前预留1核机器的方式仍是有些浪费，考虑在不影响初次请求的情况下尝试0到1的弹起，做到机器的 利用率。飞猪物理网关的替换：目前虽然飞猪Java的网关出于维护状态投入较低，但是一旦流量发生变化，网关的稳定性会成为瓶颈，希望能够有Fc专门的团队接管流量网关，之前飞猪也是完成了一个线上试点，年-年继续推进。研发态和运行时问题的可观测增强：从FC底层容器到函数代码内部再到函数依赖、流量网关，不管是部署出现的问题还是线上的问题，都比较难定位，通常需要拉着FC、研发平台、Runtime的同学一块排查，后续希望能推动可观测性的增强，让业务开发能够快速发现问题。
写在
基于Serverless的云+端结合已经基本成型，这将是前端近些年来 的变革之一，未来FaaS将是前端开发不可或缺的一环，我们需要用它来做研发模式升级，也需要用它帮助前端扩大职能，通过FaaS的能力让前端开发深入到服务层，更好地贴近业务、理解业务、帮助业务。
作者简介：王恒飞（承荫），飞猪旅行前端技术专家，飞猪Serverless引进和实践者，探索和推动云+端的研发模式。
本文为阿里云原创内容，未经允许不得转载。