1. 简单的骨架认知
2. 插件使用(Plugins)
3. 持久层方案(egg-sequelize)
4. Worker 和 高效负载均衡
5. Agent 代理角色

5-1. Master（进程守护）
5-2. Agent （代理进程）
5-3. 自定义 Agent
5-4. 进程之间通讯

6. 定时任务

笔者的其他文章推荐： 《JS 函数式编程思维简述》

前言

       Worker 作为 Egg 中应用的一个具体实例，有效的解决了 nodejs 应用对 CPU 利用率不足的问题。在生产环境中，每一个 APP 都相当于是一个 Worker，他的表现大致如下：

image

Master（进程守护）

       在这个多进程模型中，角色们都在履行着自己的职责。其中，Master 作为一个BOSS，主要负责启动或重启其他进程，以及负责进程之间的数据交互。
       这样的设计结构中，我们创建了一组进程集群（cluster），并且共用一个端口号，由 Master 捕获请求参数，通过一定的负载均衡规则分发给被选中的 Worker，由 Worker 进行详细的业务处理。不过这里还有一个问题：每一个进程开启了一个web服务，那么进程端口号不会冲突吗？
       在使用 node.js 的 cluster 模块 fork 子进程时，它会保证当前需要的端口仅由master进程内部的TCP服务器监听一次，而在创建子进程的过程中，重复监听的方法就会被干掉，因此也不会引发端口占用等问题。
       而当某一个 Worker 在遇到未捕获的异常需要挂掉时，Master 则会首先再 fork 一个子进程，以保证运行过程中的 Worker 总数不变。然后待之前发生异常的 Worker 处理完当前手中的事务时，让其安心的成佛。

Agent （代理进程）

       在这个多进程模型中，还可能产生这样一个问题：假设当前应用中有一个模块，需要每30分钟获取一次来自第三方接口的天气数据。对于集群中的所有应用而言，这样的数据实际上获取一次作为缓存即可，但在实际应用中，数据请求的次数却是 1n (worker进程数) 次。
       我们能发现，在业务处理的过程中，会有一些依赖于每一个独立请求的业务处理过程，然而，也存在着一些并非强依赖某一个请求的业务。于是，Egg 提供了一个专门用于处理公共事务的独立进程——Agent*，来处理此类业务：

image

进程启动顺序：

1. Master 启动后先 fork Agent 进程；
2. Agent 初始化成功后，通过 IPC 通道通知 Master；
3. Master 再 fork 多个 App Worker；
4. App Worker 初始化成功，通知 Master；
5. 所有的进程初始化成功后，Master 通知 Agent 和 Worker 应用启动成功；

自定义 Agent

我们可以在项目的根目录下创建自己的 agent.ts ，来实现自己的 Agent 逻辑：

// agent.ts
export default (agent) => {
    // 在这里写初始化逻辑
    // ...

    // 也可以通过 messenger 对象发送消息给 App Worker
    // 但需要等待 App Worker 启动成功后才能发送，不然很可能丢失
    agent.messenger.on('egg-ready', () => {
        const data = { ... };
        agent.messenger.sendToApp('xxx_action', data);
    });
};

而在项目根目录中的 app.ts 中，我们可以以监听事件的方式，接收 触发事件者 发送的参数：

// agent.ts
export default (app) => {
    app.messenger.on('xxx_action', data => {
        // worker 进程中监听消息传达事件并进行处理
    });
};

进程之间通讯

进程之间的通讯主要分为以下几种：

• Master -> Worker/Agent
• Worker -> Agent
• Agent -> Worker
• Worker -> Other Worker

发送消息

接收消息

这是官方的一个 IPC + 定时任务 完成的示例：https://eggjs.org/zh-cn/core/cluster-and-ipc.html#ipc-实战