Skip to content

Elpis 里程碑 1 总结

1. 项目介绍

Elpis 是一个基于 Koa 的轻量级服务端项目。它通过约定优于配置的方式,实现自动加载模块、自动注册路由等功能。同时,项目也通过分层的方式来组织业务代码,把框架层和业务层分开,方便后续扩展和维护。

2. 本阶段完成内容

2.1 项目启动和基础框架搭建

项目通过入口文件启动服务,再由 elpis-core 统一完成 Koa 实例创建、配置加载、业务模块装配以及路由注册等工作。

2.2 完成模块自动加载机制

项目启动的时候,会自动去扫描 configextendmiddlewareservicecontrollerrouter-schemarouter 这些目录,把对应模块挂载到应用实例上。可以减少手动注册代码,同时让整个项目结构保持统一。

按照以下顺序加载模块:

  1. config:加载配置文件,提供全局配置支持。
  2. extend:加载扩展模块,提供一些全局可用的工具函数。
  3. middleware:加载中间件模块。
  4. service:加载业务逻辑模块。
  5. controller:加载控制器模块。
  6. router-schema:加载接口参数校验规则,为后续接口校验提供依据。
  7. router:加载路由注册模块,完成接口和页面路由的注册。

这样安排加载顺序,主要是为了保证在路由真正生效之前,配置、扩展能力、业务模块和中间件都已经准备好,避免因为模块还没加载完成就被调用而出现问题。

2.3 完成基础业务分层

按照常见的分层方式,项目把业务代码分成了 controller、service、middleware 和 router 几部分。controller 负责处理请求和响应,service 负责具体的业务逻辑,middleware 负责参数校验、签名校验和异常处理这类通用逻辑,router 负责把请求路径和控制器方法对应起来。

这样分层之后,每一部分负责的内容会更清楚,也不容易把很多逻辑都堆在同一个地方。后面如果要继续加功能或者排查问题,也会更方便一些。

2.4 完成基础中间件能力

项目中加入了参数校验、签名校验和异常处理这些基础中间件,用来统一处理接口请求中的通用逻辑。这样可以减少业务代码里的重复判断,让 controller 和 service 更专注于核心逻辑。这里要注意的是koa实例本身不提供params解析能力,params属于路由层在请求匹配阶段对cxt进行的扩展,所以参数校验的中间件需要在路由中间件执行之后才能正常获取到对应params参数。

2.5 跑通基础接口和页面渲染流程

当前项目已经实现了基础接口和页面渲染功能。接口部分验证了从路由到 controller 再到 service 的调用流程,页面部分验证了从路由到 controller 再到模板渲染的流程。