一、项目目标：
在BFF层的搭建一个基于koa.js的服务端内核引擎实现自动化loader机制、可扩展架构、支持中间件组合和服务端渲染能力；完成从页面开发到框架设计的过渡
实现从写接口升级到设计内核，理解请求生命周期、执行时机和分层依赖关系
二、架构设计
1. 核心分层结构
middleware 中间件
router-schema 路由声明
controller 请求控制层
service 业务逻辑层
config 配置层
extend 扩展层
router 路由注册
2. 各层定位
- middleware
中间件，采用洋葱圈模型，实现请求参数校验、异常捕获等功能
洋葱圈模型：
在洋葱圈模型中，每一层相当于一个中间件，用来处理特定的功能，比如错误处理、参数校验等
洋葱圈模型采用先进后出的原则，即会先执行next()处理前的逻辑、在执行next()之后，执行下一个中间件next()之前的逻辑、等到所有中间件的next()之前的逻辑都执行完成之后，倒序执行next()之后的逻辑
在洋葱圈中心所有中间件执行完进入逻辑之后，执行业务逻辑处理，比如：页面渲染、配置获取等
- router-schema
路由声明，将路由信息抽象从结构化声明，定义路由结构、路由方法，接口参数校验规则设定
"/api/query/user/list": {
get: {
headers: {},
query: {
type: "object",
properties: {
key: {
type: "string"
},
value: {
type: "string"
}
},
required: ["key"]
}
body: {},
params: {}
}
post: {}
}
- controller
请求控制层，接收Http请求、调用service处理更原始化的面向数据的处理内容、返回响应
作为业务和http的桥梁，原则上不会写复杂的业务逻辑
- service
业务逻辑层，被controller调用，处理核心业务逻辑，后续调用sql、进行数据获取返回
- config
配置层，不同的配置文件里面是不同环境的配置信息，例如：环境名称定义、超时时间设置等会根据环境变化的数据
基础的信息配置放到default文件中，在进行挂载时根据环境信息覆盖并加载config配置
- extend
扩展层，允许将自定义文件引入到app实例上，增加框架能力，例如：日志打印、工具函数等
- router：
路由注册，根据router-schema动态生成路由，绑定controller和middleware
routes：用于获取所有注册的路由，在调用这个中间件时、会根据请求的路径和方法来匹配路由，并执行相应的路由处理函数
allowedMethods：用于处理HTTP请求中不被当前路由支持的方法。例如，一个POST请求发送到了一个只接受GET请求的路由；如果不被允许，会发送一个 405 Method Not Allowed 响应
prefix：将路径中公共的部分抽离出来；可用于多个环境同时部署、且代码不同的情况，添加前缀来区分不同环境
3.请求执行周期
发送请求 -> middleware中间件进入 -> router.routes()获取路由 -> 路由匹配 -> controller层接收 -> service层处理 -> 返回结果 -> middleware中间件出
