[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_11":-5},"routes/user.$name.replies",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20},"replies",[36,37],"user",{"_21":22,"_13":14,"_23":24,"_25":14,"_26":27,"_28":29,"_30":31,"_32":33,"_34":35},"loginname","Ellacf","page",1,"limit",50,"total",2,"id","21993","avatar_url","https://avatars1.githubusercontent.com/u/10555986?v=3","githubUsername","create_at","2016-04-12 10:43:30.92","score",15,"topic_count",0,"reply_count",3,"is_star",false,{"_21":58,"_39":59,"_41":60,"_42":61,"_44":62,"_46":63,"_48":49,"_50":35,"_32":64,"_51":65,"_26":66,"_54":67},{"_21":38,"_39":40,"_41":-5,"_42":43,"_44":45,"_46":47,"_48":49,"_50":35,"_32":29,"_51":52,"_26":53,"_54":55},"4390","author_id","6617","tab","content","原文地址:[Goodbye node-forever,hello PM2](http://devo.ps/blog/2013/06/26/goodbye-node-forever-hello-pm2.html)\r\n译文地址:[告别node-forever,拥抱PM2](http://se77en.cc/2013/06/27/goodbye-node-forever-hello-pm2-translation/)\r\n\r\n![pm2-logo](http://apps.hemca.com/pm2/pres/pm22.png)\r\n\r\ndevo.ps团队对JavaScript的迷恋已经不是什么秘密了;node.js作为服务器端,AngularJS作为客户端,某种程度上说,我们的堆栈是用它建成的.我们构建[静态客户端和RESTful JSON API](http://devo.ps/blog/2013/01/31/farewell-to-regular-web-development-approaches.html)的方法意味着我们跑了很多的node.js,我必须承认尽管node.js的一切都令人敬畏,但当我们在生产环境中运行它时它仍然会让我们感到头疼.相比一些更加成熟的语言,它的工具和最佳实践仍然缺乏(试想一下:监控,日志,错误处理).\r\n\r\n到目前为止,我们仍然依赖漂亮俏皮的[node-forever模块](https://github.com/nodejitsu/forever).它是非常伟大的模块,不过依然缺失一些功能:\r\n\r\n* 有限的监控和日志功能\r\n* 进程管理配置的支持差\r\n* 不支持集群\r\n* 代码库老化(意味着在升级node.js时频繁的失败)\r\n\r\n这就是为什么我们要在过去的几个月里去写[PM2模块](https://github.com/Unitech/pm2).在我们即将发布针对生产环境的正式版之前我们想先让您看一眼.\r\n\r\n###**PM2到底是什么个东西呢?**\r\n\r\n首先第一件事,你需要先通过`npm`来安装它:\r\n\r\n npm install -g pm2\r\n\r\n让我们通过表格来对比下:\r\n\r\n\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n \r\n

Feature	Forever	PM2
Keep Alive	✔	✔
Coffeescript	✔
Log aggregation		✔
API		✔
Terminal monitoring		✔
Clustering		✔
JSON configuration		✔

\r\n\r\n\r\n现在让我来介绍一点点主要特性...\r\n\r\n###**原生的集群化支持**\r\n\r\nNode v0.6引入了集群特性,允许你在多个Node应用中共享socket.问题在于,它不能在容器外运行而且需要一些额外的配置来处理主进程和子进程.\r\n\r\nPM2原生支持处理这个问题,而且不需要额外的代码:PM2本身作为主进程,然后它将你的代码封装到一个特殊的集群进程里,就像node.js一样,为你的代码文件添加一些全局变量.\r\n\r\n想要启动一个使用所有CPU核心的集群,你只需要键入如下的指令:\r\n\r\n $ pm2 start app.js -i max\r\n\r\n然后:\r\n\r\n $ pm2 list\r\n\r\n然后就会显示类似下面的东西(ASCII UI FTW);\r\n\r\n![pm2-list](http://apps.hemca.com/pm2/pres/pm2-list.png)\r\n\r\n就像你看到的,现在你的应用有多少个进程就取决于你的CPU核心数了\r\n\r\n###**按照termcaps-HTOP(Linux下的系统监控与进程管理软件)的方式管理**\r\n\r\n通过`pm2 list`命令来观察所有运行的进程以及它们的状态已经足够好了.但是怎么来追踪它们的资源消耗呢?别担心,用这个命令:\r\n\r\n $ pm2 monit\r\n\r\n你可以得到进程(以及集群)的CPU的使用率和内存占用.\r\n\r\n![pm2-monit](http://apps.hemca.com/pm2/pres/pm2-monit.png)\r\n\r\n**声明:**[node-usage](https://github.com/arunoda/node-usage)到目前为止还不支持MacOS(随便什么性能要求),不过它在Linux下运行良好.\r\n\r\n现在,让我们来核实一下我们的集群,还有对内存堆栈的垃圾回收,我们假设你已经有一个HTTP基准测试工具(如果没有,你一定要使用[WRK](https://github.com/wg/wrk)):\r\n\r\n $ express bufallo //Create an express app\r\n $ cd bufallo\r\n $ npm install\r\n $ pm2 start app.js -i max\r\n $ wrk -c 100 -d 100 http://localhost:3000/\r\n\r\n在另一个终端,运行监控选项:\r\n\r\n $ pm2 monit\r\n\r\n耶~\r\n\r\n###**实时集中log处理**\r\n\r\n现在你不得不管理多个集群进程:一个爬取数据,一个处理数据,等等...这就意味着大量log,你可以按照老式的方法处理:\r\n\r\n $ tail -f /path/to/log1 /path/to/log2 ...\r\n\r\n但我们想的很周到,我们增加了`logs`功能:\r\n\r\n $ pm2 logs\r\n\r\n\r\n![pm2-logs](http://apps.hemca.com/pm2/pres/pm2-logs.png)\r\n\r\n###**快速恢复**\r\n\r\n现在事情一切顺利,你的进程嗡嗡的运行着,你需要做一次硬重启(hard restart).现在吗?是的,首先,dump掉:\r\n\r\n $ pm2 dump\r\n\r\n然后,你可以从文件中恢复它:\r\n\r\n $ pm2 kill //让我们假设一个PM2停掉了\r\n $ pm2 resurect //我所有的进程又满血满状态复活了\r\n\r\n\r\n###**强健的API**\r\n\r\n比方说,你想要监控所有被PM2管理的进程,而且同时还想监控运行这些进程的机器的状态(甚至希望创建一个Angular应用来调用这些API...):\r\n\r\n $ pm2 web\r\n\r\n打开浏览器输入[http://localhost:9615](http://localhost:9615) ,我嘞个去!\r\n\r\n###**对了,还有很多特性...**\r\n\r\n* 全部测试通过,\r\n* 新一代的`update-rc.d`(`pm2 startup`),当然它还是alpha版,\r\n* 开发模式下更改文件自动重启(`pm2 dev`),也同样还是草稿,\r\n* 自动刷新log,\r\n* 快捷的通过JSON文件管理你的应用,\r\n* 在error log里记录未捕获的异常,\r\n* 记录重启的次数和时间,\r\n* 退出时自动杀死进程.\r\n\r\n##**下一步计划?**\r\n\r\n首先,你可以去[Github上](https://github.com/Unitech/pm2)粉我们(我们喜欢stars).\r\n\r\n我们开发的PM2提供了先进完整的Node进程管理解决方案.我们希望能有更多的人来帮助我们:更多的pull requests.一些还停留在开发路线图上面的功能我们会尽快完成,下面这些就是:\r\n\r\n* 远程管理/状态校验,\r\n* 嵌入式跨进程通信通道(消息总线),\r\n* V8垃圾回收的内存泄漏检查,\r\n* Web界面,\r\n* 监控数据持久化,\r\n* 邮件通知.\r\n\r\n特别感谢[Makara Wang](https://github.com/makara)的观点和工具,还有[Alex Kocharin](https://github.com/rlidwka)提的建议和提交的代码.\r\n\r\n- 在[Twitter](https://twitter.com/intent/tweet?text=[@devo_ps](/user/devo_ps)%20&related=devo_ps&url=http://devo.ps/blog/2013/06/26/goodbye-node-forever-hello-pm2.html)上给我们反馈吧.\r\n- 欢迎在[Hacker News](http://news.ycombinator.com/item?id=5945420)上和我们一起谈论","title","告别node-forever,拥抱PM2[转载]","last_reply_at","2016-05-10 01:50:01.422","good",true,"top","visit_count",24041,"2013-07-31 07:48:33.154","author",{"_13":56,"_23":57},"se77en","http://www.gravatar.com/avatar/ac91e951c9a08f0209028162d5809b2a?size=48","16670","14201","share","# koa\r\n\r\n转载：原文来自 https://github.com/berwin/Blog/issues/8\r\n\r\n学习koa需要一些相关知识，有两个关键词\r\n\r\n* generator\r\n* promise\r\n\r\n本文主要针对koa的原理进行讨论，属于深度篇，并不会对koa的使用过多介绍。\r\n\r\n如果在阅读过程中，发现有哪些地方我写的不太清楚，不容易理解，希望能提出，我会参考建议并进行修改~~\r\n\r\n## koa总体流程图\r\n\r\n让我们从一张图开始\r\n\r\n

\r\n\r\n上图中，详细说明了koa从启动server之前，到接受请求在到响应请求的过程中，经历了哪些步骤。\r\n\r\n那我们按照时间线说起~\r\n\r\n## 启动前\r\n\r\n图中有三个蓝色的方块，分别代表三个`静态类`。\r\n\r\n什么是`静态类`？这个是我自己给起的名，哈哈\r\n\r\n`静态类`就是程序运行前就存在的方法集合，`动态类`就是通过代码生成出的方法集合。额，都是我自己起的名，概念也是我自己琢磨的，就是简单归个类。\r\n\r\n三个静态类分别是`Request`，`Context`，`Response`\r\n\r\n**Request**\r\n\r\nRequest中包含了一些操作 Node原生请求对象的非常有用的方法。例如获取query数据，获取请求url等，更多方法去查API\r\n\r\n**Response**\r\n\r\nResponse中包含了一些用于设置状态码啦，主体数据啦，header啦，等一些用于操作响应请求的方法。更多方法去查API\r\n\r\n**Context**\r\n\r\nContext是koa中最重要的概念之一，Context字面意思是上下文，也有环境等意思，koa中的操作都是基于这个context进行的，例如\r\n\r\n```javascript\r\nthis.body = 'hello world';\r\n```\r\n\r\n从前面的图中，启动前的三个蓝色方块可以看到，左边的Request和右边的Response各有一个箭头指向Context，表示Request和Response自身的方法会委托到Context中。\r\n\r\nContext中有两部分，一部分是自身属性，主要是应用于框架内部使用，一部分是Request和Response委托的操作方法，主要为提供给用户更方便从Request获取想要的参数和更方便的设置Response内容。\r\n\r\n下面是Context源码片段。\r\n\r\n```javascript\r\nvar delegate = require('delegates');\r\nvar proto = module.exports = {}; // 一些自身方法，被我删了\r\n\r\n/**\r\n * Response delegation.\r\n */\r\n\r\ndelegate(proto, 'response')\r\n .method('attachment')\r\n .method('redirect')\r\n .method('remove')\r\n .method('vary')\r\n .method('set')\r\n .method('append')\r\n .access('status')\r\n .access('message')\r\n .access('body')\r\n .access('length')\r\n .access('type')\r\n .access('lastModified')\r\n .access('etag')\r\n .getter('headerSent')\r\n .getter('writable');\r\n\r\n/**\r\n * Request delegation.\r\n */\r\n\r\ndelegate(proto, 'request')\r\n .method('acceptsLanguages')\r\n .method('acceptsEncodings')\r\n .method('acceptsCharsets')\r\n .method('accepts')\r\n .method('get')\r\n .method('is')\r\n .access('querystring')\r\n .access('idempotent')\r\n .access('socket')\r\n .access('search')\r\n .access('method')\r\n .access('query')\r\n .access('path')\r\n .access('url')\r\n .getter('origin')\r\n .getter('href')\r\n .getter('subdomains')\r\n .getter('protocol')\r\n .getter('host')\r\n .getter('hostname')\r\n .getter('header')\r\n .getter('headers')\r\n .getter('secure')\r\n .getter('stale')\r\n .getter('fresh')\r\n .getter('ips')\r\n .getter('ip');\r\n```\r\ndelegates是第三方npm包，功能就是把一个对象上的方法，属性委托到另一个对象上\r\n\r\n对了，你猜对了，上面那一排方法，都是Request和Response静态类中的方法，有点看目录的感觉~\r\n\r\nmethod方法是委托方法，getter方法用来委托getter，access方法委托getter+setter\r\n\r\n下面是源码片段\r\n\r\n```javascript\r\nfunction Delegator(proto, target) {\r\n if (!(this instanceof Delegator)) return new Delegator(proto, target);\r\n this.proto = proto;\r\n this.target = target;\r\n this.methods = [];\r\n this.getters = [];\r\n this.setters = [];\r\n this.fluents = [];\r\n}\r\n\r\nDelegator.prototype.method = function(name){\r\n var proto = this.proto;\r\n var target = this.target;\r\n this.methods.push(name);\r\n\r\n proto[name] = function(){\r\n return this[target][name].apply(this[target], arguments);\r\n };\r\n\r\n return this;\r\n};\r\n```\r\n\r\n从上面的代码中可以看到，它其实是在proto上新建一个与Request和Response上的方法名一样的函数，然后执行这个函数的时候，这个函数在去Request和Response上去找对应的方法并执行。\r\n\r\n\r\n简单来个栗子\r\n\r\n```javascript\r\nvar proto = {};\r\n\r\nvar Request = {\r\n test: function () {\r\n console.log('test');\r\n }\r\n};\r\n\r\nvar name = 'test';\r\nproto[name] = function () {\r\n return Request[name].apply(Request, arguments);\r\n};\r\n```\r\n\r\n我们在来看看getter方法\r\n\r\n```javascript\r\nDelegator.prototype.getter = function(name){\r\n var proto = this.proto;\r\n var target = this.target;\r\n this.getters.push(name);\r\n\r\n proto.__defineGetter__(name, function(){\r\n return this[target][name];\r\n });\r\n\r\n return this;\r\n};\r\n```\r\n可以看到，在proto上绑定个getter函数，当函数被触发的时候去，会去对应的request或response中去读取对应的属性，这样request或response的getter同样会被触发~\r\n\r\n我们在来看看access\r\n\r\n```javascript\r\nDelegator.prototype.access = function(name){\r\n return this.getter(name).setter(name);\r\n};\r\n```\r\n\r\n可以看到，这个方法是getter+setter，getter上面刚说过，setter与getter同理，不多说了，心好累....\r\n\r\n应用启动前的内容到现在就说完了，接下来我们看看使用koa来启动一个app的时候，koa内部会发生什么呢？\r\n\r\n## 启动server\r\n\r\n我们使用koa来启动server的时候有两个步骤。第一步是init一个app对象，第二步是用app对象监听下端口号，一个server就启动好了。\r\n\r\n```javascript\r\n// 第一步 - 初始化app对象\r\nvar koa = require('koa');\r\nvar app = koa();\r\n\r\n// 第二步 - 监听端口\r\napp.listen(1995);\r\n```\r\n\r\n简单吧？\r\n\r\n不了解内部机制的同学，通常会认为server是在`koa()`这个时候启动的，`app.listen`只是监听下端口而已~\r\n\r\n事实上。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。并不是。\r\n\r\n有木有被刷新三观？？？\r\n\r\n我们看下源码片段\r\n\r\n```javascript\r\nmodule.exports = Application;\r\n\r\nfunction Application() {\r\n if (!(this instanceof Application)) return new Application;\r\n this.env = process.env.NODE_ENV || 'development';\r\n this.subdomainOffset = 2;\r\n this.middleware = [];\r\n this.proxy = false;\r\n this.context = Object.create(context);\r\n this.request = Object.create(request);\r\n this.response = Object.create(response);\r\n}\r\n```\r\n\r\n从源码中可以看到，执行`koa()`的时候初始化了一些很有用的东西，包括初始化一个空的中间件集合，基于Request，Response，Context为原型，生成实例等操作。\r\n\r\n**Request和Response的属性和方法委托到Context中也是在这一步进行的**\r\n\r\n并没有启动server\r\n\r\n我们看第二步，在看一段源码\r\n\r\n```javascript\r\napp.listen = function(){\r\n debug('listen');\r\n var server = http.createServer(this.callback());\r\n return server.listen.apply(server, arguments);\r\n};\r\n```\r\n可以看到，在执行`app.listen(1995)`的时候，启动了一个server，并且监听端口。熟悉nodejs的同学知道http.createServer接收一个函数作为参数，每次服务器接收到请求都会执行这个函数，并传入两个参数（request和response，简称req和res），那么现在重点在`this.callback`这个方法上。\r\n\r\n我们一起看一下`this.callback`是何方神圣\r\n\r\n```javascript\r\napp.callback = function(){\r\n if (this.experimental) {\r\n console.error('Experimental ES7 Async Function support is deprecated. Please look into Koa v2 as the middleware signature has changed.')\r\n }\r\n var fn = this.experimental\r\n ? compose_es7(this.middleware)\r\n : co.wrap(compose(this.middleware));\r\n var self = this;\r\n\r\n if (!this.listeners('error').length) this.on('error', this.onerror);\r\n\r\n return function(req, res){\r\n res.statusCode = 404;\r\n var ctx = self.createContext(req, res);\r\n onFinished(res, ctx.onerror);\r\n fn.call(ctx).then(function () {\r\n respond.call(ctx);\r\n }).catch(ctx.onerror);\r\n }\r\n};\r\n```\r\n\r\n**这个方法其实可以分成两部分，一部分是执行函数的那一瞬间所执行的代码，另一部分是接收请求的时候所执行的代码。**\r\n\r\n而前一部分就是总体流程图中，启动server这个时间段，黄色椭圆形所执行的那一部分，**初始化中间件！！！**\r\n\r\n### 第一部分\r\n\r\n先说第一部分，很明显，这环节是在**初始化中间件**，那为什么要初始化中间件呢？处理后的中间件与处理之前的中间件又有什么不同呢？？？？\r\n\r\n童鞋，，，不要着急，听我慢慢道来~~\r\n\r\n我们添加中间的时候使用`app.use`方法，其实这个方法只是把中间件push到一个数组，然后就没有然后了。。(⊙﹏⊙)\r\n\r\n很明显，所有中间件都在数组中，那么它们之间是没有联系的，如果没有联系，就不可能实现`流水线`这样的功能。。。。\r\n\r\n那么这些中间件处理之后会变成什么样的？？？？\r\n\r\n我们先看代码，上面的代码中用`this.experimental`这个属性做了一个判断。这个属性是什么鸟。\r\n\r\n`this.experimental` 关于这个属性我并没有在官方文档上看到说明，但以我对koa的了解，这个方法是为了判断是否支持es7，默认是不支持的，如果想支持，需要在代码中明确指定`this.experimental = true`，开启这个属性之后，中间件可以传入async函数。\r\n\r\n我想说的是，无论是否开启ES7，原理都是相同的，只是因为语法特性的不同，需要不同的处理，核心思想不会因为不同的语言特性而改变，支持ES7显然处理起来更方便，因为默认不开启`this.experimental`，所以这里我们针对不开启的情况进行讨论~\r\n\r\n这样一来，第一部分的代码就简化成了这样\r\n\r\n```javascript\r\nvar fn = co.wrap(compose(this.middleware));\r\n```\r\n\r\n虽然只剩下一行代码，但不要小瞧它哦~~\r\n\r\n我们先看`compose(this.middleware)`这部分，`compose`的全名叫`koa-compose`，他的作用是把一个个不相干的中间件串联在一起。。\r\n\r\n例如\r\n\r\n```javascript\r\n// 有3个中间件\r\nthis.middlewares = [function *m1() {}, function *m2() {}, function *m3() {}];\r\n\r\n// 通过compose转换\r\nvar middleware = compose(this.middlewares);\r\n\r\n// 转换后得到的middleware是这个样子的\r\nfunction *() {\r\n yield *m1(m2(m3(noop())))\r\n}\r\n```\r\n有木有很神奇的感觉？？更神奇的是，generator函数的特性是，第一次执行并不会执行函数里的代码，而是生成一个generator对象，这个对象有next，throw等方法。\r\n\r\n**这就造成了一个现象，每个中间件都会有一个参数，这个参数就是下一个中间件执行后，生成出来的generator对象**，没错，这就是大名鼎鼎的 **next**\r\n\r\n那`compose`是如何实现这样的功能的呢？？我们看一下代码\r\n\r\n```javascript\r\n/**\r\n * Expose compositor.\r\n */\r\n\r\nmodule.exports = compose;\r\n\r\n/**\r\n * Compose `middleware` returning\r\n * a fully valid middleware comprised\r\n * of all those which are passed.\r\n *\r\n * @param {Array} middleware\r\n * @return {Function}\r\n * @api public\r\n */\r\n\r\nfunction compose(middleware){\r\n return function *(next){\r\n if (!next) next = noop();\r\n\r\n var i = middleware.length;\r\n\r\n while (i--) {\r\n next = middleware[i].call(this, next);\r\n }\r\n\r\n return yield *next;\r\n }\r\n}\r\n\r\n/**\r\n * Noop.\r\n *\r\n * @api private\r\n */\r\n\r\nfunction *noop(){}\r\n```\r\n\r\n这是这个模块的所有代码，很简单，逻辑是这样的\r\n\r\n先把中间件从后往前依次执行，并把每一个中间件执行后得到的generator对象赋值给变量next，当下一次执行中间件的时候（也就是执行前一个中间件的时候），把next传给第一个参数。这样就保证前一个中间件的参数是下一个中间件生成的generator对象，第一次执行的时候next为`noop`，`noop`是空的generator函数。\r\n\r\nkoa的中间件必须为generator函数（就是带星号的函数），否则无法顺利的执行中间件逻辑\r\n\r\n最后，有一个非常巧妙的地方，就是最后一行`return yield *next;`\r\n\r\n这行代码可以实现把`compose`执行后return的函数变成第一个中间件，也就是说，执行`compose`之后会得到一个函数，执行这个函数就与执行第一个中间件的效果是一模一样的，这主要依赖了generator函数的yield *语句的特性。\r\n\r\n现在中间件的状态就已经从`不可用`变成`可用`了。不可用的中间件是一个数组，可用的中间件是一个**generator函数**。\r\n\r\n我们接着说刚才没说完的\r\n\r\n\r\n```javascript\r\nvar fn = co.wrap(compose(this.middleware));\r\n```\r\n\r\n上面这段代码现在就可以理解成下面这样\r\n\r\n```javascript\r\nvar fn = co.wrap(function *() {yield *m1(m2(m3(noop())))});\r\n```\r\n\r\n里面的函数刚刚已经说过是可用状态的中间件，那么`co.wrap`是干什么用的呢？？\r\n\r\nco是TJ大神基于Generator开发的一款流程控制模块，白话文就是：就是把异步变成同步的模块。。。（感觉逼格瞬间拉低了。。。）\r\n\r\n看下源码\r\n\r\n```javascript\r\nco.wrap = function (fn) {\r\n createPromise.__generatorFunction__ = fn;\r\n return createPromise;\r\n function createPromise() {\r\n return co.call(this, fn.apply(this, arguments));\r\n }\r\n};\r\n```\r\n从源码中可以看到，它接收一个参数，这个参数就是可用状态下的中间件，返回一个函数createPromise，当执行createPromise这个函数的时候，调用co并传入一个参数，这个参数是中间件函数执行后生成的Generator对象。\r\n\r\n**这意味着，返回的这个函数是触发执行中间件逻辑的关键，一旦这个函数被执行，那么就会开始执行中间件逻辑**\r\n\r\n```javascript\r\napp.callback = function(){\r\n if (this.experimental) {\r\n console.error('Experimental ES7 Async Function support is deprecated. Please look into Koa v2 as the middleware signature has changed.')\r\n }\r\n var fn = this.experimental\r\n ? compose_es7(this.middleware)\r\n : co.wrap(compose(this.middleware));\r\n var self = this;\r\n\r\n if (!this.listeners('error').length) this.on('error', this.onerror);\r\n\r\n return function(req, res){\r\n res.statusCode = 404;\r\n var ctx = self.createContext(req, res);\r\n onFinished(res, ctx.onerror);\r\n fn.call(ctx).then(function () {\r\n respond.call(ctx);\r\n }).catch(ctx.onerror);\r\n }\r\n};\r\n```\r\n\r\n从源码中，可以看到这个函数赋值给fn，fn是在下面那个函数中执行的，下面那个函数是接下来要说的内容~\r\n\r\n\r\n到现在，我们的koa已经处于一种待机状态，所有准备都以准备好（中间件和context），万事俱备，只欠东风。。。。。。\r\n\r\n东风就是request请求~~\r\n\r\n## 接收请求\r\n\r\n前面说了启动前的一些准备工作和启动时的初始化工作，现在最后一步就是接收请求的时候，koa要做的事情了，这部分也是koa中难度最大的一部分。不过认真阅读下去会有收获的。。\r\n\r\n上面我们说`this.callback`这个方法有两个部分，第一个部分是初始化中间件，而另一部分就是接收请求时执行的函数啦。\r\n\r\n简单回顾下\r\n\r\n```javascript\r\n// 创建server并监听端口\r\napp.listen = function(){\r\n debug('listen');\r\n var server = http.createServer(this.callback());\r\n return server.listen.apply(server, arguments);\r\n};\r\n\r\n// 这个方法返回的函数会被传递到http.createServer中，http.createServer这个方法的作用是每当服务器接收到请求的时候，都会执行第一个参数，并且会传递request和response\r\napp.callback = function(){\r\n if (this.experimental) {\r\n console.error('Experimental ES7 Async Function support is deprecated. Please look into Koa v2 as the middleware signature has changed.')\r\n }\r\n var fn = this.experimental\r\n ? compose_es7(this.middleware)\r\n : co.wrap(compose(this.middleware));\r\n var self = this;\r\n\r\n if (!this.listeners('error').length) this.on('error', this.onerror);\r\n\r\n return function(req, res){\r\n res.statusCode = 404;\r\n var ctx = self.createContext(req, res);\r\n onFinished(res, ctx.onerror);\r\n fn.call(ctx).then(function () {\r\n respond.call(ctx);\r\n }).catch(ctx.onerror);\r\n }\r\n};\r\n```\r\n\r\n所以第二部分的重点就是下面段代码啦~\r\n\r\n```javascript\r\nreturn function(req, res){\r\n res.statusCode = 404;\r\n var ctx = self.createContext(req, res);\r\n onFinished(res, ctx.onerror);\r\n fn.call(ctx).then(function () {\r\n respond.call(ctx);\r\n }).catch(ctx.onerror);\r\n}\r\n```\r\n\r\n我们先看这段代码\r\n\r\n```javascript\r\nvar ctx = self.createContext(req, res);\r\n```\r\n不知道各位童鞋还记不记得文章一开始的时候那个总体流程图下面的那个类似于八卦一样的东西？？？\r\n\r\n这行代码就是创建一个最终可用版的context。\r\n\r\n

\r\n\r\n从上图中，可以看到分别有五个箭头指向ctx，表示ctx上包含5个属性，分别是request，response，req，res，app。request和response也分别有5个箭头指向它们，所以也是同样的逻辑。\r\n\r\n这里需要说明下\r\n\r\n* request - request继承于Request静态类，包含操作request的一些常用方法\r\n* response - response继承于Response静态类，包含操作response的一些常用方法\r\n* req - nodejs原生的request对象\r\n* res - nodejs原生的response对象\r\n* app - koa的原型对象\r\n\r\n不多说，咱们观摩下代码\r\n\r\n```javascript\r\napp.createContext = function(req, res){\r\n \r\n // 继承\r\n var context = Object.create(this.context);\r\n var request = context.request = Object.create(this.request);\r\n var response = context.response = Object.create(this.response);\r\n \r\n // 往context，request，response身上挂载属性\r\n context.app = request.app = response.app = this;\r\n context.req = request.req = response.req = req;\r\n context.res = request.res = response.res = res;\r\n request.ctx = response.ctx = context;\r\n request.response = response;\r\n response.request = request;\r\n context.onerror = context.onerror.bind(context);\r\n context.originalUrl = request.originalUrl = req.url;\r\n context.cookies = new Cookies(req, res, {\r\n keys: this.keys,\r\n secure: request.secure\r\n });\r\n context.accept = request.accept = accepts(req);\r\n context.state = {};\r\n \r\n // 最后返回完整版context\r\n return context;\r\n};\r\n```\r\n\r\n讲到这里其实我可以很明确的告诉大家，，，koa中的`this`其实就是`app.createContext`方法返回的完整版`context`\r\n\r\n又由于这段代码的执行时间是接受请求的时候，所以表明**每一次接受到请求，都会为该请求生成一个新的上下文**\r\n\r\n上下文到这里我们就说完啦。我们接着往下说，看下一行代码\r\n\r\n```javascript\r\nonFinished(res, ctx.onerror);\r\n```\r\n这行代码其实很简单，就是监听response，如果response有错误，会执行`ctx.onerror`中的逻辑，设置response类型，状态码和错误信息等。\r\n\r\n源码如下：\r\n\r\n```javascript\r\nonerror: function(err){\r\n // don't do anything if there is no error.\r\n // this allows you to pass `this.onerror`\r\n // to node-style callbacks.\r\n if (null == err) return;\r\n\r\n if (!(err instanceof Error)) err = new Error('non-error thrown: ' + err);\r\n\r\n // delegate\r\n this.app.emit('error', err, this);\r\n\r\n // nothing we can do here other\r\n // than delegate to the app-level\r\n // handler and log.\r\n if (this.headerSent || !this.writable) {\r\n err.headerSent = true;\r\n return;\r\n }\r\n\r\n // unset all headers\r\n this.res._headers = {};\r\n\r\n // force text/plain\r\n this.type = 'text';\r\n\r\n // ENOENT support\r\n if ('ENOENT' == err.code) err.status = 404;\r\n\r\n // default to 500\r\n if ('number' != typeof err.status || !statuses[err.status]) err.status = 500;\r\n\r\n // respond\r\n var code = statuses[err.status];\r\n var msg = err.expose ? err.message : code;\r\n this.status = err.status;\r\n this.length = Buffer.byteLength(msg);\r\n this.res.end(msg);\r\n}\r\n```\r\n\r\n我们接着说，还有最后一个知识点，也是本章最复杂的知识点，关于中间件的执行流程，这里会说明为什么koa的中间件可以回逆。\r\n\r\n我们先看代码\r\n\r\n```javascript\r\nfn.call(ctx).then(function () {\r\n respond.call(ctx);\r\n}).catch(ctx.onerror);\r\n```\r\n\r\n* fn - 我们上面讲的`co.wrap`返回的那个函数\r\n* ctx - app.createContext执行后返回的完整版context对象\r\n\r\n总体上来说，执行`fn.call(ctx)`会返回promise，koa会监听执行的成功和失败，成功则执行`respond.call(ctx);`，失败则执行`ctx.onerror`，失败的回调函数刚刚已经讲过。这里先说说`respond.call(ctx);`。\r\n\r\n我们在写koa的时候，会发现所有的response操作都是\r\n`this.body = xxx;` `this.status = xxxx;`这样的语法，但如果对原生nodejs有了解的童鞋知道，nodejs的response只有一个api那就是`res.end();`，而设置status状态码什么的都有不同的api，那么koa是如何做到通过`this.xxx = xxx`来设置response的呢？\r\n\r\n先看一张图，，我盗的图\r\n\r\n

\r\n\r\n从图中看到，request请求是以respond结束的。\r\n\r\n是滴，所有的request请求都是以respond这个函数结束的，这个函数会读取this.body中的值根据不同的类型来决定以什么类型响应请求\r\n\r\n我们来欣赏一下源码\r\n\r\n```javascript\r\nfunction respond() {\r\n // allow bypassing koa\r\n if (false === this.respond) return;\r\n\r\n var res = this.res;\r\n if (res.headersSent || !this.writable) return;\r\n\r\n var body = this.body;\r\n var code = this.status;\r\n\r\n // ignore body\r\n if (statuses.empty[code]) {\r\n // strip headers\r\n this.body = null;\r\n return res.end();\r\n }\r\n\r\n if ('HEAD' == this.method) {\r\n if (isJSON(body)) this.length = Buffer.byteLength(JSON.stringify(body));\r\n return res.end();\r\n }\r\n\r\n // status body\r\n if (null == body) {\r\n this.type = 'text';\r\n body = this.message || String(code);\r\n this.length = Buffer.byteLength(body);\r\n return res.end(body);\r\n }\r\n\r\n // responses\r\n if (Buffer.isBuffer(body)) return res.end(body);\r\n if ('string' == typeof body) return res.end(body);\r\n if (body instanceof Stream) return body.pipe(res);\r\n\r\n // body: json\r\n body = JSON.stringify(body);\r\n this.length = Buffer.byteLength(body);\r\n res.end(body);\r\n}\r\n```\r\n\r\n仔细阅读的童鞋会发现，咦，，，，为毛没有设置status和header等信息的代码逻辑？这不科学啊。我分明记得状态码是`rs.statusCode = 400`这样设置的，为啥代码中没有？？\r\n\r\n这就要从最开始的上下文说起了。为什么Response静态类中添加req和res属性？就是因为添加了req和res之后，response和request类就可以直接操作req和res啦。。我们看一段源码就明白了\r\n\r\n```javascript\r\nset status(code) {\r\n assert('number' == typeof code, 'status code must be a number');\r\n assert(statuses[code], 'invalid status code: ' + code);\r\n this._explicitStatus = true;\r\n this.res.statusCode = code;\r\n this.res.statusMessage = statuses[code];\r\n if (this.body && statuses.empty[code]) this.body = null;\r\n},\r\n```\r\n\r\n主要是`this.res.statusCode = code;` `this.res.statusMessage = statuses[code];`这两句，`statusCode`和`statusMessage`都是nodejs原生api。有兴趣可以自行查看~\r\n\r\n接下来我们开始说说koa的中间件为什么可以回逆，为什么koa的中间件必须使用generator，yield next又是个什么鬼？\r\n\r\n我们看这段代码\r\n\r\n```javascript\r\nfn.call(ctx)\r\n```\r\n\r\nfn刚刚上面说过，就是`co.wrap`返回的那个函数，上面也说过，一旦这个函数执行，就会执行中间件逻辑，并且通过`.call`把`ctx`设为上下文，也就是this。\r\n\r\n那中间件逻辑是什么样的呢。我们先看一下源码：\r\n\r\n```javascript\r\nco.wrap = function (fn) {\r\n createPromise.__generatorFunction__ = fn;\r\n return createPromise;\r\n function createPromise() {\r\n return co.call(this, fn.apply(this, arguments));\r\n }\r\n};\r\n```\r\n\r\n先回顾下，createPromise就是fn，每当执行createPromise的时候，都会执行co，中间件是基于co实现的、所以我们接下来要说的是co的实现逻辑。而执行co所传递的那个参数，我们给它起个名，就叫`中间件函数`吧，中间件函数也是一个generator函数，因为在执行co的时候执行了这个中间件函数，所以实际上真正传递给co的参数是一个generator对象，为了方便理解，我们先起个名叫`中间件对象吧`\r\n\r\n那我们看co的源码：\r\n\r\n```javascript\r\nfunction co(gen) {\r\n var ctx = this;\r\n var args = slice.call(arguments, 1)\r\n\r\n // we wrap everything in a promise to avoid promise chaining,\r\n // which leads to memory leak errors.\r\n // see https://github.com/tj/co/issues/180\r\n return new Promise(function(resolve, reject) {\r\n if (typeof gen === 'function') gen = gen.apply(ctx, args);\r\n if (!gen || typeof gen.next !== 'function') return resolve(gen);\r\n\r\n onFulfilled();\r\n\r\n /**\r\n * @param {Mixed} res\r\n * @return {Promise}\r\n * @api private\r\n */\r\n\r\n function onFulfilled(res) {\r\n var ret;\r\n try {\r\n ret = gen.next(res);\r\n } catch (e) {\r\n return reject(e);\r\n }\r\n next(ret);\r\n }\r\n\r\n /**\r\n * @param {Error} err\r\n * @return {Promise}\r\n * @api private\r\n */\r\n\r\n function onRejected(err) {\r\n var ret;\r\n try {\r\n ret = gen.throw(err);\r\n } catch (e) {\r\n return reject(e);\r\n }\r\n next(ret);\r\n }\r\n\r\n /**\r\n * Get the next value in the generator,\r\n * return a promise.\r\n *\r\n * @param {Object} ret\r\n * @return {Promise}\r\n * @api private\r\n */\r\n\r\n function next(ret) {\r\n if (ret.done) return resolve(ret.value);\r\n var value = toPromise.call(ctx, ret.value);\r\n if (value && isPromise(value)) return value.then(onFulfilled, onRejected);\r\n return onRejected(new TypeError('You may only yield a function, promise, generator, array, or object, '\r\n + 'but the following object was passed: \"' + String(ret.value) + '\"'));\r\n }\r\n });\r\n}\r\n```\r\n\r\n可以看到，代码并不是很多。\r\n\r\n首先执行co会返回一个promise，koa会对这个promise的成功和失败都准备了不同的处理，上面已经说过。\r\n\r\n我们在看这段代码\r\n\r\n```javascript\r\nfunction onFulfilled(res) {\r\n var ret;\r\n try {\r\n ret = gen.next(res);\r\n } catch (e) {\r\n return reject(e);\r\n }\r\n next(ret);\r\n}\r\n```\r\n这个函数最重要的作用是运行`gen.next`来执行中间件中的业务逻辑。\r\n\r\n通常在开发中间件的时候会这样写\r\n\r\n```javascript\r\nyield next;\r\n```\r\n所以ret中包含下一个`中间件对象`（还记得上面我们初始化中间件的时候中间件的参数是什么了吗？？）\r\n\r\n然后把下一个中间件对象传到了`next(ret)`这个函数里，next函数是干什么的？我们看看\r\n\r\n```javascript\r\nfunction next(ret) {\r\n if (ret.done) return resolve(ret.value);\r\n var value = toPromise.call(ctx, ret.value);\r\n if (value && isPromise(value)) return value.then(onFulfilled, onRejected);\r\n return onRejected(new TypeError('You may only yield a function, promise, generator, array, or object, '\r\n + 'but the following object was passed: \"' + String(ret.value) + '\"'));\r\n}\r\n```\r\n可以看到，逻辑是这样的\r\n\r\n如果中间件已经结束（没有yield了），那么调用promise的resolve。\r\n\r\n否则的话把ret.value（就是下一个中间件对象），用co在包一层`toPromise.call(ctx, ret.value);`\r\n\r\n```javascript\r\nif (isGeneratorFunction(obj) || isGenerator(obj)) return co.call(this, obj);\r\n```\r\n上面是toPromise中的一段代码\r\n\r\n既然是用co又执行了一遍，那么co是返回promise的。所以返回的这个value就分别被监听了成功和失败的不同处理。\r\n\r\n```javascript\r\nvalue.then(onFulfilled, onRejected);\r\n```\r\n\r\n所以我们可以看到，如果第二个中间件里依然有`yield next`这样的语句，那么第三个中间件依然会被co包裹一层并运行.next方法，依次列推，这是一个递归的操作\r\n\r\n所以我们可以肯定的是，每一个中间件都被promise包裹着，直到有一天中间件中的逻辑运行完成了，那么会调用promise的resolve来告诉程序这个中间件执行完了。\r\n\r\n那么中间件执行完了之后，会触发`onFulfilled`，这个函数会执行.next方法。\r\n\r\n所以有一个非常重要的一点需要注意，`onFulfilled`这个函数非常重要，重要在哪里？？？重要在它执行的时间上。\r\n\r\n**`onFulfilled`这个函数只在两种情况下被调用，一种是调用co的时候执行，还有一种是当前promise中的所有逻辑都执行完毕后执行**\r\n\r\n其实就这一句话就能说明koa的中间件为什么会回逆。\r\n\r\n回逆其实是有一个去和一个回的操作\r\n\r\n

\r\n\r\n请求的时候经过一次中间件，响应的时候在经过一次中间件。\r\n\r\n而onFulfilled的两种被调用的情况正好和这个回逆的过程对应上。\r\n\r\n前方高能预警！！！\r\n\r\n**比如有3个中间件，当系统接收到请求的时候，会执行co，co会立刻执行onFulfilled来调用.next往下执行，将得到的返回结果（第二个中间件的generator对象，上面我们分析过）传到co中在执行一遍。以此类推，一直运行到最后一个yield，这个时候系统会等待中间件的执行结束，一旦最后一个中间件执行完毕，会立刻调用promise的resolve方法表示结束。（这个时候onFulfilled函数的第二个执行时机到了，这样就会出现一个现象，一个generator对象的yield只能被next一次，下次执行.next的时候从上一次停顿的yield处继续执行，所以现在当有一个中间件执行完毕后，在执行.next就会在前一个中间件的yield处继续执行）当最后一个中间件执行完毕后，触发promise的resolve，而别忘了，第二个中间件可是用then监听了成功和失败的不同处理方法，一旦第三个中间件触发成功，第二个中间件会立刻调用onFulfilled来执行.next，继续从第二个中间件上一次yield停顿处开始执行下面的代码，而第二个中间件的逻辑执行完毕后，同样会执行resolve表示成功，而这个时候第一个中间件正好也通过.then方法监听了第二个中间件的promise，也会立刻调用onFulfilled函数来执行.next方法，这样就会继续从第一个中间件上一次yield的停顿处继续执行下面的逻辑，以此类推。**\r\n\r\n这样就实现了中间件的回逆，通过递归从外到里执行一遍中间件，然后在通过promise+generator从里往外跳。\r\n\r\n所以如果我们在一个中间件中写好多yield，就可以看出关键所在，先通过递归从外往里（从第一个中间件运行到最后一个中间件）每次遇到yield next就会进入到下一个中间件执行，当运行到最后发现没有yield的时候，会跳回上一个中间件继续执行yield后面的，结果发现又有一个yield next，它会再次进入到下一个中间件，进入到下一个中间件后发现什么都没有，因为yield的特性（一个generator对象的yield只能被next一次，下次执行.next的时候从上一次停顿的yield处继续执行），所以便又一次跳入上一个中间件来执行。以此类推。\r\n\r\n我们试一下：\r\n\r\n```javascript\r\nvar koa = require('koa');\r\nvar app = koa();\r\n\r\napp.use(function* f1(next) {\r\n console.log('f1: pre next');\r\n yield next;\r\n console.log('f1: post next');\r\n yield next;\r\n console.log('f1: fuck');\r\n});\r\n\r\napp.use(function* f2(next) {\r\n console.log(' f2: pre next');\r\n yield next;\r\n console.log(' f2: post next');\r\n yield next;\r\n console.log(' f2: fuck');\r\n});\r\n\r\napp.use(function* f3(next) {\r\n console.log(' f3: pre next');\r\n yield next;\r\n console.log(' f3: post next');\r\n yield next;\r\n console.log(' f3: fuck');\r\n});\r\n\r\napp.use(function* (next) {\r\n console.log('hello world')\r\n this.body = 'hello world';\r\n});\r\n\r\n\r\napp.listen(3000);\r\n```\r\n上面的代码打印的log是下面这样的\r\n\r\n```javascript\r\nf1: pre next\r\n f2: pre next\r\n f3: pre next\r\nhello world\r\n f3: post next\r\n f3: fuck\r\n f2: post next\r\n f2: fuck\r\nf1: post next\r\nf1: fuck\r\n```\r\n\r\n如果非要画一个图的话，我脑海中大概长这样\r\n\r\n

\r\n\r\n其实刚刚那么一通复杂的逻辑下来，好多同学都会懵逼，那么我用白话文来说一下中间件的逻辑，大概是这样的\r\n\r\n**第一个中间件代码执行一半停在这了，触发了第二个中间件的执行，第二个中间件执行了一半停在这了，触发了第三个中间件的执行，然后，，，，，，第一个中间件等第二个中间件，第二个中间件等第三个中间件，，，，，，第三个中间件全部执行完毕，第二个中间件继续执行后续代码，第二个中间件代码全部执行完毕，执行第一个中间件后续代码，然后结束**\r\n\r\n用一张图表示大概是这样的。\r\n\r\n![middleware](https://cloud.githubusercontent.com/assets/3739368/14908102/e58c340a-0e04-11e6-93ba-ac04e342ae7f.png)\r\n\r\n为了方便理解，伪代码大概是下面这样\r\n\r\n```javascript\r\nnew Promise(function(resolve, reject) {\r\n // 我是中间件1\r\n yield new Promise(function(resolve, reject) {\r\n // 我是中间件2\r\n yield new Promise(function(resolve, reject) {\r\n // 我是中间件3\r\n yield new Promise(function(resolve, reject) {\r\n // 我是body\r\n });\r\n // 我是中间件3\r\n });\r\n // 我是中间件2\r\n });\r\n // 我是中间件1\r\n});\r\n```\r\n\r\n这就是最核心的思想！！！\r\n\r\n#### 总结\r\n\r\n简单总结一下，其实也很简单，只是第一次接触的同学可能暂时没有理解透彻。\r\n\r\n其实就是通过generator来暂停函数的执行逻辑来实现等待中间件的效果，通过监听promise来触发继续执行函数逻辑，所谓的回逆也不过就是同步执行了下一个中间件罢了。\r\n\r\n比如有几个中间件，mw1,mw2,mw3,mwn...\r\n\r\n站在mw1的角度上看，它是不需要关系mw2里面有没有mw3，它只需要关心mw2何时执行完毕即可，当mw2执行完毕mw1继续执行yield之后的代码逻辑。其实很简单，callback也是这个原理，当mw2执行完毕执行下callback，mw1是不需要关心mw2里面究竟是怎样运行的，只要知道mw2执行完会执行回调就行了。mw2也是同样的道理不需要关心mw3。\r\n\r\n到这里，关于koa我们就已经差不多都说完了。当然还有一些细节没有说，比如koa中的错误处理，但其实都是小问题啦，关于generator的错误处理部分弄明白了，自然就明白koa的错误处理是怎样的。这里就不在针对这些讲述了，一次写这么多确实有点累，或许后期会补充进来吧。。\r\n\r\n## 两个重要技术点\r\n\r\n最后，如果认真阅读下来的同学能感觉出来，koa中有两个最重要的地方，无论是使用上，还是思想上，这两个点都非常重要，koa也只有这两个概念\r\n\r\n* Middleware - 中间件\r\n* Context - 上下文\r\n\r\n\r\n最后说一些自己对koa的感觉，真他妈的是赏心悦目啊，真他妈的是优雅啊！！！每一行代码都浓缩了很多层含义，通过最少的代码实现最复杂的功能，对于我这种追求代码的极致优雅的人，看完koa之后，真的是感触良多，泪流满面啊。。。。\r\n\r\nppt：http://berwin.github.io/ppts/koa/\r\n\r\n转载请注明出处\r\n\r\n

","深入浅出 Koa","2018-01-02 01:00:28.599",41,32015,"2016-03-14 09:47:21.178",{"_13":68,"_23":69},"berwin","https://avatars0.githubusercontent.com/u/3739368?v=4"]