专访死马：为什么说Egg.js是企业级Node框架

60 阅读 0 评论 40 点赞

我是靠谱客的博主刻苦小懒猪，最近开发中收集的这篇文章主要介绍专访死马：为什么说Egg.js是企业级Node框架，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

在 7 月 6 日的 ArchSummit 架构师峰会深圳站上，Egg.js 的主要开发者不四（网名死马）将给参会者带来《企业级 Node.js Web 框架研发与落地》的分享，借此机会，我们对他进行采访，询问了他对这个问题的看法。

InfoQ：目前 Egg.js 在阿里内部使用的程度如何，有哪些使用场景？

死马：阿里和蚂蚁内部在开源的 Egg.js 基础上封装了一个内部的框架，不同的子公司在此内部框架的基础上二次封装符合自身业务的框架。内部已经有超过 20 个 Egg.js 的上层框架，服务于十多个子公司，包括蚂蚁、天猫、阿里游戏、河马、阿里云等。线上运行了数百个基于 Egg.js 的应用。

不同的业务会将 Egg.js 用在不同的场景，分类下来看主要是以下几类：

\t
BFF 层：做业务的前后端之间的中间层，用于更清晰的划分前后端工作职责，提升研发效率。
\t\t
\t
全栈：许多创新性业务和内部系统会通过 Egg.js 完成全栈应用研发，蚂蚁近期推出的语雀就是基于 Egg.js 全栈开发的。
\t\t
\t
SSR：部分业务需要通过服务端渲染来提升用户体验，有 Egg.js 的上层框架专注于服务端渲染同构解决方案。
\t

InfoQ：为什么说 Egg.js 是阿里和蚂蚁合作维护的，双方是如何协作的？

死马：Egg.js 最开始脱胎于蚂蚁金服的内部 Node.js 框架 Chair，为了更好的服务于蚂蚁和阿里全集团的业务线，双方合作将 Chair 底层的核心抽离出来后开源，所以它是阿里和蚂蚁以虚拟工作组的方式合作推出的。

而到现在，Egg.js 已经是一个很成熟的开源项目了，不仅仅有来自阿里和蚂蚁内部的开发者，还有许多的外部开发者一起帮忙维护。可以看到 Egg.js 主仓库已经有超过 100 个贡献者了。整个的协作流程以异步交流为主，所有的大的新功能都会在 Github 上开 issue 进行讨论，而代码变更都会由多方 review 后再合并。

InfoQ：之前 Node.js 在做企业级 Web 开发时有哪些缺陷，Egg.js 做了哪些工作？

死马：不能说 node 在做企业级 Web 开发时有缺陷，而是没有规范。企业项目和个人项目有许多不同之处：参与的人员会很多，项目的维护者也经常变更有非常多内部系统需要对接，特别像阿里、蚂蚁这个规模的公司，内部都维护了许多自己的中间件服务和定制化的 RPC 通信框架对稳定性、性能、Bug 追踪等方面的要求会更高Egg.js 为了解决这个问题，主要是从定制规范和给团队架构师更大的灵活性两方面入手，同时也从我们内部的日常开发中提取了许多经验集成到框架中。

相较于 koa/express 来说，Egg.js 首先约定了一套代码目录结构，清晰的定义了从配置、路由、扩展、中间件到控制器、定时任务等各个 Web 应用研发过程中一些最基础的概念，这样不同团队的开发者使用框架写出来的代码风格会更一致，接手老项目的上手成本也会更低。

同时 Egg.js 通过插件机制，让团队架构师可以更轻松的整合企业内部服务，定制一个企业内部的框架，通过定制化的框架来统一输出一个技术栈，业务开发人员可以不去了解细节，即可接入企业的研发流程、内部服务、监控体系。

Egg.js 不仅仅提供运行时的框架，同时也在测试方面提供了很多支持。包括测试执行框架、请求库、mock 方式等都有提供，可以从 Egg.js 的单元测试文档可以看出来我们是很认真的对待这件事情的，提升应用稳定性没有捷径。

InfoQ：既然 Egg.js 以企业级开发为目标，有没有计划推出 LTS 版本？

死马：Egg.js 最近发布了 2.0，而其实我们内部还有大量的应用都还是运行在 1.0 的版本上的，因此我们仍然会同时维护 1.0 和 2.0 两个版本。后续的计划中，我们起码会保证最近两个大版本的维护。

InfoQ：由于 JS 社区活跃，Node 框架的依赖一般又很多，版本更迭带来的代码腐化速度特别快，阿里内部是如何面对这一问题的？

死马：随着 yarn 的诞生和 npm 5 的跟进，其实整个 js 社区对待依赖这件事情的看法都在慢慢在向着锁版本倾斜的。但是锁版本在我们看来是一个治标不治本的方案，虽然看起来更稳定，但是业务繁忙起来没有人会愿意去升级依赖，导致一段时间后应用的依赖无法升级，许多新特性和隐藏的 Bug 无法被修复。

而在阿里和蚂蚁内部的 Node 实践方式来看，绝大多数复杂的功能都是由底层框架提供的，底层框架经常会有大量的新特性引入和 Bug 修复，特别是一些安全性问题非常紧急，一旦版本被应用开发者锁定，就会导致线上服务出现安全风险。所以阿里和蚂蚁内部的实践是遵循 Semver 风格的依赖引用，不锁定版本。

当然不锁版本也有它的问题，总会有模块不小心发布出了问题，所以我们内部针对这个场景有不少的优化：

\t
阿里和蚂蚁内部使用自建的 npm registry 和自研的 npm 安装模块机制，可以完全掌控所有模块，当一个底层模块出现问题时，可以快速进行版本回退。
\t\t
\t
通过控制研发流程，保证线上发布的代码包和测试用的代码包是同一个，避免线上运行的代码使用的依赖和测试时不一致。
\t\t
\t
Node 服务绝大部分复杂的逻辑都封装在底层框架中，由框架研发团队来确保兼容性。
\t

InfoQ：TypeScript 被认为是企业级 JS 开发的标准，最近 Egg.js 支持了 TypeScript，本身有没有使用 TypeScript 重写的计划？

死马：Egg.js 本身不会使用 TypeScript 重写，对于框架本身而言，JS 的灵活性可以让它更容易实现一些特性，同时它也并没有那么复杂的业务逻辑，TypeScript 并无法给框架研发带来更多的帮助。

InfoQ：Egg.js 团队有没有计划推出一个官方的应用项目作为模板展示？

死马：近期朴灵发起了一个 egg-cnode 项目，使用 Egg.js 重写了 cnode 社区。

InfoQ：在国内做企业级框架有没有考虑过商业化的问题？

死马：Egg.js 暂时并没有考虑商业化的问题，毕竟框架的维护成员仍然要花大量精力在公司业务上。当然这也不意味着 Egg.js 维护力度会下降，它是阿里和蚂蚁内部数百个应用的基石。

InfoQ：Egg.js 的发版频率和 roadmap 是怎样的？

死马：Egg.js 的核心其实是很精简的，而且由于其直接服务于内部应用，所以对它的兼容性要求是非常高的，从 Egg.js 开源以来，只发布了两个大版本，Egg.js 1 基于 Koa 1，底层使用 co 来解决异步问题，Egg.js 2 基于 Koa 2，底层切换到 Async Await，即便是这种升级，应用层也是可以无感知直接切换的。

Egg.js 自身的迭代采取插件化的开发机制，功能分散在不同的模块中，可能开发者在使用 Egg.js 的时候感知不到它的版本变更，但其实它一直都在进化。每周都可能有新的特性和 Bug fix 发布，Egg.js 更像是一个『改良派』而不是『改革派』，它会在兼容的前提下不断进化。

InfoQ：如何保证 Egg.js 的持续维护？

死马：首先，Egg.js 的核心维护者都是 node 社区的重度用户，除非这群人都不再当程序员，否则都会投入精力在其中继续维护它。其次，阿里和蚂蚁内部有数百个应用依赖于 Egg.js，从公司层面上来说也是愿意持续投入人力来维护它。现在 Egg.js 的运作也是完全社区化方式，讨论和代码变更都是基于 Github，有超过 100 位来自社区的贡献者，活跃度还是很高的。

---

除不四的分享之外，全球架构师峰会 Node.js 专场还有下述分享等待大家现场交流探讨：