作者 | 禾易

来源 | 阿里巴巴中间件（ID：Aliware_2018）

造梦者 | 王树彬，阿里巴巴闲鱼架构负责人

2014年6月28日，阿里即将赴美上市的这一年，西溪园区的一个茶水间里，28个人日夜赶工了三个月后，上线了一个闲置交易平台——闲鱼。

今年5月份，在阿里巴巴的年报中对外公布了闲鱼的数据：GMV2000亿元，同比增长100%，每天在线卖家数超过3000万人。 闲鱼已经从一个茶水间创业的内部小产品，变成了在C2C领域的领先平台。

据艾媒数据估计，2020年全年的二手物品交易市场的规模将达到万亿以上。线上交易的繁荣亟需技术架构做相应的调整、演进才能支撑业务的快速发展。闲鱼对于阿里而言，有比营收更重要的意义，那就是创新。

创新不只体现在业务模式上，闲鱼的技术架构也在探索最新的方向——向Flutter化、云原生/Serverless化发展。

2009年，从浙江大学毕业的王树彬，在UT斯康达工作了三年后，加入阿里巴巴。2017年，王树彬首次将Flutter引入到闲鱼，从2018年开始，王树彬带领闲鱼技术团队在下一盘更大的棋：布局Serverless。

颠覆性创新往往是从边缘性的地方出现，而向云原生化/Serverless化升级，对于闲鱼是一条全新的路，但趟出了这条路，对于很多做线上交易的公司有着巨大的借鉴意义。

今天，我们就一起聊聊闲鱼的云原生故事。

 

为什么要做Serverless？

闲鱼是依托阿里电商体系的前台型业务，有非常独特的业务特点和用户诉求，在底层依托阿里系统的同时，在表现层和业务层需要探索适合闲鱼的、并且更加快速灵活的研发体系。

按照传统的开发方式，闲鱼原有的 IT 系统会面临很多痛点，比如：

1. 客户端交互层、服务端业务胶水层、领域层边界划分不清晰，这就导致很小的业务需求就需要整条链路的同学参与，协同成本高，开发调试周期长。

2. 服务端存在巨型应用，研发耦合、发布耦合、运维耦合严重，甚至系统稳定性也受到很大挑战，单个业务问题往往会影响整个应用。

3. 运维成本极高。为了保障业务的稳定性和可用性，阿里对每一个应用上线都有相应的规范和规则。哪怕是一个很小的内部应用，一天可能只有一两个访问量，上线也需要遵守既有的规范，这势必会消耗一些固定资源。

   单个应用消耗的资源可能很有限，但所有应用消耗的资源累积起来也是一个不小的数字。而对于巨型应用，由于影响面巨大，发布时要有更加严格的流程和步骤，一次发布至少要耗时6小时，导致运维成本极高。

Serverless 的出现，一方面使云端一体化研发成为可能，很多小业务需求的协同成本可以大大降低。另一方面，Serverless 使业务胶水层的巨型应用，有了比微服务更加合理的拆分方式。

传统巨型应用的成本（速度）、稳定、质量相互制约的瓶颈，可以用下面这个三角形来直观的表示。

云原生/Serverless 这些新技术的出现，可以使应用运维能力下沉，传统巨型应用的成本（速度）、稳定、质量相互制约的瓶颈才有可能被打破。

闲鱼在落地新技术的过程中，先围绕 Flutter 重点攻坚了 Flutter 混合工程体系、高性能组件库。然后围绕Serverless 重点攻坚云端一体化研发体系、服务端业务组装层架构体系。

闲鱼客户端基于 Flutter 进行架构演进与创新，通过 Flutter 统一 Android 和 IOS 双端提升研发效能之后，希望通过 Flutter+Serverless 解决各角色间存在的大量的协同问题，正是这些问题导致整体研发效率低，移动端离业务越来越远，服务端没有时间做底层领域沉淀。

通过 Serverless 的引入，闲鱼会明显看到整体研发效率的提升。

 

一边探索，一边实践

2018年，闲鱼技术团队开始探索 Serverless，整体分为四个阶段：自建Dart Server、依托FaaS平台、云端一体化、传统巨型应用Serverless化。

2018年5月，以 Serverless 思路构建了2s内冷启动的 Dart Server 应用框架，用于服务端业务胶水层的轻量化开发。

2018年底到2019年初，闲鱼启动与Gaia团队协同共建基于Gaia平台的Dart 运行时，并上线了部分业务。注：Gaia是基于阿里云的面向淘宝业务特点封装的、用于淘宝业务的FaaS平台。

2019年，闲鱼基于Gaia的Dart Runtime标准化，探索 Flutter+FaaS 云端编程一体化，领域接口元数据化，最终诞生了 Nexus 等胶水层业务框架，并在闲鱼20多个业务落地。

2020年，闲鱼开始进行云端的工程&工具一体化，目标是实现一个工程、多端部署。现在，王树彬正带着技术团队攻坚业务胶水层的传统巨型应用治理，使传统应用向Serverless化迁移，“最快3个月，最晚6个月，我们就会交出一份漂亮的答卷。”

具体来看过去这两年的时间里，闲鱼在Serverless上的实践成果，主要分为5个方面：

1. 云端编程模型一体化框架（Nexus API）

这个框架的目标是使Flutter、FaaS的编程模型统一，打通UI、交互、数据、逻辑。王树彬提到，一开始说要做Flutter + FaaS一体化的时候，我们对“一体化“这三个字的认知相对比较模糊，只是知道端侧的同学可以用 Dart 这门语言来写FaaS函数，这其实还停留在语言上的一体化。

对于FaaS所能做的事，也仅仅停留在前端实施已久的BFF层面。

我们花了很长时间来讨论，基于Dart生态下，前端的 FaaS 在研发交付其实并不高效，研发阶段主要面临的问题是：

编程语言不统一：编程语言本身虽然不是最大的障碍，但这也确实给前端开发者增加不少门槛，而且更重要的是语言背后的生态、环境与体系更是一道高高的墙。

开发模式与架构割裂，环境复杂：端侧一个工程，FaaS侧也有一个独立的工程，它们背后有自己的一套构建、调试、集成/发布的工具链；除此之外，FaaS 还有自己配套的环境、Runtime、框架作为支撑。

开发者面对这样复杂的 FaaS 研发环境与双重的研发工作流是无法做到高效交付的。

最终，我们对一体化有了一个比较清晰的共识，那就是要实现两个核心的一体化：

• 语言一体化

• 开发模式与架构一体化

编程语言的一体化可以为开发者提供一种熟悉的技术栈，开发模式与架构一体化能帮助开发者解决工程割裂以及背后复杂的 FaaS 本地运行环境问题，带来与原研发模式基本一致的研发体验。

通过这两个层面的一体化，最终达到开发 Flutter 页面和开发 FaaS 无明显Gap。例如，闲鱼客户端Flutter以往是用Redux框架开发，在Nexus API框架下，可以使Redux与FaaS调用无缝集成。

1. CLI 开发工具标准化

云端一体化开发时，通过 CLI（命令行工具）屏蔽 FaaS 开发的一些细节，使客户端开发 FaaS 时的开发体验标准化，符合客户端同学的本地开发习惯。

1. 基础服务 BaaS 化

过去两年，我们在逐渐简化基础服务能力，如对象存储、消息、搜索。同时，建设业务领域层服务的元数据中心，这些简化的基础服务能力，再加上已有的业务领域层服务，使客户端同学可以快速组装业务。

1. 云端工程一体化

闲鱼在成功引入 Flutter 后，在端侧形成了以 Flutter 为主、H5为辅的跨端研发体系，使传统的 Android 和 iOS 的两端研发，合并成一端。在端上的生产力得到释放时，我们发现端的同学有机会向下层走一点，使服务端面向简单的数据组装逻辑，由端的同学一人闭环完成，这套模式尤其适用于一些小业务的需求。

类似的尝试业界其实早就有了，例如 GraphQL 框架的流行，前端的BFF层的形成。但有了Serverless，服务端轻量代码的开发可以极大地简化，所以闲鱼选择这个时机推进云端一体化。

云端一体化涉及到云端编程框架、工具链、工程体系、基础服务BaaS化、领域服务下沉，同时，也涉及人员上的组织保障、分工重塑、安全生产培训等。

1. 传统巨型应用的Serverless化改造

Serverless不是银弹，但与业务胶水层的特点很匹配，非常适用于解决胶水层的传统巨型应用的拆分，这也是闲鱼正在攻坚的下一个难题。

 

难题与破局

闲鱼落地 Serverless 的过程中并非一帆风顺。王树彬提到，在Serverless云端一体化过程中，遇到了一些技术难题，比如JAVA富客户端的异构语言访问、开放环境如何统一以及客户端同学对领域接口不熟悉等问题。

在闲鱼的Java系统中，存在大量的Java富客户端应用。针对Java富客户端的异构语言访问，闲鱼以Sidecar的模式，建立Java的Proxy来解决这类问题。

紧接着，为了让开发环境统一，闲鱼开发了自己的CLI工具（GCLI）。GCLI是一个基于支撑 FaaS 研发生命周期的命令行工具，它定义了闲鱼 FaaS 开发闭环，统一了 FaaS 的研发环境，是提升FaaS研发效率的利器。

GCLI 将研发闭环拆解成适合Serverless 研发习惯的开发指令。为了让用户继承其研发习惯和工具，闲鱼优先选择了基于本地的开发方案；使用Docker技术统一开发环境，在 Dcoker 内声明Dart FaaS技术栈依赖的运行环境(软件+配置)。

借助容器技术，FaaS 的软件环境可以移植到任何支持linux运行的操作系统，从而解决了环境统一的问题；GCLI 通过 FaaS Open API 实现本地和函数平台实现互操作，形成完整的研发闭环。

最后，针对客户端同学对领域接口不熟悉的问题，闲鱼开发了领域层的元数据中心。

云端一体化重塑了传统的云、端边界，减少了协同，也给人员的分工带来了更大的灵活性，技术上的研发效率、研发质量也明显提升。而这些改变对于业务带来的直接好处，就是可以让业务有更快的迭代速度、更快地适应市场和用户需求的变化。

云端一体化目前应用在闲鱼的重交互场景以及轻量业务场景中，其带来的技术效率、质量提升更容易以量化的数据形式呈现。例如，以典型的中大型业务需求抽样统计，开发人日降低了30%，千行代码Bug率降低了20%。

如果以零散需求统计，数据提升会更加明显。以往的小需求由于多个同学参与，往往排期需要几周，而云端一体化后，资源的灵活性明显提高，使需求响应速度大大提升。

“但是，还有一些问题没有解决”，王树彬说，在 Serverless 的巨型应用拆分方面，闲鱼遇到的问题更加严峻，比如：

• 微服务和 Serverless 的选型

• 在 Functions 之间代码复用

• 对函数的依赖做统一升级

这几个问题的方案，闲鱼还在逐步验证中，待经验成熟后再向大家详细分享，欢迎持续关注。

 

借鉴与思考

什么样的公司、应用或场景应该选用 Serverless 的架构模式？目前没有具体的定义，关键在于想清楚。想清楚，就需要平衡好收益、成本、效率和应对市场的能力。

其中，成本是企业更为关注的因素，这其中包括基础设施搭建的成本、运维成本、扩容成本、安全成本等。

Netflix是落地 Serverless 的一个成功的典型，Netflix 在产品设计上一直都有创新的基因，除了不间断的 A/B 测试之外，每周都会发布很多新功能。

为了确保这样高强度的工作成果，就需要一个 API 服务平台来帮助客户端工程师快速而有效地将更改的需求部署到服务层。

FaaS 通过把那些与服务相关的所有平台组件抽象为业务逻辑本身来实现这一目标，而 Serverless 模式能够为Netflix提供一个平台，即使没有服务器和运营经验的工程师也可以开发高可用的服务。

采用 FaaS 模式，本质上是对交易速度和可能性的定制化。有些应用程序的 FaaS 服务表现得很好——Netflix API 的情况就是如此，Netflix 运行的是相对统一的微服务，只需要访问和改变下游服务的数据。

然而，如果服务需要定制化，例如需要改变服务平台的各个组成部分，像 RPC、数据访问、缓存、认证等，那么 FaaS 模式可能无法为这些服务提供足够的灵活性。

自建 Serverless 平台对企业IT人员的要求比较高，同时建设成本也很高。另外，实施Serverless 需要一个成熟的生态。

绝大多数情况下，已经上云的企业应该优先考虑云厂商的Serverless产品，而没有上云的企业，需要考虑现有系统的生态情况是否能与云厂商的Serverless产品兼容。

对于 Serverless 产品的选型，应该综合几个方面来看：生态的成熟度，支持的开发语言，功能丰富度，收费标准等，关键是结合企业自身业务发展的需求。

 

关于未来

O'Reilly 曾对 Serverless 的应用情况进行了过一次调查，发现软件行业的开发者关注和应用 Serverless 非常多，这在意料之中，但是金融和银行业也在高度关注Serverless，原因之一是越来越多的金融科技初创企业的诞生，它们承担了传统基础架构的责任，并且以更开放的心态，接纳和拥抱 Serverless 。

对于拒绝 Serverless 的理由，60% 的受访者表示是安全问题。因为很多行业对于 IT 环境的安全性要求很高，而采用任何新技术都可能会带来安全风险。

此外，开发者另外一层顾虑主要是担心被厂商绑定，这就导致具备一定规模的组织会基于开源方案，如 Knative，搭建自己的 Serverless 平台。而一旦某个开源方案成为主流，云厂商就会主动去兼容开源标准并增大社区投入。

Serverless 除了对技术和业务产生影响外，对于企业组织架构和技术人员也提出了新的要求。

首先，Serverless 改变了沟通结构。按照康威定律，组织架构需要适应新的沟通结构，才是最好的匹配。

闲鱼以前负责客户端和服务端的同学是分开的，在全新的 Flutter+Serverless 的背景下，组织结构也需要做相应的调整。经过讨论，闲鱼最终决定按照业务线划分，将客户端、服务端的同学按业务线重新组合到一起。

其次，Serverless 使客户端的同学有机会更多的了解业务，这就要求客户端同学更加具有业务敏感度。Serverless 促使客户端同学扩大了技术边界，也需要了解一定的服务端开发概念。

最后，Serverless 要求原有的服务端同学有更好的数据建模、领域建模能力，从而有助于底层接口复用度更好。

从最开始不被外界看好，甚至被调侃为“咸鱼”，到如今实现了千万DAU，盘活了一个万亿级市场，闲鱼的出现，无论是对前端的电商生态，还是用户在互联网上的生活形式，都产生了重要的影响。

为了支撑起闲鱼万亿的交易规模，王树彬和技术团队正在紧锣密鼓地进行传统巨型应用的 Serverless 化改造，“闯过了 Serverless 的这一关，才是我比较满意的状态。”