深刻koa源码（一）：架构设计

本文来自《心谭博客·深刻koa源码：架构设计》

前端面试、设计模式手册、Webpack4教程、NodeJs实战等更多专题，请来导航页领取食用

全部系列文章都放在了Github。欢迎交流和Star ✿✿ ヽ(°▽°)ノ ✿

最近读了 koa 的源码，理清楚了架构设计与用到的第三方库。本系列将分为 3 篇，分别介绍 koa 的架构设计和 3 个核心库的原理，最终会手动实现一个简易的 koa。

koa 的实现都在仓库的lib目录下，以下图所示，只有 4 个文件：

对于这四个文件，根据用途和封装逻辑，能够分为 3 类：req 和 res，上下文以及 application。

req 和 res

对应的文件是：request.js 和 response.js。分别表明着客户端请求信息和服务端返回信息。

这两个文件在实现逻辑上彻底一致。对外暴露都是一个对象，对象上的属性都使用了getter或setter来实现读写控制。

上下文

对应的文件是：context.js。存了运行环境的上下文信息，例如cookies。

除此以外，由于request和response都属于上下文信息，因此经过delegate.js库来实现了对request.js和response.js上全部属性的代理。例如如下代码：

/** * Response delegation. */
delegate(proto, "response")
  .method("attachment")
  .method("redirect");

/** * Request delegation. */

delegate(proto, "request")
  .method("acceptsLanguages")
  .method("acceptsEncodings");
复制代码

使用代理的另一个好处就是：更方便的访问 req 和 res 上的属性。好比在开发 koa 应用的时候，能够经过ctx.headers来读取客户端请求的头部信息，不须要写成ctx.res.headers了（这样写没错）。

注意：req 和 res 并非在context.js中被绑定到上下文的，而是在application被绑定到上下文变量ctx中的。缘由是由于每一个请求的 req/res 都不是相同的。

Application

对应的文件是: application.js。这个文件的逻辑是最重要的，它的做用主要是：

• 给用户暴露服务启动接口
• 针对每一个请求，生成新的上下文
• 处理中间件，将其串联

对外暴露接口

使用 koa 时候，咱们常经过listen或者callback来启动服务器：

const app = new Koa();
app.listen(3000); // listen启动
http.createServer(app.callback()).listen(3000); // callback启动
复制代码

这两种启动方法是彻底等价的。由于listen方法内部，就调用了callback，而且将它传给http.createServer。接着看一下callback这个方法主要作了什么：

1. 调用koa-compose将中间件串联起来（下文再讲）。
2. 生成传给http.createServer()的函数，而且返回。

• http.createServer传给函数参数的请求信息和返回信息，都被这个函数拿到了。而且传给createContext方法，生成本次请求的上下文。
• 将生成的上下文传给第 1 步生成的中间件调用链，这就是为何咱们在中间件处理逻辑的时候可以访问ctx

生成新的上下文

这里上下文的方法对应的是createContext方法。这里我以为更像语法糖，是为了让 koa 使用者使用更方便。好比如下这段代码：

// this.request 是 request.js 暴露出来的对象，将其引用保存在context.request中
// 用户能够直接经过 ctx.属性名 来访问对应属性
const request = (context.request = Object.create(this.request));

// 这个req是本次请求信息，是由 http.createServer 传递给回调函数的
context.req = request.req = response.req = req;
复制代码

读到这里，虽然能够解释 ctx.headers 是 ctx.request.headers 的语法糖这类问题。可是感受怪怪的。就以这个例子，ctx.headers 访问的是 ctx.reqeust 上的 headers，而不是本次请求信息上的headers。本次请求信息挂在了ctx.req上。

让咱们再回到reqeust.js的源码，看到了headers的 getter 实现：

get headers() {
  return this.req.headers;
}
复制代码

ok，看来这里的this就是指的上下文环境咯。那么确定是在application.js中某个地方改变了this的指向。果真，在application.js的构造函数中能够看到：

this.request = Object.create(request);
复制代码

application 实例上的 request 被传递给了 context.request，此时 this 天然指向了 context。

能够看到，koa 为了让开发者使用方便，在上下文上作了不少工做。

中间件机制

中间件的设计是 koa 最重要的部分，实现上用到了koa-compose库来串联中间件，造成“洋葱模型”。关于这个库，放在第二篇关于 koa 核心库的介绍中说明。

application 中处理中间件的函数是use和handleRequest：

• use函数：传入async/await函数，并将其放入 application 实例上的middleware数组中。若是传入是 generator，会调用koa-conver库将其转化为async/await函数。
• handleRequest(ctx, fnMiddleware)函数：传入的fnMiddleware是已经串联好的中间件，函数所作的工做就是再其后再添加一个返回给客户端的函数和错误处理函数。返回给客户端的函数其实就是respond函数，里面经过调用res.end()来向客户端返回信息，整个流程就走完了。