Qcon 分享 | 从 NodeX 到 Serverless, 滴滴前端服务工程化实践之路

目录

今天的分享内容是在过去几年里，滴滴在Nodejs和Serverless上的思考与实践。我们将从 1个Why，3个How 展开。

1.

为什么要进行 Nodejs 工程化

我们为什么要进行 Nodejs 工程化，放了两张图。第一张，我们希望泛前端开发者能更高效的交付更多业务价值，因为你的公司，你的老板更关心的是交付的业务价值。第二张，作为泛前端开发者，我们都希望能更深入到冰山的下面，只有更深入业务链路，才能更好的发现和创造业务价值。

我们将冰山横置过来，我将它分为4分，左侧是服务端技术，右侧是端技术。在最右侧，也就是冰山的最上面，是我们泛前端开发者长期深耕的一块田地，把这一块定义为为用户体验负责，包含我们日常熟悉的UI组件，互交互应用、可视化等等。再后面是一块是我们也熟悉的，比如：页面搭建，跨端框架，微前端等为研发效率负责的一层。在后面是我们今天要探讨的话题， 如何进行 Nodejs 工程化，为泛前端基础设施负责。

当我们决定要使用 Nodejs 深入到后端时，我们会遇到很多痛点，我把它归纳为3类。

• 可行性：如何和公司的运维体系打通？如何和公司的基础能力打通？几年前我们刚开始做Nodejs，可以看到右侧这张我们公司运维平台的截图，是找不到 Nodejs 的，被归纳到其他语言里。
• 稳定性：当我们前端刚开始做服务时，我们是缺乏后端思维的，比如你的服务稳不稳定？出现异常是否能及时发现？发现异常是否能及时止损？发现异常是否能及时定位？流量能不能抗得住？有没有限流？有没有降级？等等。我们希望交付更多业务价值，却为服务的可靠性、可扩展性、性能支付高额的成本。
• 易用性：当我们团队通过几年打磨，沉淀了最佳实践，但如何能让最佳实践能被其他同学低成本的批量复制？只有能被批量复制的模式，才是能创建更多价值的好模式。

2.

如何打造公司 Nodejs 生态 为了解决上面三个方面的痛点，我们打造了面向公司内部的 Nodejs 生态，把它命名为 NodeX。这是NodeX 的首页，它的slogan叫 让Node服务更简单。

我们来看下 NodeX 在解决什么事。当你要在公司内创建一个服务时，你需要关心的分为两部分，应用维度和代码维度。它们分别包含，对接公司的基础镜像、构建规范、部署规范、日志、监控、报警、集群的配置管理等等，另一部分是如何选择框架，使用何种编程范式优雅的管理代码。我们将这些很多很多你需要关心的，收拢放入到右侧NodeX中，对用户更开箱即用，更友好，那么之前散落在各个部分的业务逻辑将聚合在 NodeX 的上层，使你更专注于业务代码开发。

我们再来看下 NodeX 如何解决的。下面这张图是 NodeX 的全局图。底部左侧是公司的运维基础设施，右侧是包含数据存储、数据通信的基础服务。在这之上是解决可行性的一层，这层是面向 Nodejs 的各种SDK组件，打通底层的运维基础设施和公共基础服务。我们沉淀出一个叫 NodeX-Component 的SDK组件库。在上层是业务框架，框架解决了开箱即用，并和组件层快速打通，并提供了良好的编程范式来辅助开发者组织代码。这一层我们沉淀了一个叫 Degg 的业务框架。再上层是通用服务，比如 静态资源服务、上传服务、埋点服务，这些都是常见的泛前端开发者需要的服务。左侧中有个定位和排查 Nodejs 稳定性的工具：Nodejs 性能分析平台，我们把它命名成 NodeX-Monitor。

我们来分别介绍下 NodeX 三板斧：NodeX-Component、NodeX-Degg、NodeX-Monitor。第一个是 NodeX-Component， 这是一个Nodejs SDK 组件库，包含来自滴滴普惠、金融、车服等多个泛前端团队沉淀、统一的SDK, 总共近30个 ，他们部分与社区共建，同时也进行了对接公司内部基础设置和服务的适配，添加了公司标准规范的日志、监控上报，全链路压测等逻辑，另外一部分是完整内部打造，对接内部服务的。

再说到业务框架，我们调研了业界的主流框架，也讨论了自己打造的方案，最后选取了Egg做为我们业务框架的基础。因为 Egg 本身的定位足够灵活，且符合我们打造企业级业务框架的诉求。下面这张图，展现了 Egg 作为框架的框架是如何孵化上层的。我们的业务框架命名为 Degg ，它和阿里的Begg/蚂蚁的Chair 属于同一层。在Degg 里 我们对接了NodeX-Component 里的组件，并包含必要的公司基础镜像、运维规范、多集群配置、性能分析等能力，其他默认插件是关闭的，希望上层能孵化出更多业务领域的业务框架。

再来看下性能分析平台，在性能分析平台上我们走过多个阶段。最开始我们基于pm2进程收获，pm2 本身商业化产品有个后台系统，可以查看守护的进程相关信息，在其runtime中包含着这些信息的采集，故我们通过pm2.describe接口获取到这些数据，将其通过nodex-metrics上报，和运维监控报警体系对接。可以看到(多张图被盖住了)，在运维监控图中，我们看到了进程的重启次数、存活时间、进程的cup占比，内存、堆内存等情况。另外一块非pm2守护的进程我们通过Nodejs 原生API来采集，目前只有cpu 的profile 还未有这个原生API能力，我们通过社区v8-profiler C++插件来实现对v8 api 的暴露，实现了采集和后台的分析展示，如图所示（多张图又被盖住了）。在今年随着团队成员加入EZM，我们搭建起现在的版本，如下所示，后面主要通过深度共建回馈社区和定制能力自研增强的方式双工迭代。

3.

如何打造公司 Serverless 生态

以上我们为了在滴滴内部构建 Nodejs 企业级应用，解决了可行性、稳定性、易用性相关问题，沉淀了 NodeX 生态。但对于同学们使用接入 Nodejs 服务，还是存在很多问题，比如机器和域名的申请，机器的利用率，服务日常运维等等，还是给开发者带来了很多额外成本。对了，这正是 Serverless 可以解决的问题。故我们继续开启了我们 Serverless 之路，下面是我们滴滴 Serverelss 产品的首页，slogan叫 弹性计算，触手可得。

我们先简单来看下，什么是Serverless？在以往我们通过虚拟机来将一台物理机切割成多个服务部署的部分，后来容器技术Docker的兴起，更轻量隔离方案代替了VM, 在这之上是Application 应用服务，再上门是 Function函数服务。可以看到越往上隔离粒度越细，越专注业务。我们把最上面两层 Application + Function 叫做 Serverless, 开发者无需关注服务器，只需要关注业务代码。另外我也很喜欢一句话，Serverless 是一种理念一切让我们开发者更关注业务代码的工程化，都可以称作 Serverless 。

在推进 Serverless 落地过程中，我们调用了很多方案，最终我们先后实践了下面这两条路：

• 通过 Nodejs 实践，打造面向 Nodejs 语言应用的 Serverless 方案
• 通过 Knative 实践，打造面向多语言应用的通用 Serverless 方案

在讲具体的Nodejs 方案前，我们先回顾下 Nodejs 的 进程、线程、isolate 模型，更有助于我们理解 Nodejs 实现 Serverless 的原理。

先看一下下图左侧是我们日常启动一个 Nodejs 服务的一个进程模型，它包含：

• 一个进程 + 一个线程 + 一个事件循环 + 一个 Nodejs 实例 + 一个 JS 引擎实例

然后我们再来看下进程+线程的模型，此时如右图所示，包含如下：

• 一个进程 + 多个线程
• 每个线程包含事件循环 + Nodejs 实例 + JS 引擎实例

这里需要重点强调下每个线程里包含独立事件循环 + Nodejs 实例 + JS 引擎实例，这很关键。我们知道 Nodejs 是适合IO密集型，对cpu密集型很敏感，一个进程一个事件循环，当事件循环中有一个cpu密集型计算，会阻塞掉其他所有请求的处理。线程模型中，包含自己独立的事件循环，并且还要自己独立的 Nodejs 实例和执行引擎实例，这让不同线程之间有较好的隔离性。

下面这张图很好的反映出上面关系。在左侧js线程中 除了 Event loop， 我们看到 V8 Isolate 它就是 一个js 引擎实例，能执行我们最原生的 javascript 语法，如 i++。上面可以看到 V8 Context 以及外部紫色的 Environment 这就是基于 Nodejs 实例提供的 Nodejs 上下文环境，比如：require(‘fs’) 模块。从这里可以看到线程之间，他们不仅仅事件循环独立，它们的 Nodejs 所有上下文实例是独立的，js 执行引擎实例也是独立的。

如下是通过 Nodejs 实现 Serverless 的4种方案：

• 基于 Nodejs 热更新能力，我们发布 faas 函数“脚本”文件，然后通过删除 Nodejs require 中缓存的模块，重新加载就能动态执行最新的函数。
• 基于 child_process 子进程的能力，我们为每个应用函数启动一个进程，然后提供服务。进程已经有一定隔离性，进一步隔离性可以通过 linux 控制组等能力限制。
• 基于 worker_threads 的线程能力，我们为每个应用函数启动一个线程，然后提供服务。线程也有不错的隔离性，其中一个函数的死循环不会阻塞影响到其他线程正常提供服务，因为线程本身在cpu上通过时间片轮转来依次获得cpu使用的时间。
• 基于 V8:: isolate 能力，我们为每个应用函数启动一个isolate， 然后提供服务。因为isolate 只包含js的执行能力，不包含任何上下文，故这部分需要平台方在runtime里定制注入，但它更轻量，安全隔离性更好，它适合比如一些硬件平台动态分发并执行脚本。

下面这张图对上面4种方案，在内存、启动耗时、执行耗时、通信耗时、隔离性、易用性 多个维度进行了的对比。通过我们之前对进程、线程、isolate 模型的介绍，我们能较为清晰得获得下面的对比。其中可以看到一排红色标注出的 worker_threads 的方案，对于我们面向“可信”开发者做Serverless 方案是最为适合的，在内存占用较小，启动速度较快，通信效率较高，更重要的是它保留了易用度高的同时还有较好的隔离性。

下面这张图是基于 Nodejs 结合 worker_threads 实现 Serverless 的架构图。当用户通过一个url: 域名/group/rep/file 路径, 通过网关访问到runtime服务里。master 进程会基于路径唯一性，去启动该接口对应 faas 函数的 wokrer 线程。执行 new Worker (${(localDir} /${group}/ ${rep}/${file}.js)，如果本地没有文件，第一次会去远程文件服务上拉取文件到本地。对于开发来说，使用开发者工具，cli 或者可视化工具，发布特定函数到文件存储服务即可，函数可以是一个文件，也可以是一个正常的工程，包含node_modules的zip包。当我们启动runtime时，会启动一个agent 注册到 管理服务上，当开发者发布后，会通知到各个agent, 然后它们会更新本地文件。

在master进程的职责，包含请求的路由，worker 的缓存与弹性回收，worker cpu/内存异常处理，worker的守护等。

我们看下通过 Nodejs 实现 Serverless 的利弊。

• 优势：

• 资源利用率大大提高且有一定隔离性

• 面向业务开发Serverless

• 前端开发者可闭环，方案落地相对可控

• 劣势：

• 无文件IO隔离性，恶意开发者可以通过 fs 等其他方式runtime 源码文件读取破坏。

• 外部容器无法弹性伸缩

• worker管理复杂度留在master，越简单越可靠。

• 机器申请/域名申请/日常运维，仍然有人要去承担前端基础团队并没有Serverless

为了解决 Nodejs 实现的以上问题，同时也希望 Serverelss 方案是支持跨语言栈的，真正让所有开发者迈入 Serverless 时代，让 Serverless 的降本提效的能力充分发挥。另一方面，来自公司不同技术栈的的合作方，能更好的形成合力，考虑和解决问题更为全面。

在充分调研了行业内现有 Serverless 产品和方案后，我们选择了基于 Knative 打造应用级 Serverless 的方案。Knative 是什么？它是谷歌发起的致力于将 Serverless 标准化的开源方案，基于 K8s 之上部署管理现代 Serverless 负载：函数、应用、容器。

下面这张图展示了 Knative 处于的位置，在 K8s 之上，在 Istio 之下, 它们分别致力于成为各自领域的标准，并都由谷歌发起和主导。

在 Knaitve 里由几个组件组成，Eventing 组件，Serving 组件，之前还包括 Build 组件来做代码到镜像的持续集成工作，后来 Knaitve 社区决定这不应该是 Knative 需要关注的，应该更聚焦在Eventing/Serving 两个核心功能组件上。故自身项目删除了 Build 组件，推荐使用社区 Tekton Pipelines 来做这件事。

下面这张图是滴滴 Serverless 现在的全局图。我们从下往上看，

• 平台层

• 底层，两层，K8s 集群 + Knaitve 集群

• 在集群中跑的是各语言框架，这边列的是 Nodejs 服务框架，如：NodeX 里的Degg, Express、Koa 等

• 在语言框架之上，是在集群里跑的一个个Runtime 应用服务，之上一个个 Function 函数或者小应用，另外也可以是一个个和传统服务一样的 Application。

• 在应用之上是Baas SDK 层，这一层是在 NodeX 里 NodeX-Component SDK面向 Serverless 场景更轻量化的版本，负责与基础设施的打通

• 再上层分别是 Serverless 网关 + 业务网关。

• 研发层

• 本地 IDE 和 云端 IDE

• 然后是面向开发者的 Serverless-CLI 和 可视化工具，如：VSCode插件

• 再上层是 Serverless 里很重要的一点，基于一个个业务场景的解决方案的沉淀，比如：云函数、微应用、SSR 等。

我们再来看下，滴滴 Serverless 的全局流程图。我们将平台拆成 上层研发层，中间平台层，底层集群层，在团队分工时也是按照这个大的划分合作。面向开发者的流程是这样的：研发层各个场景的解决方案，在日常操作时会调用 Serverless-cli 这个SDK，上层根据场景可能会可视化操作。通过 Serverless-cli 调用 平台层统一提供的 OpenAPI 接口，经过账号权限校验，平台内部进行状态记录和流转，会调用通用构建平台服务，进行代码构建和镜像构建，然后调用通用部署服务，部署服务会调用底层集群提供的 OpenAPI 接口操作集群，将服务部署到集群上。

了解了 Serverless 的架构设计与流程图后，我们看下现在滴滴 Serverless 产品的的具体形态。

下图是服务的创建，支持场景化的模板创建，包含代码模板 & 配置模板。

下图是服务部署一体化的流程，包含线下、预发、线上多场景的按流量的灰度部署，用户也可以自定义场景(环境)。

下图是平台一站式的其他功能，包含日志，监控，网络等其他能力。

整个 Serverless 项目我们今年年初2月立项，在今年7月跑通整个MVP版本，12月自定义域名、日志、监控等稳定性相关完成，业务接入。目前已接入60+服务，累计接口调用量2亿+。整个过程中团队是以跨部门FT形式，在日常业务之外投入完成的，能做到这个程度，是因为整个 Serverless 项目尽量复用了已有运维体系里的能力。

首先是对现有运维体系 USN（unique service name）服务树规范的保持一致，这个很重要。因为 USN 是一个服务接入滴滴内部所有基础设施的唯一标识服务。另外我们在构建规范、部署启停规范尽量与过去保持一致，一方面复用现有的构建和部署服务，另一方面可以大大降低传统历史服务的迁移成本。另外在这之上，我们复用了构建、监控、报警、日志、业务网关、Gitlab、Agent等能力，在前端侧也尽量复用已有的业务UI组件。

下面我就9个维度，对滴滴 Serverless 进行了概况，它是应用型 Serverless 平台，现阶段面向公司内部，代码维度不同于外部如：云函数、函数计算等产品通过zip文件包管理，我们对接了公司内部的Gitlab平台。整个服务接入和操作部署，我们是重平台轻CLI的，外部往往是重CLI的。另外目前我们在配置文件资源编排上还没这么强的能力，但这同时让我们配置文件更轻量，用户使用更易上手。因为面向对内开发者，所以我们平台与内部的运维体系是强一站式的。另外，我们 Serverless 产品 包含着模板、场景、服务等级、流程控制等特色概念。

从下图在我们来看下，在拥有 Serverless 产品前后对开发者的对比， 可以看到从服务初次的创建接入，到日常部署运维效率大大提高了，另一方面得益于 Serverless 的弹性伸缩，机器的利用率大大提高了。

4.

如何通过 Serverless 升级研发模式

当我们拥有了朝思暮想的 Serverless 能力后，如何升级研发模式么？我们把它归纳为如下3点

在工程化中常常需要配合脚手架，如下图所示，在 Serverless 中同样会有，但它的角色变成了 CLI 的一个框架。它本身不提供具体命令的实现，只提供机制和规范，让在上层各个场景的开发者，沉淀包含多个命令的解决方案的具体插件，打造一个统一、共享的开发体系。

前面讲到滴滴 Serverless 是重平台轻CLI的，但同时我们仍可以通过CLI “一键” 对服务全流程的构建、多环境的灰度部署。

下面这张图展现的是在 Nodejs 前端生态里，我们基于业务场景，目前沉淀了来自多个前端团队的7个解决方案。如：faas/微应用/ssr/degg/isolate等，同时利用模板能力，我们将通用服务如：静态资源服务，上传服务等也沉淀到平台中，让有需求的团队可以快速创建并私有化部署，同时该服务核心代码层是内部开源统一维护的，基于Degg(Egg)业务层保留了灵活的扩展能力。

下面举了3个比较典型的场景解决方案：Faas / Sma（serverless micro application）/ Sma-light

• Faas ：下图右上方可以看到，开发者可以在工程中创建一个或者多个函数，和我们熟悉的云函数、函数计算等产品一样进行代码编写，函数返回即可，然后通过 CLI 发布或者平台发布。
• Sma: 如下图右下方，该类型工程中，可以看到一个页面目录中包含前端UI逻辑代码文件，也包含服务端逻辑代码文件，他们统一管理，统一发布，形成一个完整的业务逻辑单元。另外还有一个解决方案 Sma-medlar, 在这之上进一步屏蔽掉UI逻辑中 Ajax 请求的逻辑，变更为服务端的远程方法调用形式。
• Sma-light: 如下左侧所示，该类型工程在 Runtime 侧结合了前文介绍的 Nodejs 实现 Serverless 的方案，在整体 Runtime 基于 Knative 弹性伸缩下，同时保留了函数级 Serverless 的两个好处：
• 函数级的隔离能力
• 发布的轻量化，如支持工程内单一页面、函数的动态发布、回滚

接下来是云端一体化的 WebIDE, 我们公司内部也有对应的 WebIDE 产品，但目前它的架构是和 VScode 不太相同。我们前端开发者更多的熟悉 VScode 编辑器，并且我们本地一体化开发环境的插件都是基于 VScode 插件能力开发的。故经过调研，我们利用社区开源方案 + 进一步的二次开发在我们内部搭建了类 VScode 的 WebIDE， 来解决了本地一体化和云端一体化的一致性和共享性。

5.

我们的期望 下面是来自我们泛前端团队的两款产品：

• 滴滴星云：综合运营效能平台
• 桔研问卷：商业化的问卷产品

它们都是我们泛前端开发者基于全栈的能力，完整闭环交付业务价值的典型案例。今天的整个分享关于NodeX 和 Serverelsss 的工程化思考与实践，初心也是期望更多的泛前端开发者，有能力高效交付更多业务价值，希望 Nodejs 能遍地开花结果。

6.

合作的意义 最后想来聊一聊合作，下面这张图是我们 FT 成员周会的一次合影，虽然大家来自各个业务线，但因为对这件事的认可，年初立项后每周一次线上周会已经快一年了。同样也因为作为泛前端开发者我们想做些改变，Nodejs 语言也从公司之前运维体系”其他语言”里，变成现在第一个语言模块，更多其他语言生态期待被点亮，合作给我们带来了：

• 更大的合力
• 更优的解决方案
• 更多的资源和影响力

7.

合作的意义 最后我们一起回顾下全文的内容，一个 Why，三个 How，以及每一块对应的思路和解决方案。

本文由哈喽比特于3年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/84fog_u1sOksajqclA5kZQ