Node.js在Qzone的演进

本文由youkun编写：原文地址

2011~清除迷雾

入职年负责的第一件事是用node.js来实现长连接。因为涉及server开发，所以直接进入双导师模式，一个前端导师加一个后端导师。

server的开发部署摸清了在腾讯做后端开发的大部分流程和工具，为之后的node.js开发清除了迷雾。

2012~一切皆模块

2012只做了一件事，那就是模块化，浏览器里的代码被抽像为一个个module。除了参与sea.js设计细节的撕逼，团队也诞生了基于目录的合并编译工具JSC。JSC一直用到现在，最好用的一个功能是实时把前端模板编译为sea.js模块，为后来的直出复用模板做了积累。

2012年10年1日 node.js直出服务器第一个版本诞生，命名py_nodejs_proxy。py并不是大家理解的炮友的意思，而是朋友网的缩写， proxy指可编程的代理。这个名字一直延续到现在。

2013~错过最好的发展时机

这一年经历了空间触屏改版，是Node.js发展的风口。但是，由于各种原因最后采用了CPP+V8的解决方案，Node.js的定位被锁死在模板上。这并不是我希望的结果，于是又新起了一个相册直出的域名，继续默默更新py_nodejs_proxy，等待下一个风口。

那一年空间触屏上亿PV，相册直出域名千万级PV，装机量不到20+。

2014~无为的一年

打酱油的一年Orz

2015~破局

如果非要用一句话总结这半年来的主要工作：不停的把其它域名cname到相册直出域名。

随着移动端的崛起，新起的项目面临如何同时支持多平台的问题。从后台的角度来看这个问题，相同的接口维护两种协议，已经成为一种隐形的成本。支持移动端是必须的，那如何优雅的进行H5开发呢？就是现在，前端看到机会点，我们重新思考py_nodejs_proxy的定位，不仅仅是用来直出页面，而是将py_nodejs_proxy定义为http接入层，所有天赋点都加到proxy的技能树上。

然后就有了webapp，这意味着Node.js可以直接调用后台为手机准备的所有接口。然后也有了域名收归能力，为更快的尝试spdy/http2.0等项目提供了可能。新活动和项目后端专心搞接口，接入层前端直接搞定，随着webapp的大面积使用，Node.js一下热了起来。

大面积的业务应用间接推动了py_nodejs_proxy在基础能力上的不断完善。立体监控、实时日志、染色和window对象的出现、安全、httpdns、更强的路由和代理能力。同时py_nodejs_proxy开始把业务逻辑向外分离，集成大量公司级公共组件（L5、DC、门神、CMEM等），定位开始变得清晰，从空间Node.js解决方案上升为公司级通用解决方案。因为具有一定的技术壁垒，接着内部站点nodejs.oa.com诞生，文档开始出现。

这一年相册直出域名过亿PV，手Q离线包域名过40亿PV。py_nodejs_proxy装机量破百，共385个迭代，2015半年就贡献了255个~

团队的状态异常活跃，任何靠谱的想法都可以快速落地执行，有意思的工具或内部站点开始不断涌现。随着py_nodejs_proxy的完善，其发现问题和定位问题的能力已经远远超过tnginx，业务内部开始出现tnginx退Node.js进的趋势。微云全站也在进行着php退Node.js进的演进。

空间前端开发者的日常聊天话题，已经从“浏览器中遇到的奇葩问题”扩展到了“http接入层中遇到的奇葩问题”，团队的日常行为和面对反馈的第一反应也发生了巨大变化。比如，以前面对用户反馈第一时间是联系用户抓包分析，现在直接查流水对log。回过头看，如今的空间前端和当年的相比，已经不在一个档次上。

技术的领先，在被普及后都不再有壁垒，我们需要不断的扩展新的领域保持领先，任何可以用JS实现的都终将被JS实现，下一个也许大概可能就是react~