飞猪基于 Serverless 的云+端实践与思考

简介:过去两年,飞猪前端一直在积极地进行 Serverless 建设和实践,2019 年 - 2020 年咱们和集团 Node 架构组、研发平台一块儿完成了基础能力的建设和业务试点,成为集团率先落地 Serverless 实践的 BU,2020 年 - 2021 年咱们开始大规模地在飞猪推广使用 Serverless 的能力,从导购全链路到核心中后台,都可以看到 Serverless 的身影,这一年咱们完成了 Serverless 从业务试点到生产力工具的转变,本文将主要分享飞猪基于 Serverless 的实践成果以及将来想要作的事情。

头图.png

做者 | 王恒飞(承荫)
来源 | 阿里巴巴云原生公众号前端

本文整理自飞猪旅行前端技术专家--王恒飞(承荫)在【阿里云 Serverless Developer Meetup 上海站】上的分享。点击查看直播回放:https://developer.aliyun.com/live/246653

过去两年,飞猪前端一直在积极地进行 Serverless 建设和实践,2019 年 - 2020 年咱们和集团 Node 架构组、研发平台一块儿完成了基础能力的建设和业务试点,成为集团率先落地 Serverless 实践的 BU,2020 年 - 2021 年咱们开始大规模地在飞猪推广使用 Serverless 的能力,从导购全链路到核心中后台,都可以看到 Serverless 的身影,这一年咱们完成了 Serverless 从业务试点到生产力工具的转变,本文将主要分享飞猪基于 Serverless 的实践成果以及将来想要作的事情。
node

Serverless 的使用规模


2020 年 - 2021 年飞猪 Serverless 的规模和重要度都有很大的变化,主要表如今三方面:
算法

  • 一是函数组规模增加一倍以上,Qps 峰值增加 650%。
  • 二是使用 FaaS 开发的人员规模增加 560%,其中前端人员 80% 以上参与到 FaaS 的开发中。
  • 三是影响力的表现,目前不只飞猪前端都对 Serverless 很熟悉,客户端也有不少人参与到 FaaS 的开发,更重要的是后端和产品同窗也知道咱们有 Serverless 进行服务开发的能力。

具体的数据以下:

1.png后端

为何要引入 Serverless


飞猪为何这么迫切地要引入 Serverless?这主要是出于先后端研发模式升级以及前端职能扩展的考虑,下面回顾一下飞猪前端架构的发展和研发模式的演进。
api

1. 飞猪前端架构的发展


飞猪前端架构总结下来就是从最初纯粹的前端开发,到解决多端一致性的跨端开发,再到接管视图服务端逻辑的前台开发,Serverless 就是前端升级转变的核心一环。数组

2.png

2. 研发模式的演进历程


前端人员为何必定要参与服务侧开发?从先后端研发模式的演进来看,主要经历了如下三个大的阶段:

第一阶段是资源解耦,这个阶段前端把静态资源分离出来部署到 cdn,解决了和后端服务同机部署的耦合。

第二阶段是模板解耦,咱们以前提到的先后端解耦大部分指的就是模板的解耦,一种不完全的解法就是渲染解耦,服务端放一个空模板内容部分全靠 CSR,完全的解法就是前端接管模板,能够独立部署模板也可使用 node.js 替代。

第三个阶段就是试图解耦,一方面是因为客户端体系和前端的离线体系的限制,端侧对于视图的动态性要求极高,没有服务侧能力的前端只能将视图的动态性放在服务端作,另外一方面因为端侧架构对于数据接口协议的特殊要求,须要服务端来进行协议的转换,也就是服务端常说的 Do 到 Vo 的处理,这就形成了先后端视图的耦合,为了去除这部分耦合,前端经过 Node.js 作 BFF 层来接管视图层的逻辑,Serverless 则是给了前端作 BFF 开发的最佳选择。

3.png性能优化

3. 为何必定是 Serverless


其实在 Serverless 出现以前,前端也尝试了用 node 应用来作 BFF 层的开发,飞猪也是在 2017 年经过 Midway + React SSR 的架构将飞猪 PC 主链路首页、搜索、商品详情、订单详情 Node 化,可是应用级别的开发在前端存在如下几个问题:
架构

  • 开发成本高:Node 应用级别的开发对于新手前端仍是具有必定的开发成本,以前作过粗略的估计,上手成本至少须要 3 人/日,还不包括后续的性能优化、内存泄漏排查等一系列能力。
  • 运维成本高:Docker、镜像、机器日志查看、域名申请、机器替换等一系列运维能力对于前端来讲具有很是高的复杂度,也是注定没法推广的一个重要缘由。
  • 机器成本高:前端在使用应用开发时过分偏向于前端架构设计带来的应用离散和机器利用率低的问题,根本缘由是前端在用页面开发的思惟去作应用开发,致使新建一堆应用占用大量闲置机器。

2017 - 2019 年也是集团 Node 开发停滞的两年,这个阶段因为上述问题的闲置,Node 开发没法在移动端铺开,前端使用 Node 主要在中后台的开发,这时矛盾主要表如今前端迫切渴望研发模式转变和涉足服务端开发的高昂成本,直到 Serverless 浪潮的出现让咱们看到了曙光,下面来看下 Serverless 能给前端带来什么样的变化:

4.pngless

Node FaaS 经过将中间件集成到 Runtime 的上下文中,开发经过 Api 的方式调用来实现极低上手和开发成本,只要会写 js 就能在 0.5 人/日内上手 FaaS 开发,同时 Serverless 容器底层经过机器统一管理、镜像统1、灵活调度、按需付费等方式向开发者屏蔽容器的运维,二者结合完美地帮咱们解决了以前 Node 应用开发遇到的三大问题,至此先后端研发模式升级的最后一块拼图集齐,前端开始云+端的变革。运维

飞猪云+端的核心落地场景

1. 落地场景总览


从飞猪首页到搜索、频道,再到大促会场,Serverless FaaS 实现了在飞猪导购全链路的覆盖,成为飞猪前端的经常使用生产力工具之一。另外中后台开发已全面使用 FaaS 开发,而且赋能客户端同窗,下图右侧的包体积平台就是飞猪客户端同窗使用 Node FaaS 开发完成。

5.png

2. 云+端场景 - 数据协议处理


数据协议处理是 BFF 层最为常见的场景,包括接口合并、Do 到 Vo 的转换等,飞猪 80% 以上的 C 端 FaaS 场景都是用做数据协议的处理,经过 FaaS 来作协议转换可以解放服务端,同时加强前端对视图层的控制,可谓一箭双雕。

6.png

一个最新的例子(以下图所示),这是一个飞猪的内容详情页,页面涉及内容中台、评价中台、互动、算法等 5 个以上接口,这些接口都是现成的分散在各个系统,对于前端来讲确定是不想在端上调 5 次接口,不论是从性能仍是架构设计上考虑,都是不合理的,这时就须要一个服务端接口的合并,FaaS 就很是适合作这样的事情,经过原子能力的拼装,无需服务端介入,极大缩短了需求的交付周期。

7.png

3. 云+端场景 - SSR 同构渲染


SSR 同构渲染并非一个新的概念,最先在 React 支持 SSR 的时候,前端就具有一套代码在 Server 和 Client 端执行的能力,飞猪这边早在 2017 年就在 pc 端上线了 Midway + React SSR 的页面。

移动端因为流量比 PC 大不少,且在 Server 侧执行 Js 是一个极耗机器资源的操做,经过 Node 应用的方式作 SSR 机器和运维成本跟随着页面流量指数级上升,ROI 并不高,可是 Serverless FaaS 的自动托管,能帮前端解决机器利用率和运维成本的问题。

再配合客户端的文档预加载,咱们能够作到客户端预加载直出率(500ms下)100%,端外渲染 2s 达标率 90+%,性能提高 80% 以上。

8.png

4. 云+端场景 - 一体化应用


一体化研发是一种更加符合前端人员习惯的开发模式,常见的分为中后台一体化和 Rax+FaaS 一体化,将 FaaS 代码和 Assets 代码在一个仓库下开发,调试和部署可以极大地提升开发效率,目前飞猪用得最多的就是中后台一体化开发。

9.png

Serverless 研发配套建设


在基础建设方面定义为两部分:研发态效率的提高运行时稳定性的保障

1. 研发态效率


开发阶段主要涉及的操做是新建项目、调试和发布,飞猪经过已有的 Clam 工程体系集成 FaaS 的脚手架模板,对接 def api 打通建立项目、迭代和发布的能力,让前端同窗开发 FaaS 能有和开发页面同样的体验,下降上手和开发成本,同时封装 Mtop 调用和容灾 SDK,封装经常使用 FaaS Utils 集合的方式提升代码的复用度。

2. 运行时稳定性


经过函数监控 Alinode、网关监控 Sunfire 以及全链路日志的排查能力,作到问题的快速发现和定位。

10.png

经过 tair 容灾和 cdn 容灾,保障大部分场景在函数或者网关挂掉的状况下,仍可以正常展现页面。

将来


2020 年 - 2021 年咱们完成了 Serverless 向生产力工具的转变,2021 年 - 2022 年整体来看是完全完成飞猪研发模式转变的目标,让 FaaS 成为先后端都习觉得常的一环,规划还没作具体,有如下几个关键的事情要作:

  • 中后台和长尾函数 0 - 1 的弹起尝试:这块考虑到一些中后台函数和长尾函数天天可能只有几十个 Uv 够不到 Qps 级别,目前预留 1 核机器的方式还是有些浪费,考虑在不影响初次请求的状况下尝试 0 到 1 的弹起,作到机器的极致利用率。
  • 飞猪物理网关的替换:目前虽然飞猪 Java 的网关出于维护状态投入较低,可是一旦流量发生变化,网关的稳定性会成为瓶颈,但愿可以有 Fc 专门的团队接管流量网关,以前飞猪也是完成了一个线上试点,2021 年 - 2022 年继续推动。
  • 研发态和运行时问题的可观测加强:从 FC 底层容器到函数代码内部再到函数依赖、流量网关,不论是部署出现的问题仍是线上的问题,都比较难定位,一般须要拉着 FC、研发平台、Runtime 的同窗一块排查,后续但愿能推进可观测性的加强,让业务开发可以快速发现问题。

写在最后


基于 Serverless 的云+端结合已经基本成型,这将是前端近些年来最大的变革之一,将来 FaaS 将是前端开发不可或缺的一环,咱们须要用它来作研发模式升级,也须要用它帮助前端扩大职能,经过 FaaS 的能力让前端开发深刻到服务层,更好地贴近业务、理解业务、帮助业务。

做者简介


王恒飞(承荫),飞猪旅行前端技术专家,飞猪 Serverless 引进和实践者,探索和推进云+端的研发模式。

2021 阿里云开发者大会重磅开启!

数字时代,如何更好地利用云的能力?什么是新型、便捷的开发模式?如何让开发者更高效地构建应用?科技赋能社会,技术推进变革,拓展开发者的能量边界,一切,因云而不一样。点击当即报名活动2021 阿里云开发者大会将给你答案。

本文内容由阿里云实名注册用户自发贡献,版权归原做者全部,阿里云开发者社区不拥有其著做权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将马上删除涉嫌侵权内容。