egg.js设计思路

理想的企业级Web开发模型

1. 错误处理(优雅的退出)
2. 多进程管理(egg-cluster)
3. 编程模型的约束(egg-loader)
4. 安全(egg-security)
5. 丰富的扩展点(plugin)
   ....

编程模型规范

├── package.json
├── app.js (可选)
├── agent.js (可选)
├── app
|   ├── router.js（路由）
│   ├── controller（控制器）
│   |   └── home.js
│   ├── service (业务逻辑)
│   |   └── user.js
│   ├── public (静态资源)
│   |   └── reset.css
│   ├── view (模板)
│   |   └── home.tpl
├── config（配置）
|   ├── plugin.js
|   ├── config.default.js
│   ├── config.prod.js
└── test（单元测试）
    ├── middleware
    |   └── response_time.test.js
    └── controller
        └── home.test.js

约定优于配置,通过loader进行挂载

插件机制

如果仅仅是提供一套规范,那么其实没有太多技术含量,也很容易做到。
koa的middleware是处理请求相关的,但是不太适合用于承载扩展的职责。还有些和请求无关的。比如:日志切割,定时任务等。不适合用middleware来承载。
插件可以作为框架 的渐进式的演变。

进程管理

              +--------+          +-------+
                | Master |<-------->| Agent |
                +--------+          +-------+
                ^   ^    ^
               /    |     \
             /      |       \
           /        |         \
         v          v          v
+----------+   +----------+   +----------+
| Worker 1 |   | Worker 2 |   | Worker 3 |
+----------+   +----------+   +----------+

为什么不使用PM2等进程管理工具? 还多了一个agent的进程

• agent进程只有一个(worker进程有多个),负责脏活累活。
• 不对外进行服务，专门处理公共事务
• 如: 定时日志切割，公共资源访问，后端长连接等

渐进式的开发思路

应用内部的业务逻辑 ->沉淀应用内部插件-> 独立出插件系统->插件集规范->沉淀到框架
希望做到

• 对业务开发者提供强约束,提高研发效率。(目录规范)

• 对架构团队提供灵活的定制能力。(插件能力)
  大概来看一张全景图:

  
  image.png