『大吉大利，明早吃蛋。』
底部有文化衫活动邀您参加。
知乎原文地址：https://zhuanlan.zhihu.com/p/45143762
2016 年 9 月，我们在 JSConf China 2016 上宣布了 Egg 开源，至今整整 2 年了。 在 Egg 2.0 发布通告 提到，核心代码已经很稳定，后续重心主要在开发者体验方面的优化。
Egg 是阿里 Node.js 的核心基础框架，面向『企业级的 Web 基础框架』这个领域，提供了「微内核 + 插件机制 + 框架定制能力」，完美达成生态共建和差异化定制的平衡点。
既适合个人小项目快速开发，也适合团队架构师基于自身的技术架构在 Egg 基础上扩展出适合特定团队业务场景的框架。
它沉淀自阿里在各行各业不同领域的大规模工程实践经验，稳定支撑了多年天猫双11大促，顶级流量压力。
接下来跟大家分享下，过去 9 个月里面，我们的一些产出和数据，本文较长，请慢慢品用：
- 开发者数据分享
- 文化衫活动邀请
- 开发者体验优化
- TypeScript 的支持
- 新增「生命周期」
- Alinode 接入指南
- 和 Java 的互联互通方案
- 实践案例 - 用 Egg 重构的 cnode 社区
- 来自语雀团队的 sequelize ORM 实践分享
- 与 Webpack 等前端工程的实践分享
- 错误处理和 opentracing 的 RFC
- egg-init 骨架重构方案
- 未来规划
开发者数据
- 官网 PV 在 1.2w 左右。
- npm egg 模块数 1006 个，GitHub 依赖库 3738 个。
- 一千多个 Pull Request，2200 个 Issue，130 多位 Contributors 。
- 共发布了 81 个版本，Release Note 。
- 社区实践项目：cnodejs/egg-cnode ，eggjs/awesome-egg 。
- 知乎专栏 Node.js 一共发布了 48 篇文章，7600 订阅，阅读数据未知（知乎创作者中心看不上咱，不给内测资格 😭）。
正在使用 Egg 的公司，不完全统计：
- 深度使用的： 阿里巴巴，全民直播，网易考拉
- 使用并有分享过使用经验的：去哪儿，摩拜，点评
- 有个别团队咨询过试水但最终有没有落地的不知道：美团，新浪，百度，腾讯，YY 等
顺便分享一个 cnpm 的统计数据：
文化衫活动
欢迎大家访问以下链接，分享你们的实践经验，有机会获得 Egg 文化衫和相关周边喔~ 另外，第 10000 Star 的同学 godmeir 请联系我们。
『2018 年 EggJS 怎么样了？对它的看法有什么变化？』
开发者体验优化
接下来跟大家分享下这段时间来，我们在『开发者体验』方面做的一些优化。
TypeScript
这几年来 TypeScript 很受欢迎，它的静态类型检查，智能提示，IDE 友好性等特性，对于大规模企业级应用，是非常的有价值的，被视为是企业级 JS 开发的未来之一。
阿里内部实践 TS 也蛮久了，在 5 个月前，也把我们的其中一部分成熟的实践，分享出来： 『天猪：当 Egg 遇到 TypeScript，收获茶叶蛋一枚』
非常感谢 @吖猩 在这领域的持续贡献：
这块目前还在持续优化中，有兴趣的同学可以参与以下几项优化：
- egg-ts-helper 增加对 js 的支持，这样非 ts 的同学，也能享受到智能提示和静态检查的 Buffer 加成。
- 完善插件自带的 d.ts 方便其他开发者。
- 分享你的上层封装，如通过装饰器来注册路由或 AOP。（内部有不少实践，但还未达成共识）
PS： Egg.js 本身不会使用 TypeScript 重写，对于框架本身而言，JS 的灵活性可以让它更容易实现一些特性，同时它也并没有那么复杂的业务逻辑，TypeScript 并无法给框架研发带来更多的帮助。
生命周期
之前 Egg 提供给开发者在启动期的钩子不多，只有 beforeStart 几个。 感谢 killagu 同学给我们补充了更细致的生命周期，相关的 RFC 和文档如下：
- [RFC] egg-core 增加应用启动阶段 · Issue #2520
- Egg 文档 - 生命周期 （目前文档还有较大的优化空间，我们将在后续继续完善。）
// app.js
class AppBootHook {
configDidLoad() {
// Config, Plugin files have did load.
}
async didLoad() {
// All files have did load, start plugin here.
}
async willReady() {
// All plugins have started, can do some thing before app ready.
}
async didReady() {
// Worker is ready, can do some things don't need to block the app boot.
}
async serverDidReady() {
// Server is listening.
}
async beforeClose() {
// Do some thing before app close.
}
}
Alinode
Node 发展到今天，已经被越来越广泛地应用到前后端分离、全栈开发、客户端工具等领域。 然而，相对于应用层的蓬勃发展，其 Runtime 对于绝大部分前端出身的开发者来说，处于黑盒的状态，这一点并没有得到很好的改善，从而也阻碍了 Node.js 在业务中的应用和推广。
作为一个 Node 开发者，最头痛的事莫过于莫名其妙的 CPU 100% 和内存泄露导致的 OOM。
所幸的是，阿里云 @朴灵 团队的 Node.js 性能平台 为 Node 开发者提供了：性能监控、安全提醒、故障排查、性能优化 等服务的整体性解决方案，提供完善的工具链和服务，协助开发者快速发现和定位线上问题。这些年来，为我们解决了非常多的线上问题，为业务保驾护航。
相关分享：
当然，在日常的答疑中，很多同学也表达了对数据安全方面的担忧。从我个人的角度来看，Alinode 的采集脚本，都是开源了，不会采集隐私数据。实在不行，在压测期接入用用也行，绝对可以让我们少掉一点头发，良心推荐。
和 Java 互联互通的方案
Node.js 在蚂蚁和阿里已经发展了四、五年时间，从最开始「前端工程师的玩具」，到 Web、BFF 场景的破局，逐步走到线上甚至是一些核心业务，非常不容易。
回头想想 Nodejs 为什么能活下来？依靠的绝不仅仅是：非阻塞I/O、事件驱动、轻量这些官方宣传的特性，我们认为更重要一点是我们打通了和 Java 的桥梁，实现了互联互通，这才让它真正融入阿里的技术体系。
伴随 蚂蚁 SOFA Java 技术栈 的开源，我们也开源了 Nodejs RPC 相关模块，希望能填补 Nodejs 社区这块的空白，也将我们几年来在 Nodejs 基础技术的一些经验做个总结和分享。
推荐阅读小丸子姐姐的相关科普文章：
egg-cnode
朴老师发起的 cnodejs/egg-cnode 项目，用 Egg 重写了 cnode 社区应用。 目前完成了功能层面的重构以及测试用例的补全：
- 文件数减少 41，减少 22%
- 代码行数减少 2460 行，减少 4.7%
- 测试代码减少 980 行，减少 39%，覆盖率高于原项目。
目前还有较大的优化空间，因为第一阶段专注于功能迁移，不做大的优化，有些使用方式不符合 Egg 的最佳实践，欢迎有兴趣的同学加入一起完善。
值得关注的 RFC 和分享
在 eggjs 团队的日常协作中，遵循「基于 GitLab 的硬盘式异步协作模式」。 通过 issue 发起 RFC 提案 -> 讨论定稿-> 提交 Pull Request -> Code Review -> 发布。 这样便于沉淀，即使是当时没有参与讨论的开发者，事后也能通过 issue 了解某个功能设计的前因后果。
Θ 来自 语雀团队 的 ORM 实践分享
- 语雀是基于 Egg 技术栈研发的，算是为数不多的涉及到各个技术点的 Node 大应用。
- Egg 文档 - Sequelize
Θ 与 Webpack 等前端工程的实践分享
- Egg 文档 - Assets 静态资源
- 来自 easywebpack 的实践
- 上层同构框架：alibaba/beidou 和 Serlina
Θ 错误处理 && 问题跟踪
- [RFC] egg-opentracing · Issue #39
- [RFC] 应用自定义 4xx 和 5xx 的方案 · Issue #1086
- [RFC] 统计 egg 加载过程的各步骤的耗时 · Issue #1898
- handle unconsume multipart request data in egg itself. · Issue #2897
Θ 工具优化 目前的 egg-init 存在以下问题：
- 脚手架逻辑集中化，全部在 egg-init 本身，作为全局命令，更新不方便。
- 模板无法定制自己的逻辑，无法代码共享。
- 没有 sub generator，如 egg-init add controller Test 这样的功能。
- 脚手架只在项目初始化时用到，无法支撑升级功能，容易腐化和分裂。
- 上层封装不方便，不支持 preset 。
因此提出了 『[RFC] egg-init refactor 』，应该下个月可以完工并分享给大家。
Θ 科普文 提到 Egg 值得自豪的应该是我们的文档吧，我们深知前端开发者在后端知识面还有很多需要科普的，也很乐意分享我们的实践：
未来规划
老实说没有太多新特性，还是那个原因：Egg 采用的是『微内核 + 插件 + 上层框架』模式。
Egg 自身的迭代采取插件化的开发机制，功能分散在不同的模块中，可能开发者在使用时感知不到它的版本变更，但其实它一直都在进化。每周都可能有新特性和 BugFix 发布，更像是一个『改良派』而不是『改革派』，它会在兼容的前提下不断进化。
接下来的规划，还将继续放在 『开发者体验优化 + 实践经验分享』 方面。
- egg cli 工具链和骨架的重构优化。
- TypeScript 的继续优化，以及增加对 js 项目智能提示方面的支持。
- 更多的实践项目和科普分享。
- 国际化。
仅凭我们自己的精力是远远不够的，欢迎社区的大家一起加入，共同推动 Node 的发展。
写在最后
- 如果你喜欢 Egg，请支持我们：
- 分享本文，为我们点赞。
- 来分享下你们的实践，无论大小，这很重要，谢谢，将有机会获得我们的文化衫。
『2018 年 EggJS 怎么样了？对它的看法有什么变化？』
- 如果喜欢我的文章，请关注 我的知乎 和 Follow GitHub 。
- 广州阿里游戏，招前端，熟悉动效，Node 的速来~
@waitingsong 说句实话，直接在框架层使用这个worker方案，我并不认为是好事。 比如这会让beforeStart行为很奇怪，会让调试的现象更诡异以及架构灵活性会被相对较大的制约。 并不是说框架的worker的技术不好，讲真，主进程fork出agent管理cluster的方案是可以的。但感觉不适合直接打在框架里，我可能更愿意把worker做成更可插拔的功能。
当然egg会有上面的worker方案也必然经过了深思熟虑的，而我可能也只看到了一面
@waitingsong 不对，我的意思是根本不要worker。 我为什么要在框架里面充分利用CPU，我更愿意开4个容器每个设置1核来用，用容器来伸缩。 而且直接在框架中增加，我觉得增加复杂度远大于我性能提升的好处。 你这个回答显然没有说服我，我都不要worker了，为什么还要worker通讯
@zy445566 这你得问问lz了 我认为多容器，也存在对容器（服务）的管理，包括状态监控、任务分发等。这依然需要一个上层的抽象层来实现。而egg不过是集成了而已，并且实现也许比容器方案还简单些。
@zy445566 egg是小而全的框架，追求简洁，所以多任务是自己实现而没采用现成的 pm2。大而全的就是 k8s 那陀拉～ 你也可以设定egg只启动一个 worker （加上master和agent总共3个进程） 然后容器化嘛。
没有银弹，实在不需要，如上说的，一个 worker，一个 agent，一个 master 就好了，没啥资源损耗。
实在要定制，可以自己写个 my-egg-cluster，然后基于 egg-core 继承为自己的一个框架。但缺点就是，生态里面用到 agent 和消息机制的一些插件会挂掉。或者是类似 egg-mock 那样，把 app 和 agent 放到一个进程里面去加载，这样是可以兼容插件。
但问题是，我们的资源利用率需要扣这么一点么？ 一定要把所有目前暂时不需要的，即使不碍事的，也全部要清理掉么？
我们自己业务一般是配置 docker 为 4 个 cpu，启动 4 个 worker。
还有一种场景，不一定准确：
同样是 16 个实例的情况下，如果 agent 里面跟后端建立长连接，如果是 4 worker + 4 docker 就只有 4 条长连接，而 1 worker + 16 docker 是 16 条。
在 Egg 出现的时候，甚至到现在，Docker 也并没有成为每个团队的可选项。
没有银弹，只关乎历史惯性 + 取舍的平衡点。
@atian25 这确实是一个好的解释 我想是因为我这边只站在了纯后端的角度(可能是我这边服务没有Java只有node的缘故)，所以考虑并不周到 但如果要做中间层或服务前端的后端，这确实是必然的需求
@zy445566 对于阿里来说egg应该是BFF首要需求，兼顾后端服务需求，所以是这样的设计。你需求是纯后端服务（那agent估计都不需要了，直接单进程然后容器化）
