Linuxeden开源社区作者
在 7 月 6 日的 ArchSummit 架构师峰会深圳站上，Egg.js 的主要开发者不四（网名死马）将给参会者带来《企业级 Node.js Web 框架研发与落地》的分享，借此机会，我们对他进行采访，询问了他对这个问题的看法。
InfoQ：目前 Egg.js 在阿里内部使用的程度如何，有哪些使用场景？
死马：阿里和蚂蚁内部在开源的 Egg.js 基础上封装了一个内部的框架，不同的子公司在此内部框架的基础上二次封装符合自身业务的框架。内部已经有超过 20 个 Egg.js 的上层框架，服务于十多个子公司，包括蚂蚁、天猫、阿里游戏、河马、阿里云等。线上运行了数百个基于 Egg.js 的应用。
不同的业务会将 Egg.js 用在不同的场景，分类下来看主要是以下几类：
- BFF 层：做业务的前后端之间的中间层，用于更清晰的划分前后端工作职责，提升研发效率。
- 全栈：许多创新性业务和内部系统会通过 Egg.js 完成全栈应用研发，蚂蚁近期推出的语雀就是基于 Egg.js 全栈开发的。
- SSR：部分业务需要通过服务端渲染来提升用户体验，有 Egg.js 的上层框架专注于服务端渲染同构解决方案。
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 风格的依赖引用，不锁定版本。
当然不锁版本也有它的问题，总会有模块不小心发布出了问题，所以我们内部针对这个场景有不少的优化：
- 阿里和蚂蚁内部使用自建的 npm registry 和自研的 npm 安装模块机制，可以完全掌控所有模块，当一个底层模块出现问题时，可以快速进行版本回退。
- 通过控制研发流程，保证线上发布的代码包和测试用的代码包是同一个，避免线上运行的代码使用的依赖和测试时不一致。
- Node 服务绝大部分复杂的逻辑都封装在底层框架中，由框架研发团队来确保兼容性。
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 专场还有下述分享等待大家现场交流探讨：
转自 http://www.infoq.com/cn/news/2018/05/eggjs