Serverless一体化探索与落地

作者介绍：

李智勇

2019年4月加入去哪儿旅行，在带领团队负责低代码平台的建设与落地工作中，成功赋能了企业中后台系统研发提效，成功接入中后台系统60+其中包含多个代码量级在50W行以上的系统，页面600+。目前技术上聚焦于组件化低代码平台建设，Serverless平台建设，跨端渲染、架构设计、服务可用性提升及运维，具备大型服务的落地实践经验。

一、前言

本文从团队所面临的背景出发，引出方案思考和选择，并阐述 Serverless 一体化落地过程中的全链路问题解决思路。本项目落地平台命名为塞拉斯（来源于 lol 人物名，在游戏中别人的大招他都能用，预示着我们的平台是集大成者，汇集大量优秀思想方案来落地实现我们的平台）

• 核心名词介绍：

Serverless：含义是无服务，核心思想是让开发者专注于自己的业务逻辑开发，不必关心服务器端的专业知识，减少服务端知识掌握、运维知识掌握等心智负担。

BFF：含义是专为前端服务的服务层，核心思想是开发合理化分层，后端专注于服务稳定性及基础数据提供，前端专注于页面交互开发对用户体验负责，对于基础数据未提供但前端需要逻辑运算得到的部分或者前端需要多服务接口组装才能满足页面展示需要的部分放在 BFF 层。

FAAS：含义是函数即服务。在平台中函数为一等功名，开发者编写函数，即可对外提供接口服务。

• 塞拉斯核心思想：

以 Serverless 思想，搭建 BFF 层，建设一个 FAAS 服务平台，前端人员在平台上写云函数即可完成业务开发，不需要关心服务器端知识、不需要搭建工程，可以云端复用，可以进行自动化的线上 case 验证。

二、背景介绍

大前端中心拥有大量的前端工程，带有 appcode 的 node 端工程 200+ ，qzz + rn + 小程序工程 300+ ，当前的现状是疫情影响、人力紧张、需求堆积较多、前端人力维护现有工程已经捉襟见肘。如何在当前人力紧张的情况下，服务好用户、做好用户体验的前提下高效的维护好这些工程，那么提效就是我们的主要抓手，除了之前已经做过的低代码平台以外，我们如何继续提效，如何找到低成本的方案进行大幅提效成为我们迫在眉睫的核心诉求。

我们首先分析了当前会影响到前端效率的一些问题点，梳理下来主要有以下一些问题。

• UI 逻辑处理争议（比如代金券的状态有待领取、已领取、已作废、已过期等状态，状态是后端计算得到的，不同状态展示不同，站在后端角度不需要关心前端 UI 、站在前端角度不同状态展示不同希望有人给算好展示相关的数据和样式，前端可直接渲染，由于低代码的组件是跨业务复用的，不同业务的后端立场不同，接口返回也会有差异，前端后端关于 UI 逻辑处理存在争议）
• 多接口数据整合争议（有些业务场景下前端一个组件的数据是由后端多个团队提的接口，接口整合工作的划分也存在争议）
• 相同代码在不同前端工程存在多份（由于有些情况下前端无法说服后端去做相关数据处理逻辑，那么大量数据处理逻辑就放在了前端，前端可能不同端、不同 team 都会用到某接口数据都需要进行数据处理，这种场景下相同前端的数据处理逻辑代码就散落在不同的工程代码库中）
• 前端同质化 node 服务多（有些情况下，前端团队会搞一个服务于前端UI展示的服务层来方便前端开发，前端会自建 node 服务，各个 node 服务其实处理的事情大致是相同的，但是每个场景下都单独建立了各自的服务）

以上的问题在不同项目中不断重复的影响着前端的开发效率，所以我们的目标就聚焦到了：梳理一个可以解决以上问题的合适方案。

三、方案选型

以下是我们对于整体方案的核心诉求和行业内的解决方案。

我们希望整体方案，可以完全自控、代码安全不托管、保持 DevOps 不变，且数据处理逻辑改动后能够按照线上的 case 数据自动化的回归测试，我们对比的国内阿里云，和国外亚马逊的 AWS Lambda 当前如果在公司内落地，很难取得合理的性价比，所以我们走了自研的方案。

核心点是开发、构建、测试、发布、线上问题排查等公司都有自己的一套完整流程。

首先业界的都做的比较完善，功能齐全，能满足我们的基本诉求

问题排查，目前公司内排查问题整体链路已经非常明确，工具也相对完善，通过用户名、手机号可以看到每一个节点的数据输入、输出，如果使用了外界的产品，这一部分的数据输出就是个黑匣子，会给我们排查问题增加很大的难度。

自动化测试，公司内部的一些用户输入输出我们是可以拿到的并进行真实 case 自动化测试的，但是如果使用外界产品，无法拿到线上真实案例

所以这里核心点我们主要是借鉴业界的思想，进行自研实现

塞拉斯的方案核心思想总结为一句话就是：以 Serverless 思想，搭建 BFF 层，建设一个 FAAS 服务平台，前端人员在平台上写云函数即可完成业务开发，不需要关心服务器端知识、不需要搭建工程，可以云端复用，可以进行自动化的线上 case 验证。

四、方案详解

塞拉斯整个方案的核心可以用以下这张图进行概况，接下来进行详细的展开介绍。

整个方案，以 Serverless 思想，搭建 BFF 层，建设一个 FAAS 服务平台，定位的角色是服务层，边界是处理数据、但不处理 dom 。

易用性：前端人员可零成本的上手使用、在线调试，无需额外的学习成本。

问题排查全链路可回溯：从发起端到后续各个环节可以可视化查看全链路调用，进行精确定位，也可根据关键信息，查询各个节点输入输出，也可以根据线上case还原回溯调试处理逻辑

代码跨工程复用：由于运行先服务端，不受端的限制，云函数可自由复用。

自动化的线上 case 验证：修改云函数代码后可根据线上 case 数据，自动进行回归验证。

高性能&高可用：作为统一的服务，对应搞性能高可用也有较高的要求。

五、架构讲解

（一）系统架构

塞拉斯系统架构如下图：

整个架构两条分支对应了两种场景：

第一种后端站在服务端的角度认为数据很合适，但是前端认为不合适，后端接口数据需要处理下，给前端用的。

第二种需要 BFF 层去组合多接口的场景

（二）BFF架构

BFF架构如下图：

BFF 的界面配置层用公司内的低代码系统搭建平台进行搭建

服务层主要使用容器化部署方式部署，支持自动扩缩容

持久化存储采用 MySQL 关系型数据库进行存储

六、系统介绍

（一）配置系统

配置系统主要可以进行单函数、编排的在线编写维护工作。

系统单函数管理界面如下图

系统编排管理界面入下图

（二）单函数介绍

单函数的使用场景：对于较为简单的数据处理可以使用单函数。

单函数规范如下图

其中语法检查主要利用 babel 进行校验，避免常规错误，比如：返回 promise 的函数前面必须跟 await ，函数必须有返回值，不能有声明但未使用的变量等。

（三）编排介绍

编排的使用场景：组件多、数据节点多层级深、依赖接口多、整体逻辑复杂等场景下，适合使用编排进行逻辑的拆分和组装处理，可以降低单函数的复杂度，增加复用性。

编排结构如下图：

编排的执行过程如下图：

（四）平台能力

平台主要提供了以下 6 种通用能力，供开发者在编写函数时进行调用：

1、函数调用的能力，可通过 getHandle 传入函数标识，进行函数调用。

2、获取 QConfig 配置文件的能力，通过 getQConfig 方法进行配置文件获取。

3、可以进行 redis 操作，通过 redis 对象进行 redis 操作。

4、进行请求，通过 request 进行请求。

5、通过 logger 对象进行，日志打印操作。

6、中断编排执行，可通过 composeBreak 进行编排的中断。

（五）版本方案

我们会有 beta 、仿真、线上 3 种环境，版本方案如何选择，我们的核心期望是：版本一致、开发易用、方案清晰。最终我们的方案如下图：

多人协作时类似 git 版本管理，每个人可独自产生小 beta 版本进行各种开发，最终 merge 后台进行合并上线。

（六）易用性设计

为了提升易用性，塞拉斯平台支持以下几方面的内容：

1、全链路问题定位：线上的一个请求我们可以通过 traceId 串联起各个调用环境和输入输出，可视化的方式进行展示，也可以按照关键信息进行各个环节的日志查询。

2、在线调试：我们可以根据 traceId 进行线上数据调试，也可以自己伪造 mock 数据进行在线调试。

3、搜索定位：代码可搜索定位。

4、引用函数跳转：类似本地编辑器可以按住 ctrl 键点击跳转到引用的函数体中。

5、服务器端能力抹平：我们的编辑器是在web浏览器端运行的，但是打日志、qconfig 文件的读取等能力操作是必须运行在 node 服务端的，为了给开发者屏蔽掉这个区别，方案直接在线编写、在线运行调试看效果，我们进行了服务端能力抹平。

6、可视化流程图：编排中函数关系提供可视化的流程图进行展示。

（七）安全高可用

为了保障整体服务的安全高可用，塞拉斯做了以下功能：

1、代码在线 CR

2、多环境验证

3、线上真实 case 自动化回归测试

4、上线审核

5、支持限流配置

6、服务双环境秒切

7、自动扩缩容

8、全局监控报警

七、落地效果

（一）系统性能

塞拉斯落地系统性能，如下图，单函数、编排执行耗时 P90 优化到了 10ms 以下：

（二）接入场景

目前塞拉斯主要的接入场景

• 营销活动：双旦集卡、五一大促、中秋、十一大促等
• 门票主流程：POI 货架、POI 头部、L页
• 酒店 neeko 标签系统：neeko 标签系统是展示在酒店 D 页酒店卡片上的标签数据

（三）接入效果

1、营销活动接入效果：

十一大促、中秋活动、暑促等营销活动场景均有使用，后端接口依赖多方接口，比如超商、酒店、市场等需要前端聚合数据，塞拉斯为活动能够及时上线提供了有力保证，如果没有塞拉斯，对于页面展示依赖多业务部门数据接口的需求如果逻辑写在前端代码就会增加端上的工作量，另外有些接口有依赖关系在端上的串行操作会影响页面性能、影响用户体验，为了不影响用户体验就需要有专门的一个服务层为前端提供数据，服务层都是内网间访问相对性能损耗要比放在端上好很多，单独新增一个服务层人力成本会增加，而在有了塞拉斯之后，前端可以方便的以编写函数的方式在线组装数据低成本的解决了当下痛点。

（十一大促页面）

2、门票接入效果：

接入页面如下图：

接入后

代码层面：

• 2w行降至6500+行

• 更专注于展示

迭代效率：

• 不需要发QP包（无UI改动，纯逻辑变更情况下）

• 无需经过单独测试

• 1pd -> 十几分钟

3、酒店D页标签处理逻辑，从neeko标签系统迁入BFF效果：

接入页面如下图：

酒店标签处理日均访问量1300万+，当前qps 100左右

P99从400ms 降低到152ms 降低72%

P50从96ms 降低到24ms 降低75%

八、未来展望

未来规划主要有以下的事情可以落地继续推进：

1、缓存预热，减少缓存冷启动带来的性能损耗

2、业务接入&推广

3、按业务进行集群物理隔离，避免某个业务影响全局的问题出现

END