基于Koa实现服务端内核引擎

前言：内容来源于抖音哲玄前端 大佬的《大前端全栈实践》课程

架构设计

• 奉行“约定优于配置”。按照一套统一的约定开发应用，未有约定的团队，沟通成本极高，因为每个人的开发习惯可能都不同。
• 采用单例模式的设计理念，通过编写 loader 解析器，将不同模块下的文件暴露在 koa 实例下
• 整个服务端内核分为 接入层、业务层、服务层
• 接入层则是为 web 端提供接口路由，在接入层中去调用业务层相关的逻辑
• 业务层中进行服务端的业务逻辑处理，最后再调用服务层
• 服务层中主要负责操作数据

项目结构

elpis
  |-- app // 文件目录
  |   |-- controller // 业务逻辑处理
  |   |-- extend // 拓展
  |   |-- middleware // 中间件
  |   |-- public // 静态资源根目录
  |   |-- router // 路由
  |   |-- router-schema // 路由校验规则
  |   |-- service // 数据处理
  |   |-- middlewares.js // 全局中间件
  |-- config // 环境配置文件
  |-- elpis-core // 引擎内核
  |   |-- loader
  |   |   |-- config
  |   |   |-- controller
  |   |   |-- extend
  |   |   |-- middleware
  |   |   |-- router-schema
  |   |   |-- router
  |   |   |-- service
  |   |-- env.js
  |   |-- index.js
  |-- index.js // 入口文件

项目结构分析

• app 下存放的是项目相关的具体业务文件
• elpise-core 下是服务端的内核引擎

内核引擎

• elpise-core通过7个 loader 将app目录下编写的文件全挂载到koa实例中

  • 例如： app/middleware/errorHandler.js --> 经过loader解析后 ---> app.middlewares.errorHandler, app为koa实例

• 相关 loader 解析器

  • configLoader: 配置加载器
  • extendLoader: 扩展功能加载器
  • middlewareLoader: 中间件加载器
  • serviceLoader: 服务加载器
  • controllerLoader: 控制器加载器
  • routerSchemaLoader: 路由模式加载器
  • routerLoader: 路由加载器

• 对于每个 loader 来说，每个app下都会有一个对应的目录，通过 glob 读取到对应的目录下的所有文件，然后通过 loader 将加载的文件挂载到app对象

• loader的加载顺序

  • config -> extendLoader -> service -> routerSchema -> middlewareLoader
  • 原因：
    • config为最基础配置，负责区分 本地/测试/生产 环境读取不同的 env.config
    • extendLoader，中的日志功能属于基础功能，其他loader都可能会用到
    • service，则被controller依赖，优先级同样高
    • middlewareLoader中编写的 验证参数需要 先执行routerSchema