【第1735期】蚂蚁金服Node.js 基础服务 - 摸爬滚打才不负功名尘土

前言

看看关于蚂蚁金服技术Node基础服务的历史。今日早读文章由蚂蚁金服@天猪授权分享。

@贯高，目前负责蚂蚁体验技术部的基础服务团队

正文从这开始～～

作为『那些年的体验技术部』一文的亲历者，蚂蚁体验技术承载了我们的梦想，走过了十年，经历了风雨，也收获了掌声，但这都只是波澜壮阔的互联网发展史中的小小缩影。

下一个十年会发生什么？我们无法预测，但我们正在尝试给出答案。在本文中，我将展开阐述下体验技术部中的基础服务组的过去、现在和未来。

初创时期

蚂蚁体验技术部起源于基础技术，当年玉伯从淘宝转岗到支付宝，开启了基础技术的新征程，那时的团队更像一个创业公司，开源的工作方式、异步沟通协作、做基础技术的同时怀揣着产品梦。

早期的基础技术和大部分前端团队一样，主要 focus 在前端组件库和工具领域。

在那个时候，前端不被视为研发，还是野生的孩子，背负着『如玩具般简单』的刻板印象，为了摆脱刀耕火种，我们只能撸起袖子自力更生。

蚂蚁组件库经历了从 YUI 到反复推翻自己的 Arale，工具也从 antx、maven 到反复推翻自己的 spm。

这一时期主要还是解决温饱问题，还谈不上工程化，仅仅是通过一些自动化的手段来加速前端的开发。

随着前端的飞速发展，npm 包极速增长，webpack 生态越做越大，前端框架也成三足鼎立的之势，玉伯决定基于 React 重新打造一套组件库，不过那就是另外一个故事了。

在这过程中我们积累了不少 Node.js 工程实战经验，基础技术逐渐下沉为体验技术的底盘，关注如何把各种新兴技术进行民用化、工程化，为上层的创新业务提供炮弹支援，扩大前端能力、提升前端效能，成为我们的初心和责任。

破土而出

随着前后端的演进，前端为了更好的提效，需要把 API 聚合层掌控在自己的手里，越来越重视 Node.js 这利器。

然而，在那个年代的阿里技术架构中，Java 一家独大。新生的语言，要想立足，难度非常巨大。

那时 Java 提供的中间件服务、通讯协议、SDK 完全不考虑跨语言，我们需要自行实现大量的中间件 Node SDK。

蚂蚁的 LDC 架构也导致我们需要自行实现很复杂的路由规则等。

同时在运维上的挑战也不小，研发平台只支持 Java，我们只能作为非标应用接入，需要自行实现很多脚本来伪装为 Java 应用，方能适配日志采集等运维能力。相比阿里集团的同机部署方案，我们采用的 Node 独立部署方案受到了非常大的挑战，在没有说清楚 Node 这层能做什么的时候还在链路上新增了一层调用，"耗费性能又无法提升研发效率" 是最大的质疑。

然而站在前端的视角，我们坚信，这是最佳的前后端分层方案：由前端来提供页面所需的 UI Model，Java 提供领域模型。

这一年前后，苏千、不四等 Node 社区的活跃成员先后转岗蚂蚁，苏千在原来的业务线已经使用 Node 做生产服务了，他也是开源框架 Koa 的核心开发者，让基础技术有了定心丸。苏千和玉伯一拍即合开始研发 Node 框架 ，当时蚂蚁的 Java 框架叫 SOFA（沙发），我们希望做一个更轻量的，因此这个 Node 框架被取名为 Chair（椅子）。

第一个使用 Chair 的应用是『我的支付宝』，当时算是流量比较大的前台应用了。正如上面所说，当时 Node 中间件体系并不完善，百废待兴，Node 还无法支持一个复杂业务的所有能力，所以当时 Node.js 侧重点在和前端侧的研发模式结合上，对后端的结合则使用一个 Java 应用作为透明代理，通过直连的方式调用下游的服务。支付宝第一个 Node 应用平稳经历了当年的双十一，验证了这种模式的可行性。

崭露头角

随着 Chair 框架的完善和前后端分层理念在整个集团乃至社区的传播，这种模式也迎来了一个新名词 BFF (Backend For Frontend)，这个词能很好的解释前后端分层以及这一层的价值。越来越多的人认可了这种模式，也越来越多的前端愿意尝试写服务端代码。

这期间余化、汤尧、不四、宗羽、自成、孝达纷纷加入了基础技术，在这群人的碰撞下，Chair 飞速发展。

• 汤尧的 jar2proxy 创新性的把 Jar 解析为对应的 Node RPC 类，解决了 API 定义和协作问题。

• 宗羽支持了绝大部分的中间件 SDK 研发，扫清了 Node 走向更强大的全栈应用的障碍。

• 朴灵的 Alinode 使得我们再也不用担心内存泄露和 CPU 问题，放心的上线。

• 苏千不四的 tnpm 解决了 npm 龟速问题，以及私有库的管理。

等等等。。。

2015 年 9 月，Chair 1.0 正式发布，这是非常重要的历史节点。1.0 发布了插件机制，从一个单体框架抽出了 37 个插件（现在的 Chair 拥有将近 100 个插件），成为了后续开源 Egg 的基础。

同年 10 月，苏千组建了阿里 Node 虚拟工作组，以这套插件机制为模板发起全集团共建，并将其取名为 Egg，有孕育孵化之意，希望各个 BU 可以在共建的基础上孵化适合各自业务场景的上层业务框架。天猪也是此时作为 UC 的代表参与到共建，只身背着一台 Mac mini 跑到杭州借个显示器一起闭关。

短短半年间，各 BU 通力合作，陆续发布了基于 Egg 的上层业务框架（Nut、Begg、Columbus 等）。Egg 就这样没有一点波折的快速成为了阿里 Node.js 的核心基础框架。

回头看这段历史，只能感慨天时地利人和：

• 各 BU 的 BFF 建设刚起步，没有太多历史包袱。

• 来着五湖四海十几个 BU 的前端骨干自下而上的 Open 的心态。

• 苏千等人多年在 Node.js 耕耘积累下的几百个模块，以及由此带来的强大的号召力。

• 庄少、不四等也通过天猫双十一等场合的业务实践，用出色的业务实践，给出了有力的回应。

次年 9 月，天猪在 JSConf 2016 上正式对外开源 Egg，它对 Node.js Web 应用规范的提炼，完善的插件生态，深入浅出的文档，在国内的口碑与日俱增，目前已经破万 Star，各大公司包括腾讯、百度、美团、网易、头条、小米都有不少团队使用。

这一阶段，我们证明了 Node.js 的能力和价值，并不是 Node 不适合做大项目，而在于基础设施和实践的沉淀，需要有团队踏实的深入进去踩坑，为后人铺路，Node 自此在阿里全面开花。

与此同时，我们积极地参与开源，回馈社区，除了 Egg、cnpm 外，我们在 Node 社区发布了大大小小几百个模块。希望能一起盘活前端的盘子，促进业界发展。

黄金时代

Chair 在 0.10 时就已经实现了无线网关的功能，无线时代是 BFF 非常好的机会，这也是蚂蚁当下最常用的场景。

这一时期前后端分层已经成为共识，在各个 BU 出现了大量的 BFF 应用，H5 + BFF 已经成了前端团队的标配，前端这个岗位的职能在不断的扩大，已经能处理较为复杂的业务问题，也跳出了一直被诟病的不懂业务的怪圈。Node.js 成为了阿里技术栈的另一重量级玩家。

然而随之带来的研发效率问题，需要我们去直面和解决。

上面提到，阿里的研发平台等当时都是专为 Java 服务的，也没有计划支撑跨语言，我们依旧需要自力更生。而随着 Chair 框架的不断完善，使用 Chair 开发一个全栈应用成为了可能，我们的武器已经强大起来了。

这一时期，前端研发平台 Basement 出现了。早期的 Chair 应用都是以非标应用的身份来使用 Java 的研发平台，前端组件发布也是自己的流程。因此我们需要自己定义前端研发平台，根据前端的特点定义我们的研发模式，通过技术手段针对性的解决前端研发痛点。如今它服务于蚂蚁几千位 Web 开发者（甚至包括几百个 Java 中台开发者）。

这一时期，Dockerlab 出现了。Dockerlab 是基于 Docker 做的一个内部 PaaS 平台，可以让开发者非常简单的在测试环境部署起应用，进一步降低了前端的研发成本。这为前端创新创造了土壤，离从想法到产品又更近了一步，很多不错的内部创新中台都孵化于此。

这一时期，Basement BaaS 出现了。提供了一套快速使用的 API，包括文件上传、NOSQL 数据存储、异步任务等服务，结合 Dockerlab 可以快速开发一个应用，极大的降低了前端的研发成本，这也是 小程序 Serverless 雏形。

• Render：高性能高可用的页面渲染和托管方案，支持亿级 PV，能满足绝大部分业务场景的动态渲染能力。

• File：基于 OSS 高度定制化的文件上传服务，屏蔽底层 OSS 细节，实现文件上传的开箱即用。

• DB：NoSQL 数据存储服务，用于中台快速迭代期的数据存储。

• Task：异步任务，覆盖高 CPU/MEM、执行周期较长的操作，支撑了蚂蚁前端的绝大部分构建任务。

• Message：消息推送的服务，涵盖邮件、短信、钉钉、机器人等渠道。

• 还有 FileSync 文件同步、Redirect 短链服务、区块可视化配置服务等等。

这些为前端量身打造的平台陆续出现，极大的提升了前端的研发效能。

在这个时期，以框架能力为中心，开始向研发平台、BaaS 等方向发展，一方面解决 BFF 研发效率的问题，另一方面继续扩大前端的能力，先通过自建平台来满足自己的需求，再对外开源输出能力。

潮起潮落

如上面所述，我们通过框架来提升工程师的开发效率，通过平台来把一部分场景的复杂度消化掉。

理想是美好的，但现实是残酷的，当我们站在一个山峰的时候，却发现：

BFF 的增多给前端不可避免带来额外的治理成本，知识面的拓宽对人的要求变高了，前端不仅仅要了解前端知识还要了解服务端知识，招人和培养的成本也因此变高了。

基础技术团队维护的 Node 中间件也逐步增加，而且需要跟着 Java 的变化持续维护，变成了代码翻译机器。

技术商业化也成为了新的课题，开源影响力并无法直接带来商业的成功，但基础技术还是继续探寻框架和 BaaS服务商业化的可能，中间也走了不少弯路。

这一时期，对未来方向的迷茫以及当前现状的压力，整个团队都陷入了低谷。有些同学换了赛道去 Cloud IDE、小程序等去继续自己的探索，也有新的同学加入到基础技术来验证自己的想法。

这一切迫使我们开始不停思考：

中间件的维护，真的需要每个语言独立维护 SDK，重复实现一套逻辑么？有什么新技术可以为我所用么？

交付给开发者的，除了框架还能再进一步么？能否既不增加额外负担，又能扩大前端的能力呢？

扬帆起航

这是最好的时代，也是最坏的时代。

上一个阶段的痛苦和思考，随着云原生和 Serverless 领域的兴起以及阿里经济体整体云化的快速推进，我们找到了新的发力点，继续为扩大前端能力和为前端提效两个目标而努力。

如上图是蚂蚁体验技术部的矩阵大图，我们基础技术负责其中非常重要的两项：

• Serverless For Frontend - 蚂蚁前端云化的基础底盘设施，为云凤蝶，Cloud IDE，语雀等产品保驾护航。

• 小程序云 Serverless - 阿里经济体一朵云战略，基于 SFF 对外开放我们的能力来服务外部开发者。

我们重新定义了 BFF，称为 SFF (Serverless For Frontend)，为高效的开发人机交互界面提供无感的服务能力。

未来不管怎么演变，与人机交互界面都需要这层 SFF。大致可以分为三类，可互相调用：

• Function (80%)：函数，快速开发 Core model 到 UI model 的转换。

• Application (20%)：全栈应用，主要使用 Node 开发中台应用。

• Task (<10%)：异步任务，覆盖高 CPU/MEM、执行周期较长的操作。

SFF 研发模式的核心点在于：不增加额外成本的同时，扩大前端能力。

轻研发、弱流程：让开发者关注于业务代码本身，简化第三方接入流程。

一站式、免运维：贯穿整个研发流程的一站式研发体验，无需关注运维，系统自动根据流量扩缩容和故障自愈。

云端一体化：前后端研发模式融合，降低理解成本，自动生成前端 RPC 代码，Code Once Run Everywhere。

此时此刻，非我莫属

基础技术从玉伯到苏千、再到我们这代，工作职责也从前端框架到 Node，从工程化到 Serverless PaaS，虽然工作范围更偏服务端，但 为前端提效 和 扩大前端能力 的初心一直没有变，这两个目标总是交替螺旋上升的。

也许外面很多人都在唱衰 Node.js，但我们一直坚信未来十年内，Node 是整个前端的护航者，必不可缺。

我们做了很多事，但有更多的事需要我们去做。活多人少有挑战，撸起袖子拼命干。

此时此刻，非我莫属。你是否希望撸起袖子，一起描绘前端基础技术的未来。

关于本文 作者：@贯高 原文：https://www.yuque.com/afx/about/nodejs

为你推荐