我在阿里巴巴做 Serverless 云研发平台

简介： 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 方案定制能力来完善云端一体研发者市场，提供开发者更多选择、打造云端一体的研发集成闭环来提供业务更快的交付速度、以及业务低成本的使用基础 BaaS 服务能力以及业务 BaaS 成为研发平台的核心抓手。

Serverless 研发平台

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 个典型的解决方案。

一体化解决方案

一体化应用解决方案是基于 Midway Hooks 提供的上层业务云端一体解决方案，借助 Serverless + Hooks + “零” API 调用的特性，开发者在研发流程中仅需关注业务逻辑，即可高效完成应用的交付。

一体化应用在使用时，具有诸多的优势：

易于开发，前后端同仓库，无缝融合一体开发
易于部署，前后端一同发布与部署
易于维护，后端代码使用Serverless 部署，运维难度低

而在开发时，我们也提供了诸多的功能来帮助开发者加速研发。

“零 API 调用”

Hooks 支持

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

淘系模型驱动解决方案

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

整个操作面板的核心关注点在右侧的流程画布上，我们希望使用固定的流程来解决这一类业务问题，这些逻辑遵从预定义的操作路径。在云市场轻应用外包介入开发的模式中，由内部同学生成物料，外包同学开发模块和选择业务字段并串联流程，帮助内部同学节省了大量流程串联和模块联调成本，相比传统的开发方式整体提效10%左右。这也是一种创新的协同模式，物料丰富后会有更大的提升空间。

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

模型驱动解决方案在淘宝很好的解决了业务问题，但是面临更多的场景需要的是更加灵活的模板定制能力，因此未来模型驱动会在灵活的模板配置化上发力、对节点物料的沉淀上建立更加完善的机制、支持Web IDE等插件，并在更多的场景上支持业务的落地，让不同的业务场景可以更加便利的建立自己的“三板斧”。

考拉 Dart 一体化解决方案

考拉大前端自 2020 年 3 月份开始尝试 Flutter 的应用，部分客户端和前端同学均参与进 Flutter 的开发，对于 Dart 相对熟悉，所以 Dart 一体化解决方案最初目的主要是考虑帮客户端同学解决开发提效的问题。考拉之前主要在使 Node.js Runtime 的 Serverless 方案，相比于 Java Script，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 微应用级别的解决方案，天猫行业团队研发的面向轻店场景的原生小程序一体化 解决方案等，这里不展开一一介绍了。

函数稳定性保障

最开始的时候，我们关注的重点是如何用 Node 完成业务逻辑，比如数据怎么组织、 Java 二方包怎么调用、怎么结合阿拉丁链路、线上 bug 怎么快速修复。现在有了这么多线上运行的业务，我们关注的重点已经从怎么完成业务需求，转变成如何高效地、稳定地完成业务需求。

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

在预防问题上，要尽可能降低问题发生的概率和缩小影响面，做好上线卡口，以及做好对应的预案。发现问题上要尽可能实现全链路监控，以及实现合理有效的报警分发机制。定位问题上，要尽可能缩短问题的定位时间，在报警元信息的基础上，做一些机器的辅助分析，关联上下文，从而做到半自动定位或提供更多有逻辑的上下文，来缩短人为定位问题的时间。在解决问题上，要保证解决方案的有效，安全以及快速。

大促稳定性保障手段

大促场景下， C 端场景需要重保，以下的稳定性保障手段经历数次大促压测，同时越是大促态，整个稳定性保障也愈发紧张。

稳定性是保障了，但是在之前我们是对照上述的文档完成上线流程的，流程冗长无比，最终并沉淀成一个作战手册，同时这些内容无法和应用关联，离散在文档角落，整个过程「又臭又长」。

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

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

通过半自动化流程生产的作战手册，函数和作战手册关联的硬盘化记录方式，并结合自动限流和下游依赖分析以及预案生产，例如：通过预发流量录制的回放，自动分析出函数下游的强弱依赖，并录入强依赖负责人，方便出现线上问题的时候可以第一时间找到负责人排查问题；根据不同租户对单元化的需求，平台可以帮助用户进行多机房、多单元部署实现异地多活。这些都能够让业务的大促态变得更轻松一些。

专家应急响应

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

租户运维

平台上的每个租户都有对应的租户管理员，对各自租户的函数稳定性负责，包括租户下函数的单元化部署规则、大促管控、自建网关配置、容器额度、租户私有解决方案等，为此平台提供了一系列运维工具。

租户大盘

帮助管理员更好的观测到租户下函数的服务质量，和容器额度使用状况，提供函数错误率和 RT 黑榜，并且每周都会有治理周报推送给管理员，帮助其更好的进行运维其租户下的函数。

函数盘点

帮助管理员细致的观测每个函数线上运行的具体状态，包括函数线上存在的版本、容器数量、 Runtime 版本、灰度、单元部署状况，甚至可以观测到函数部署是否均衡。

大促管控

平台还提供针对大促态的运维管控能力，管理员可以将租户下参与大促的函数服务一键切换到大促态，进行大促态的额外配置，比如大促容量配置，Broker 侧限流，网关侧统一监控预案等能力，保障大促的稳定。

一些思考

Serverless 云研发平台后续将在提升用户正向和逆向流程的效率上继续演进，L1 是希望让用户低成本的上手，L2 是希望让用户低成本的进行研发，让前端往应用研发更进一步。

以下是基于用户正向研发链路耗时统计的一些分析：

技术方案产出的时间较久，占比整体研发周期 5%，核心原因是服务物料难以检索以及服务可用性难以评估，领域模型沉淀不足；

FaaS 整体研发占比 25%~30% ；模型驱动等可视化编排在物料准备完备的情况下，能够提效，但是不具备规模化场景；
联调耗时较久占整体成本 20% 左右，过度依赖预发环境，据统计，完成一个项目需要部署 50 次；
压测成本依然存在，平台熟悉成本过高。

当然还有监控运维逆向链路的一些分析：

报警分发不准确，因现在无法区分报警是底层框架和上层业务的问题，所以往往需要架构组和业务同学的共同介入；

定位问题效率低，如失败率报警，可能是底层架构的问题也有可能是下游的问题，还有可能是机房或者自身的问题，往往需要去多个平台逐一排查；
缺乏对服务质量的统计或整体认知；
缺乏能针对 80% 线上问题的排查和解决的标准化流程，依赖用户对问题的定位和解决能力。

最后

Serverless 云研发平台经过这半年多的蜕变，已经从简单的解决工程链路的平台演进成一个面向研发、上线、运维的全生命周期研发平台，后续要解决的命题会集中在用户低门槛上。

希望我们在 Serverless 上的实践和探索，能给业内其他公司带去一些启发，让路上的障碍变少，让应用的研发变轻。

原文链接
本文为阿里云原创内容，未经允许不得转载。