Node v1.0路线图
在上周（5.9）于San Francisco, CA，由Node.js++俱乐部举办的分享会议上，Isaac Schlueter（Node现今的Gatekeeper）介绍了Node v1.0的详细路线图，并于Youtube上传了分享视频。Isaac Schlueter在本次分享中介绍了Node1.0发布前Node还将经历的增强和改动。这个经历4年左右发展的技术，一出世就吸引了太多太多的目光，惊人的社区活力，相信它的大版本会得到更多人的关注。
尽管Isaac Schlueter在Node v0.10发布时就对未来的计划通过博客进行过说明，但没有本次分享详细和正式，那让我们就内容先睹为快吧。
Node v0.10
Node v0.10的发布，带来了以下这些改进，并随着v0.10.x的发布，将持续在这几个方面带来增强：
- 主要引入了新的Stream API（Stream2）
- API的改进。包括domains, nextTick, IdleGC等
- 持续集成。目前Node通过jenkins搭建了持续继承的环境，每天为新的改动执行单元测试，以检测对多个平台的影响
- 一些企业场景的支持
- 依然成指数增长的社区模块
这里Stream2主要方向是内部重构和向下兼容方面的工作，不再重点详述。
npm-www的计划
npm-www是Node官方的第三方公共模块平台，目前上面有3万多个第三方模 块，在数量和开发速度上都呈现出社区的活跃度。但是这里隐藏的问题是第三方模块存在良莠不齐的质量，需要更科学的管理，和更良好的社区生态环境。 Isaac Schlueter提到将会通过以下三个方面入手：
- 集成Github。集成Github上的项目仓库，和集成Github的登录。npm上的模块大多托管在Github上，集成Github将两个社区联系得更紧密
- 推荐引擎。目前寻找目标模块的方式还比较原始，主要是通过Node的模块列表Wiki、通过npm-www搜索、通过Github等。对于社区的发展还需要更好的推荐方式，如何让优秀的模块让需要它的人更快的找到，是故，推荐引擎不可少。
- 模块排行。Isaac Schlueter计划引入CPAN社区中的“Kwalitee”风格来让模块进行排序。
“Kwalitee”是一个拟声词，发音与“quality”相同。CPAN社区对它原始的解释如下：
"Kwalitee" is something that looks like quality, sounds like quality, but is not quite quality.
总体意思就是模块的质量不是那么容易确认，只能从一些层面对它进行考察，但即使考察都通过，也并不能意味着它就是高质量的模块，所以存在 “Kwalitee”这么一个新发明的词。这个方法能排除大部分不合格的模块，虽不精确，但是有效。总体而言，符合“Kwalitee”的模块应该是满足 如下的条件：
- 具有良好测试
- 具有良好文档（README、API）
- 具备良好的测试覆盖率
- 具备良好的编码规范
- etc.
对API采用Deprecate标记， 而不是暴力修改API
没有人料到Node目前已经这么成熟，随着Node的成长，刻意破坏API兼容性的日子结束了。假如发现Node中有些API不合理，也不会直接暴 力删除了，而是采用温和的deprecate标记。Node团队保证只要你的应用现在能跑起来，不用任何修改过了一年以后仍然能跑起来。
Node v0.12
对于v0.12，可以将它看成是1.0的候选版本。这个版本之后，就是我们翘首企盼了4年的1.0版本。这个版本主要的工作几种在4个方面：
- 重构TLS模块。主要是在性能方面
- 清理HTTP模块
- 提升Cluster模块的负载均衡能力
- 处理掉Buffers中性能慢的点
Buffers
Buffers是这个版本要重点攻克的地方，因为Buffers在Node中有着广泛的应用，任何Buffers带来的性能提升都会让Node受益。现在的难点在于Persistent和MakeWeak的GC方式太慢。
目前调研了两种方法来解决这个问题：
- ThinBuffers。一种用户分配/销毁的的Buffers对象
- 让Buffer成为V8的原生对象，视图从V8的层面来改进
不久之前，Trevor Norris加入了Node核心开发团队。Trevor Norris来自Mozilla公司，之前为Node贡献的开发工作主要在node.cc中，围绕process.nextTick, node::MakeCallback和Domains部分。他的加入主要是致力让Buffers更快。让我们翘首以待。
TLS
TLS模块是Node典型的弱点。由于涉及安全，在系统中存在更多的层次。完成一次安全传输，TSL是先要经过libuv（C），进入TCP层 （JavaScript），处理的结果立刻扔给OpenSSL（C），OpenSSL干完活后又扔出Buffer，给后面的http_parser，处理 之后才扔出Buffer给用户层（JavaScript）。如图所示：
我们可以看到这这过程中有大量的JavaScript与C之间的对象调用，中间创建了大量无意义的Buffer。所以将会对TLS中的 tls.CryptoStraeam进行重构。重构后这一层，以下的代码全部用C完成，这以上的代码全用JavaScript完成，这样只要创建一次 Buffer就可以了。
将来tls.CryptoStream会为了向下兼容而存在，不会被默认启用。
http
http模块目前一个文件中既包含服务端也包含客户端代码，主要的目的是试图共用一些代码，但这并不是一个好主意。目前已经着手分离它，以使代码更容易管理。同时http模块与TLS有相同的问题，就是创建了太多无意义的Buffers对象，这也是待改进的点。
对于http客户端的连接池，Node默认设置的连接数量是5，这个数字可能是当时拍脑袋决定的，该版本将会改进它。
另外http的客户端实现只在队列中有请求时，才让底层TCP保持连接，如果队列中没有请求，就会关掉它，即是你立即又发起请求。这个版本的改进将使它真正能保持连接。
cluster
cluster模块使得Node能够实现单机的进程集群，但它目前在负载均衡上的表现欠佳，总有一个或两个worker进程干了太多活。这使得你需 要集群好好工作的地方，却在某些情况下引起问题。接下来的解决方案是将会采用round-robin调度来使集群负载均衡良好。
其他地方
- 子进程同步执行 execSync
- 流对象写入的writev支持（将多个缓冲区中的数据一次写出，以提升性能）
- V8 API改变带来的某些改变
- 更好的IPv6支持
- 特殊的DNS支持
- Bug修复等
Node v1.0
Node v1.0将是v0.12之后的下一个稳定版，目前的API在1.0中都会有效，但是内部会有小的改动。v0.12版本之后不会新的功能特性开发计划，从0.12到1.0之间不会有大体上的区别。
总结
总体来说，这个路线图主要反映如下这几个方向： - 持续性的稳定系数提升 - 速度提升，这可能得益于V8的升级，或者新的ECMAScript特性等 - Node现在已经相当稳定，可以放心使用。 - 不会有奇怪的事情发生 - Node绝不会出现Perl6/Python3（不会出现语法变动，不向下兼容的版本）
另外Node v1.0之后会带来稳定和持续性的发展势能，这主要体现在： - Node国度中，对核心代码的改动影响将会减缓 - 稳定的基础是最好的培养社区创新的最好方式 - 仍然可能发生变化，虽然是稳定的立场相悖，但会做出权衡 - 疯狂而高产，快速成长的社区 - 涌现更多用Node的产品将势不可挡
