手机淘宝轻店业务 Serverless 研发模式升级实践

一、前言

随着 Serverless 在业界各云平台落地，阿里内部 Serverless 研发平台、各种研发模式也在业务中逐步落地，如火如荼。在此契机下，淘系团队启动了轻店 Serverless 研发模式升级战役，基于阿里集团底层设施建设、上层技术体系，解决在淘系轻店业务场景下碰到的系列问题，并借此推动现有前后端协作模式转变。

二、背景

轻店业务是淘系新型业务，目前处于探索试错阶段，如何能以较低人力成本配合业务快速试错，是团队当前需要考虑的问题。Serverless 重要的特点之一“only focus your business”。因此，拥抱 Serverless，轻店业务势在必行。本篇主要介绍，Serverless 技术在轻店前端团队如何落地，以及如何推动轻店研发模式升级，提升研发效率。在此基础上，同时探索前端职能转变成为应用开发的可能性。

三、研发模式升级

本文首先调研阿里集团内外 Serverless 现状，结合自身业务特点做技术选型；随后在轻店域内进行业务落地，在落地过程中逐步落实以下能力：以 sidecar&bottle 作为底层支撑，以一体化研发模式结合公共服务层、原子能力层、基础 SDK 来提升研发效率；最后通过轻店标准研发链路来保障业务稳定性；最终形成轻店 FaaS 体系，初步实现研发模式提效升级。

1. 技术现状

阿里集团各 BU 过去一年里在 Serverless 领域做了很多工作，主要集中在基础建设、研发模式、逻辑编排、稳定性建设、以及将 faas 链路打通并落地到 B 侧和 C 侧业务场景，如下图所示。各业务依赖的 Serverless 平台集中在 C 平台 / F 平台（PS：阿里内部 Serverless 平台）。

2. 技术选型

当前阿里集团 Serverless 平台和 midway-faas 团队深度合作，定制了基于阿拉丁 FaaS 方案，依托袋鼠为业务网关，承载请求分发的职责，并且有容灾、兜底等通用能力。袋鼠以天马体系（PS：指以统一模块规范为基础的搭建体系）为基础底座，但是轻店业务底层依赖装修体系。因此，我们需要重新选型实现基于轻店场景的 faas 解决方案。除此之外，轻店业务核心依赖各种中台服务。这些中台服务大部分是以富客户端（PS：指集成了本地能力的二方包）形式提供，如何在 nodeFaaS 体系中使用富客户端，是我们技术方案需要考虑的重点。下面是 C 平台方案（PS：阿里内部的 Serverless 平台） 和 G 平台方案（PS：阿里内部的 Serverless 平台）的链路对比图。

其中， G 平台链路有 bottle 能力提供富客户端方案，整体系统链路层级少，性能更优，因此我们最终技术选型为 G 平台。作为业务方，和各平台一起推动&打通 G 平台方案在前端 FaaS 场景落地。

3. 轻店 FaaS 体系

随着业务落地，能力沉淀，轻店 FaaS 逐成体系。

轻店 FaaS（代号：玳瑁），有基础能力层，包含接口聚合、数据映射、函数兜底、灰度等。原子服务层，沉淀了轻店业务场景的各种中台能力封装，上层提供基础 SDK，将各种能力直接给到业务使用。轻店 FaaS 在业务落地时，和前端模块组成轻店的商业 SaaS 能力，通过解决方案将商业能力组合，服务轻店各种业务场景。

1）SideCar & bottle

轻店业务核心依赖中台和中间件能力。因此，首先要解决的问题是，在 nodeFaaS 技术体系下如何调用富客户端和中间件能力。

轻店与 G 平台、midway FaaS 团队一起推进基于 G 平台开发 node FaaS 能力。G serverless 平台中，一个 pod 上面有两个容器，sidecar 容器主要负责请求发现、分发、协议解析、提供各种服务能力（中间件、中台服务）；function 容器运行 node runtime 并且在上面跑业务 faas 代码。容器之间通过 GRPC 进行通信。最终，业务代码可以通过 bottle-SDK 调用富客户端/中间件能力。如下图所示：

基于上述方案，轻店 FaaS 实现了满足轻店业务场景的能力图谱。中间件层面主要集中在消息队列（metaQ）、运维（switch、diamond）、服务（HSF、mtop、http）、缓存（tair、redis）、数据库（云 RDS）、调度（schedulerx）等。中台能力集中在商品、商户、门店、券、标、店铺、UIC 等。随着业务发展，在逐步丰富中。

2）玳瑁 FaaS 能力

玳瑁在运行态，以 G 平台和 node rutime 为底层平台，通过原子层能力实现业务 Faas 函数，并在公共层统一提供数据聚合、兜底等能力。在研发态，基于统一研发平台和小程序端实现轻店一体化研发链路，包含统一构建发布流程、UI 配置化映射、FaaS 函数自动补全等。如下图所示：

公共层

api 请求过来，首先经过公共层（代号：羚羊）。公共层主要实现了轻店域内的基础通用能力。比如，自定义投放能力、兜底能力、聚合能力、配置能力。其中：

• 自定义投放能力是打通了阿X丁（PS：阿X丁指阿里集团内部通用投放平台），业务可以自定义配置定投规则项，比如按商家、人群、区域、业务维度定投数据；
• 兜底能力，针对需要保障高可用的 C 端接口，即使接口挂了也可以通过备份数据进行兜底，让消费者对服务异常无感知；
• 聚合能力是将轻店页面装修数据和模块内部数据统一下发，提高页面性能，防止页面抖动。并且基于统一下发服务的基础上，实现页面级别、接口级别的兜底，模块插件灰度能力。

原子能力层

原子能力层，是沉淀轻店业务场景的各种中台能力封装（门店模型、商品模型、券模型……）。基于这些原子能力，轻店 FaaS 统一收敛外部依赖，业务可以减少外部对接成本，实现业务功能，同时也为映射补全能力提供基础。

FaaS-SDK

为了提升效率，轻店抽象出 FaaS-SDK，包含各平台适配、缓存能力、日志规范、锁能力、数据库封装、通用工具等等。其中：

• 平台场景的适配包含阿里集团内各 Severless 平台，让开发者对平台无感知，只需要关注业务逻辑本身；
• 轻店体系下提供多级缓存能力，对 RT 要求高的高可用场景，提供技术支撑；
• 通用日志规范，对 FaaS 场景的 INFO、ERROR 日志进行格式规范，并封装成独立包供业务使用。

一体化研发模式

在公共层能力层、原子层能力、SDK 、以及 sidecar & bottle 的基础上，我们打通小程序模块和 FaaS 研发链路，实现轻店一体化研发模式。

一体化研发模式是指，基于端开发小程序模块，同时在同一个项目中实现 FaaS 能力。在前端代码中直接引用 FaaS 代码作为函数调用，无需通过请求调用；并且在整个研发链路中，实现两端同步创建&发布。在轻店场景下，这种研发模式节省了前后端沟通联调成本，大大提升研发效率。

稳定性

最后，为了保障业务的可靠性和稳定性，轻店定义了轻店 FaaS 的标准研发链路。从研发生命周期（研发态、待上线、上线中、上线后）各个阶段配置不同的措施来保障业务稳定性。如下图所示：

至此，轻店 FaaS 体系已介绍完，以 sidecar 支撑底层能力，一体化研发模式结合公共服务层、原子能力层、基础 SDK 来提升研发效率，最后通过标准研发链路来保障稳定性。

通过轻店 FaaS 体系支撑轻店业务，前端从前到后 cover 完整业务，后端同学更聚焦在业务中台能力建设。前端职能逐步转变，从前端到全栈，从资源到业务合伙人。对整体业务而言，以更少的协同沟通成本，更少的联调成本，让团队整体效率提升。自此，轻店团队初步实现研发模式升级。

4. 业务落地现状

当前淘系轻店 FaaS，已在多个轻店域内业务落地。

四、未来

未来，淘系团队将继续在轻店 faas 体系的基础上，探索一体化研发模式的最佳提效实践。