Egg体系导读
概述
Egg框架是公司在2016年推出的企业级的应用框架，开源的Egg现在已经到2.8.1版本了。Egg的文档现在已经很完善了，网上和ata上也很多教程，但是剖析Egg源码的文章较少，于是想整理下源码的逻辑。
首先来看看，我们装了一个最简单的应用，node_module会给我们装哪些egg库。
这些Egg库构成了一个基础的egg体系，我把这些库分为两个种类。
- Egg核心 --- 上图圈出来的库
- Egg主要插件/中间件
Egg核心
核心体系 --- egg-core
- 整合koa
- Loader机制
辅助体系
- 多线程利用 egg-cluster
- egg-script(部署), egg-bin(开发)
- 脚手架 egg-init
- 环境区分
- 辅助开发 egg-bin
| 库名 | 功能 |
|---|---|
| egg | 封装各方库提供给外部使用 |
| egg-core | 整合koa和提供Loader机制 |
| egg-cluster | 为框架提供多进程能力 |
| egg-bin | 为框架提供强大的调试能力 |
| egg-script | 为框架提供部署到生产环境的能力 |
Egg主要插件体系
| 库名 | 功能 |
|---|---|
| egg-session | 提供关联应用session的能力 |
| egg-security | 提供多种场景安全的防范，xframe，crsf，xss等 |
| egg-schedule | 为框架提供运行定时脚本的能力 |
| egg-multipart | 提供文件上传能力，无需关心需要暂存本地 |
| egg-static | 为框架提供静态资源的访问能力 |
| egg-view | 为框架添加模板渲染的能力 |
进行源代码调试
- 所有不经过调试的读源代码都是耍流氓
前置工作
需要建好一个空的egg项目，不再赘述了
> egg-init egg-basic-learn --type=simple && cd egg-basic-learn
> npm i进行调试
说到Egg调试，有的同学可能想到了使用egg框架的egg-bin debug，但这没办法调试到源码级别的，只能对业务代码进行调试，所以需要借用node --inspect-brk方式了。
在根目录新建一个index.js文件
egg-basic-learn/index.js
---
'use strict'
const egg = require('egg');
egg.startCluster({}, () => {
console.log('started');
});
运行node --inspect-brk
> node --inspect-brk index.js
Debugger listening on ws://127.0.0.1:9229/ce6baa2f-8713-4740-bf40-aa21ae5466cc
For help see https://nodejs.org/en/docs/inspector打开Chrome开发者调试工具，点击下图按钮，就可以进入调试台了。
Egg源码导读
源码导读分为下面两个部分进行讲解。导读只涉及到各模块的功能，暂不贴源代码与路径(实在是不好贴。。)
- 框架启动剖析。
- Work处理一个网络请求。
Egg启动代码剖析
Egg框架的启动是在egg-cluster库文件中处理的。egg-cluster库是让egg区别于
egg-cluster大概干了这么几件事
- 初始化master(master进程和启动的node进程为同一进程)，启动agent进程
- agent初始化成功后，通过IPC通道通知master
- master根据CPU的个数启动相同数目的worker进程
- worker进程初始化成功后，通过IPC通道通知master
- 所有的进程初始化成功后，master通知agent和各个worker进程应用启动成功
master，agent和worker之间的通讯如下图所示，master和worker，master和agent是直接通过message模块进行通讯(底层调用的是subprocess.send方法)。agent和worker之间不能直接通讯，需要master进行中转。
下面我们会详细讲解下Agent的启动和Worker的启动，在这之前，我们先看下Egg框架的一个核心机制 --- Loader机制，也是Egg框架号称“约定优于配置“的实现。
Egg将应用，框架和插件都称为加载单元(loadUnit)。加载过程中Egg会遍历所有的loadUnit加载相应文件(应用，框架，插件各有不同)，加载时有一定的优先级。Loader的核心代码存在@egg-core/lib/loader/中，分为上下文(应用)loader，框架loader和文件loader。
- 按插件 => 框架 => 应用依次加载。
- 插件之间的顺序由依赖关系决定，被依赖方先加载，无依赖按object key配置顺序加载。
- 框架按继承顺序加载，越底层越先加载。
下面我们以加载plugin为例，看下代码里是怎么实现的
egg-core/lib/loader/mixin/plugin.js
---
/**
1. 分别从应用，框架层还有环境变量中合并插件配置，得到allPlugins变量
2. 调用getOrderPlugins方法，解析插件直接的加载顺序，被依赖方先加载
**/
loadPlugin() {
//合并插件配置
const appPlugins = this.readPluginConfigs(path.join(this.options.baseDir, 'config/plugin.default'));
const eggPlugins = this.readPluginConfigs(eggPluginConfigPaths);
this.normalizePluginConfig(customPlugins, name);
//三者合并得到allPlugins配置
for (const name in this.allPlugins) {
const plugin = this.allPlugins[name];if (plugin.enable) {
enabledPluginNames.push(name);
}
}
//调用getOrderPlugins方法，解析插件直接的加载顺序
this.orderPlugins = this.getOrderPlugins(plugins, enabledPluginNames, appPlugins);
}
/* 根据配置文件和服务器的运行环境，找到插件的绝对路径，解出形如下面的插件配置 */
readPluginConfigs() {
plugin.name = name;
plugin.dependencies = plugin.dependencies || [];
plugin.optionalDependencies = plugin.optionalDependencies || [];
plugin.env = plugin.env || [];
plugin.from = configPath;
depCompatible(plugin);
}
getOrderPlugins() {
//使用requireMap对象来判断依赖关系
}
插件配置加载完成之后，egg_loader.js文件中调用loadToApp()方法，调起文件loader的load()方式，把插件加载到内存。
Agent启动
Agent进程在Egg框架中的定位是“小秘”，它不对外提供服务，只给 App Worker 打工。源码实现在@egg/lib/agent.js中。主要实现了做了两步操作。
- 使用AgentLoader加载插件和配置，即上一步loader做的工作。
- 保持心跳(调用setInterval方式)。
Work启动
Work进程顾名思义就是干活的『工人』。它们接收请求，对外提供服务。启动代码在@egg-cluster/app_worker.js中。代码主要逻辑有下面几部。
- 实例化egg.Application类为app变量。
- 启动startServer方法，使用app监听调用。
egg.Application即eggCore继承于KoaApplication，下面讲解下框架里两个重要的概念，controller和Router。
controller的实现在@egg-core/lib/utils/base_context_class.js，代码很简单，这也可以说明了为什么可以在代码里直接使用this.app，this.service。
egg-core/lib/utils/base_context_class.js
---
class BaseContextClass {
/**
* @constructor
* @param {Context} ctx - context instance
* @since 1.0.0
*/
constructor(ctx) {
/**
* @member {Context} BaseContextClass#ctx
* @since 1.0.0
*/
this.ctx = ctx;
/**
* @member {Application} BaseContextClass#app
* @since 1.0.0
*/
this.app = ctx.app;
/**
* @member {Config} BaseContextClass#config
* @since 1.0.0
*/
this.config = ctx.app.config;
/**
* @member {Service} BaseContextClass#service
* @since 1.0.0
*/
this.service = ctx.service;
}
}
Router的实现基于koa-router添加了一些更加方便的路由定义方式。结构大致入下。
egg-core/lib/utils/router.js
---
class Router extends KoaRouter {
register() {}
resources() {}
url() {}
...
}
小结
整个egg的源码读下来，感受最深的还是框架在为成为企业级框架这一愿景做了很多事情。虽然是基于Koa框架的封装，但是多进程的应用，成熟的Loader机制，Application，controller，router封装了更多的方便使用的方法。结合koa社区和egg社区的强大中间件和插件的支持，egg的明天会越来越好。
