阿里巴巴Serverless云研发平台工作与技术实践分享

时间：2026-08-21 16:05

技术成熟度往往来自大规模业务实践。在 Java 领域，阿里巴巴持续将自身实践经验反哺到微服务技术体系；在 Node js 领域，阿里则掀起了前所未有的前端研发变革浪潮，将实践能力沉淀并反哺给 Serverless 技术体系，同时逐步扩展到更多多语言技术栈和后端 BaaS 场景。Serverless

技术成熟度往往来自大规模业务实践。在 Java 领域，阿里巴巴持续将自身实践经验反哺到微服务技术体系；在 Node.js 领域，阿里则掀起了前所未有的前端研发变革浪潮，将实践能力沉淀并反哺给 Serverless 技术体系，同时逐步扩展到更多多语言技术栈和后端 BaaS 场景。

Serverless 云研发平台，是由阿里巴巴集团前端委员会发起打造的一体化云研发平台。平台底层依托函数计算 FC，可视为整个 Node Serverless 体系的重要研发入口，承担着淘宝、飞猪、ICBU、考拉、高德、文娱等多条业务线的研发、交付与运维工作。目前，集团内部已有上千名前端与客户端工程师通过 Serverless 云研发平台开展业务开发，覆盖营销导购、中后台、行业前台等多个规模化应用场景。

从今年双11整体大盘数据来看，仅淘系 Node Serverless 的支撑流量，就已经从去年的 2K QPS 峰值提升到今年的 30K QPS 峰值，峰值流量增长接近 15 倍；集团整体更是从近 5.8K QPS 提升至今年的 50K QPS 峰值。

在解决方案层面，我们定制了面向更多业务场景的能力，包括考拉 Dart 解决方案的落地，以及面向导购业务的模型驱动解决方案；在运维层面，我们优化了大促态与日常态流程，让开发者在应对更高 QPS 规模时，精力投入至少降低 50%；在研发体验侧，我们构建了解决方案体系，降低研发门槛，支持前端快速入场，整体研发效率提升 39%；在底层 Serverless 基座方面，我们适配了多个 Serverless 平台，支持多平台实时切换，以应对单一平台带来的不确定性。

本文将重点介绍，Serverless 云研发平台是如何通过多项能力建设，保障各租户业务实现快速开发与安全交付的。

研发的本质

很多团队可能一直在「人员协同」和「服务可靠性」上投入高额人力成本，但研发的本质，始终是高质量交付「业务功能」。

今天，我们正从传统的「前端开发者」逐步走向「应用研发者」。这个过程并不轻松，除了需要思考「什么是真正的按需付费」「什么是弹性能力」等底层运维命题之外，还必须关注「研发效能」相关问题。这也是为什么更高效的协同模式、组织关系变化，甚至前后端协同的生产关系都在持续演进。如今我们谈「云端一体」，本质上是站在用户视角思考问题，用更高效的方式解决实际业务需求。

在当下，软件开发对成本控制的要求越来越高，单位时间内的产能将逐渐成为衡量团队是否高效的重要标准。

因此，回到研发本质，Serverless 云研发平台要解决的核心命题主要有：

让业务开发更轻，聚焦核心业务逻辑；
让业务开发更快，全面提升产研效率；
让基础设施更厚，持续增强系统稳定性。

图为 Serverless 云研发平台架构图

通过打造 Serverless 解决方案定制能力，平台不断完善云端一体的研发者生态，给开发者提供更多选择；同时构建云端一体的研发集成闭环，加快业务交付速度，并以低成本方式提供基础 BaaS 服务能力，使业务 BaaS 成为研发平台的重要抓手。

Serverless 研发平台

1. Serverless业务解决方案

我们定义的“解决方案”，是指面向某一横向或纵向领域，贯穿创建、研发、交付、运维全流程的一系列能力集合。那么，为什么当时需要定义这种解决方案的定制能力？核心原因在于，面对今天云端一体化研发场景，不同事业部的业务团队存在差异化、个性化的定制需求。

我们调研了多个事业部，包括 AE、考拉、淘系等。最初的 Serverless 云研发平台在定制开发能力方面相对薄弱，难以充分承接业务诉求，因此平台需要具备一定的开放定制能力。比如，淘系需要面向研发面板的 low code 定制能力，考拉则有面向函数的资损风险等级录入、应用风险等级录入等需求。

但开放能力会涉及创建、研发、交付、运维等多个阶段，每个环节能开放哪些定制能力、开放到什么程度，都需要平台结合收集到的需求与自身管控要求进行综合权衡。正所谓「人挪活，树挪死」，在结构化梳理出几个关键能力之后，Serverless 云研发平台面向多个租户开放解决方案定制能力的方向，也就逐步形成了。

上图为结构化几个可定制节点以及多个场景的调研情况

基于上图中的结构化信息，我们进一步定义了解决方案的元数据模型，下面展示的是中后台一体化解决方案的相关元数据信息示例。

{
  "name": "ICE-FaaS",
  "display_name": "Web 端一体化",
  "description": "传统 Web 一体化解决方案，解决中后台开发需求（ICE、React等），同时支撑中后台前端页面和 FaaS 的研发",
  "owner": "*",
  "generator": {
    "id": 30
  },
  "depserver": [],
  "page": {},
  "widget": {},
  "baas": {},
  "ide_plugin": ["midway-helper"],
  "checkConfig": {
    "cf": true,
    "cr": true,
    "fone": true
  },
  "flow": {
    "id": 1
  },
  "ops": {
    "resource": [{
      "type": "faas"
    }, {
      "type": "assets"
    }]
  }
}

截至目前，Serverless 云研发平台通过共建方式累计沉淀了 14 个解决方案，其中包括 5 个通用解决方案，以及 9 个面向不同租户的定制化解决方案。

接下来重点介绍 3 个典型的 Serverless 解决方案。

1）一体化解决方案

一体化应用解决方案，是基于 Midway Hooks 打造的上层业务云端一体化解决方案。借助 Serverless + Hooks + “零” API 调用等特性，开发者在研发流程中只需要专注业务逻辑，就可以高效完成应用开发与交付。

一体化应用在实际使用中具备多项优势：

易于开发，前后端同仓库管理，无缝融合一体化开发；
易于部署，前后端可统一发布与部署；
易于维护，后端代码通过 Serverless 部署，运维复杂度更低。

在开发过程中，我们也提供了丰富的能力，帮助开发者进一步加速研发效率。

“零 API 调用”

Hooks 支持

在阿里内部，我们已经提供了中后台一体化和搭建模块一体化两种解决方案。其中，中后台一体化应用已在内部落地 300+ 应用，能够快速、高效地支撑各个 BU 的中后台研发需求。

2）淘系模型驱动解决方案

模型驱动，是淘宝导购业务开发过程中沉淀出的一种研发模式，主要面向导购场景中大量的召回、补全、展现需求。通过配置化面板，将模型、数据来源、插件配置进行组合，最终自动生成业务逻辑代码，供业务侧直接消费。

整个操作面板的核心关注点，在于右侧的流程画布。我们希望通过固定流程解决这一类业务问题，让业务逻辑遵循预定义的操作路径。在云市场轻应用外包介入开发的模式下，由内部同学生成物料，外包同学负责开发模块、选择业务字段并串联流程，帮助内部同学显著节省流程串联和模块联调成本。相比传统开发方式，整体提效约 10%。这也是一种较为创新的协同研发模式，未来随着物料逐步丰富，整体提效空间还会更大。

数据源（召回） --> 模型（补全） --> 扩展逻辑（插件）

模型驱动解决方案在淘宝场景中较好地解决了业务问题，但面对更多复杂业务时，还需要更灵活的模板定制能力。因此未来模型驱动会重点发力于灵活模板配置化、节点物料沉淀机制完善、支持 Web IDE 等插件能力，并在更多业务场景中推动落地，让不同业务都能更高效地建立自己的“三板斧”。

3）考拉 Dart 一体化解决方案

考拉大前端自 2020 年 3 月开始尝试 Flutter 应用开发，部分客户端与前端同学都参与到了 Flutter 研发中，因此对 Dart 技术栈相对熟悉。Dart 一体化解决方案最初的目标，主要是帮助客户端同学提升开发效率。考拉此前主要使用 Node.js Runtime 的 Serverless 方案，相比 JavaScript，Dart 对客户端研发同学更加友好，同时也持续有客户端同学提出 Dart Serverless 的明确诉求。

在函数计算 FC 研发团队的支持下，考拉基于 Dart Runtime 的前期测试版本，快速完成了考拉 App 今日活动 Tab 的改造与重构，并已于 9 月底完成灰度上线。到了 10 月中下旬，又基于 Dart Runtime 开始与 DEF 平台进行对接，最终在 DEF Serverless 创建面板中透出 Dart 纯函数解决方案。目前与 FC 侧的基础流程已经基本打通，Dart 纯函数解决方案也即将正式上线。

除了已经上线的 Dart Ast 生成服务外，考拉后续还将基于 Dart Serverless 方案推出更多业务场景，例如 App 端数据模型动态下发、业务逻辑动态配置、Flutter 动态化尝试，以及 App 跨端搭建能力等。

除了以上 3 个典型解决方案外，ICBU 团队研发的 EaaS 微应用级解决方案、天猫行业团队研发的面向轻店场景的原生小程序一体化解决方案等，也都已形成各自特色，这里就不一一展开介绍了。

2. 函数稳定性保障

最开始时，我们关注的重点是如何使用 Node 完成业务逻辑，比如数据如何组织、Java 二方包如何调用、如何接入阿拉丁链路、线上 bug 如何快速修复。如今随着越来越多业务在线上稳定运行，我们关注的重点已经从“如何完成业务需求”，转向“如何高效、稳定地完成业务需求”。

线上稳定性，本质上是对问题的系统化治理。从问题治理视角出发，主要可以拆分为以下几个关键环节：预防问题、发现问题、定位问题和解决问题。

在预防问题方面，要尽可能降低问题发生概率，并缩小影响范围，做好上线卡口控制以及对应预案准备。
在发现问题方面，要尽可能实现全链路监控，并建立合理有效的报警分发机制。
在定位问题方面，要尽可能缩短故障定位时间，在报警元信息基础上结合机器辅助分析与上下文关联，实现半自动定位，或提供更有逻辑的上下文信息，从而降低人工排查成本。在解决问题方面，则要确保解决方案有效、安全且快速落地。

3. 大促稳定性保障手段

在大促场景下，C 端业务需要重点保障。以下稳定性保障手段已经历多次大促压测验证，而且越是在大促状态下，整套稳定性保障体系的重要性就越发突出。

虽然稳定性能力得到了保障，但在过去，我们仍然需要对照上述文档手动完成上线流程，流程非常冗长，最后只能沉淀成一份作战手册，而且这些内容无法与应用直接关联，分散在各类文档角落，整个操作过程既低效又繁琐。

上线流程 -> 作战手册一体化

因此，Serverless 研发平台希望对整个上线流程进行规范化管理，从强弱依赖梳理 -> 预案配置 -> 监控报警订阅 -> 单链路压测 -> 作战手册生成，完整记录所有函数上线过程，实现流程可追溯、文档可沉淀；同时，让预案、压测、监控等流程尽可能半自动化，减少整体上线时间。我们将每个流程节点定义为一个 SOP 单元，这样就可以根据不同业务特性，灵活组装对应的 SOP 流程。

发布 SOP 流程

作战手册通过半自动化流程生成，采用函数与作战手册关联的硬盘化记录方式，再结合自动限流、下游依赖分析以及预案生成能力，可以让业务在大促状态下更加从容。例如，通过预发流量录制回放，平台可自动分析函数下游的强弱依赖，并录入强依赖负责人信息，这样当线上出现问题时，就能第一时间找到相关负责人协同排查；同时，平台还能根据不同租户对单元化部署的需求，帮助用户实现多机房、多单元部署能力，支撑异地多活。

淘系业务作战手册

4. 专家应急响应

为了解决线上问题定位慢这一痛点，平台还提供了应急响应系统。当函数成功率下降并触发报警时，平台会自动拉取函数及其下游多项数据信息，进行错误分析，快速生成错误报告并推送给函数开发者，同时引导开发者回到研发平台执行切流、预案等止血操作。例如，当下游强依赖服务 A 成功率下降，导致函数自身成功率降低时，开发者就能快速获知需要联系服务 A 的负责人进行排查。