滴滴NodeX生态 ，让开发更高效

桔妹导读：滴滴NodeX是由滴滴普惠、金融、车服三个泛前端团队合力共建，致力于打造滴滴集团级的专业、高效、稳定的Node研发生态。帮助开发者降低服务搭建门槛，提升壁垒和快速闭环赋能业务，目前生态已覆盖滴滴大部分业务。

0. 

前言

“能用 JavaScript 编写的程序，都终将会以 JavaScript 编写。”这句话曾经听起来十分高傲，但是随著 Node.js 的发展，我们渐渐地明白到这句话的远见性──JavaScript 真的越来越强大了。

Node.js 是一个非常新兴的开发工具，虽然它诞生自 2009 年，但是它确实有史以来发展最快的开发工具，没有之一。在这短短的几年间，我们看到了 Node.js 从当初的一无所有到如今的飞速发展，说明这背后的需求场景是巨大的。

1. 

背景

早在前几年，滴滴前端技术团队就在探索 Node.js 的实践和落地，积极将传统的前端推向大前端领域，并在生产环境中考验自身以及 Node.js 的素质。无论是哪个团队，Node.js 在团队中都扮演了十分重要的角色，各个团队也结合滴滴内部的场景各自沉淀了大量组件和相关生态。

为了让我们历史沉淀的经验能够在滴滴内铸就更大的价值，并且能够输出给外部社区，我们成立了NodeX 跨团队FT，致力于打造滴滴集团级的专业、高效、稳定的Node研发体系。

2. 

什么是NodeX

有些同学可能还不知道NodeX生态到底是什么，接下来就为大家介绍下我们的生态体系，若有疑问或想交流，欢迎评论留言。

▍一张图了解NodeX

上面的图简要的概括了NodeX做的事情和愿景，我们在生态内提供组件框架、研发支撑平台以及通用服务能力，同时也有辅助开发的滴滴Node指南，贯穿整个开发周期。目标就是为了让我们的开发者能够以更低门槛、更小成本、更高效率的开发Node服务，最终提升壁垒和闭环能力，快速高效的为业务赋能。就像下面这张图一样，开发者更多的只需要关心业务代码开发。

了解完宏观层面的思考之后还是觉得对NodeX了解不够清晰怎么办？那就看看下面这个架构图吧，图里包含了各个核心的能力点和组成部分。

▍全局架构图

从上面的架构图可以看出来我们主要由几块组成，分别是上面提到的组件框架、研发支撑平台、通用服务以及贯穿整个研发周期的文档体系，各个模块都是相辅相成，下面我们就将各个核心模块一一给大家介绍一下。

【 文章推荐：车载硬件的感知能力是有局限的，Lidar的可靠感知范围不过百米，货车等大型交通参与者也会造成视角遮挡等问题…回复「自动驾驶」阅读】

3. 

组件

NodeX Components提供常用的 Node.js 基础组件模块，同时这些常用组件和滴滴各个服务进行打通，减少了很多不必要的重复底层联调对接工作。优质的组件往往需要经过大量的历史经验沉淀，以及流量的考验。

NodeX Component中的组件都在经历过真实的生产环境的鞭策，在历史的翻车和事故中沉淀了不少经验。大部分组件的解决方案都在线上跑了两年、甚至三年左右，持续不断的踩坑和维护，才锤炼出目前的稳定，同时我们也会持续优化迭代现有组件性能稳定性和拓展新的能力。目前已覆盖绝大部分场景约20余种组件，详情可以查看下面这张图：

整个组件工程是通过lerna来统一管理各个组件的开发、单测、发布等生命周期，同时提交代码也会有严格的规范，这块是通过commitizen来管理，代码格式则是通过Eslint+Prettier校验，感兴趣的可以了解下相关能力。

4. 

框架

在组件之上，得益于egg灵活的lorder机制，我们基于它封装了一套适合滴滴生态的企业级框架。框架集成了常用的开发插件及中间件，打通了滴滴内基础设施、Node基础设施，并支持了服务滴滴部署环境的个性化配置的开发的应用框架。具备易用，快速部署，健壮，生态丰富等特点，是构建企业级应用的不二之选。

与之配套的则是我们提供的sls-cli脚手架，可以一键初始化标准工程，工程内提供了符合滴滴规范的编译构建脚本，无需改任何代码即可部署线下线上环境，同时集成了基础代码规范配置。开发者可以把更多重心放在业务开发上，而不需要关心更多基础和底层的问题，如果有需求也可以对基础配置和能力进行改造，大大降低了搭建服务门槛。具体架构可以详见下图：

5. 

研发支撑

除了提供基础组件框架帮助开发者快速搭建服务外，我们还提供了一系列研发支撑的工具和平台，脚手架上面已经有讲到到，下面只介绍两个比较常用的。

▍性能分析平台

JS Runtime 对于绝大部分的开发者来说是处于黑盒状态的，开发者无法感知其运行状态，出现一些性能、内存问题时也没有很好的工具链进行更深入的支持。所以我们搭建性能分析平台正是为了解决这个问题，帮助大家更方便的解决Node性能问题、提升服务性能瓶颈、并且提供进程级监控告警能力，能够提前预知问题。

我们可以先通过性能平台的业务架构图了解它的基本能力：

从业务架构图里面可以看到，性能平台主要提供了进程级细粒度监控、告警及性能文件采集分析的能力，能够帮助开发者实时监控进程性能，及时发现并预警问题，让开发者能够前置处理性能问题，并且有很好的问题处理抓手点。

性能平台在我们滴滴内部总共经历了三个版本：第一个版本是基于PM2和V8 Profile的的采集监控版本，平台也只是支持火焰图分析；由于PM2的版本局限性太高，不能够很好的支撑各种Node工程，所以在今年我们重构了V1版本，底层换成XProfile（基于V8的能力，一个C++ addon）采集数据，这样就可以支持PM2、egg-cluster等各种进程管理的项目工程，只要是基于node8以上的版本都可以兼容。

目前是第三版，基于社区EZM的版本构建的，来自一君大神的佳作（XProfile也出自他手），后面主要会通过深度共建回馈社区和定制能力自研增强的方式双工迭代。

▍Markdown文档平台

文档平台的最开始是为了解决NodeX体系复杂的文档架构而生，在建设的过程中进行了通用化处理，为了能够给更多团队解决文档部署难、同步难的问题，提升构建文档效率，降低团队间沟通成本，同时也能形成沉淀文档的好习惯。

文档平台提供在线实时预览保存及本地编辑markdown能力，一键同步线上，无需编译，支持丰富的文档配置能力，既能满足轻量的文档编辑发布能力，又能满足复杂的混合文档能力，整体文档发布流程图如下：

而查看文档就比较简单了，整体实时渲染能力是基于开源的docsify的能力，基于它之上我们做了鉴权、样式升级、埋点等更多能力，具体查看文档流程如下：

6. 

通用服务

除了基础能力之外，我们在生态内还提供了一系列的通用服务，这些通用服务都是用NodeX体系搭建，在大多数常见场景中抽离出来通用化，开发者可以通过接口直接调用通用服务能力，大大减少了不必要的重复建设，具体架构图这里就不详细展开了。

7. 

滴滴Node指南

除了实质的基础生态之外，在提升认知和体系化能力方面，我们建设了滴滴Node指南，结合FT各团队多年的历史沉淀和内外部的一些最佳实践，形成一套覆盖开发前、中、后的各大核心知识体系。目的就是为了让开发者能够更轻松的从0到1搭建一个服务，并且体系性的了解一个服务的各个生命周期都应该干什么，如何学习Node、如何搭建服务、如何编译部署服务、如何运维服务、各种类别最佳实践以及如何保障服务的性能和稳定性等，从而为业务提供稳健的服务能力。目前这套指南正在完善中。

8. 

落地情况

在我们的NodeX生态不断建设和推广传播下，令人感到兴奋的是，滴滴内越来越多的团队都在用node做着各种提效降本和业务赋能的尝试，其中不乏有C端业务诸如短域名服务、动态配置服务、埋点服务等，还有一系列中后台服务。未来我们也会将基础能力沉淀到Serverless，提供夯实的基础能力，同时也会沉淀各种类别使用场景解决方案，诸如BFF、SSR、微前端等，帮助开发者快速解决问题。

目前NodeX生态在滴滴内部安装量已突破20W+，服务接入量也达200+，覆盖了滴滴内绝大部分部门。当然上面统计的只是组件和框架的数据，体系内还有通用服务和研发支撑平台接入量也非常可观。整个生态大大提升了研发效率和自闭环能力，帮助越来越复杂的业务快速发展。

9. 

总结

我们建立 NodeX 体系，是希望能够汇聚滴滴更多的泛前端团队，能够联动起来学习、沉淀、探索、建设、和分享大家历史沉淀的解决方案，服务滴滴的同时也能回馈外部社区，共同建设一个好的Node生态。

本文作者

▬

团队招聘

▬

NodeX FT致力于建设滴滴Node生态，同时我们也有丰富的业务场景（两轮车、代驾、货运等）和其他技术建设（Dokit、Hummer、 Chameleon等），涵盖了跨终端、跨服务端、动效、可视化搭建、serverless等各个场景，欢迎感兴趣的同学加入我们，简历投递至

[email protected]om。

扫码了解更多岗位

延伸阅读

▬

内容编辑 | Mango

联系我们 | [email protected]

本文分享自微信公众号 - 滴滴技术（didi_tech）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。