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)。如图所示:

Node v1.0路线图_第1张图片

我们可以看到这这过程中有大量的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的产品将势不可挡

参考

  • http://j.mp/2013-road-to-node-10
  • http://cpants.cpanauthors.org/kwalitee

感谢崔康对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至[email protected]。也欢迎大家通过新浪微博(@InfoQ)或者腾讯微博(@InfoQ)关注我们,并与我们的编辑和其他读者朋友交流。

你可能感兴趣的:(Node v1.0路线图)