什么是生产环境，给人造成的字面上的解释是满是隆隆机器的工厂？或者是妇产医院的婴儿房？在Web开发中，开发环境是指已经运行在正式环境中的代码，与其相对的则是在开发环境中的代码，balabalabala...（扯O中...）

希望上边的一段话不会让你认为本文是懒婆娘的裹脚布的开端。
相比于开发环境，生产环境有几个特点：

a). 对性能的需求

开发环境中，对网站的uv（user view）为1，没什么好说的了，怎么方便，怎么能提升开发效率。抄起你的十八般武艺，怎么使得顺手怎么招呼。
总之一句话，开发效率为先。
对比与线上环境，uv是个不确定的数值，说不定今天放了几张小黄图会引来无数狼友的围观。说不定某天也会门庭冷清。
对于性能的支持上，首先从硬件拼起，本文以本站音韵码工（下文中以"本站"来代替）为例。作者本是北漂的屌丝小码农一枚，没有太多预算，所以本站用的是一台512M，双核的BurstNet小破VPS。用脚趾丫都能理解的到，自然是服务器的数量越多，配置越高，网站的性能会越好。
在硬件恒定的情况下，线上环境，当然要把它调整到最佳状态。可以使用node.js的clurster模块，充分的利用多核CPU的特性。
我进行过简单的测试，cluster能使本站的qps能提升了50%，还是非常给力的，下边的继续优化的瓶颈应该就是I/O的操作了。
详见官本站的启动脚本app.js第55行
正常情况下，你很happy的加入了cluster后，你可能会发现session经常会偶发性的失效了。
因为使用了cluster，查看名为node的进程后你会发现已经不止一个进程了，而express.js提供的默认session是无法在多进程之间共享的。
其实在默认的情况下，当你使用了production的方式启动了express.js，命令行里都会有警告的日志，提示默认的session存在内存泄露的风险，官方不建议使用。
我们需要找个中间的媒介存放session数据，这个时候就connect-redis模块在天空一阵巨响后闪亮登场了。
首先要安装了redis，再安装了connect-redis依赖后，用app.js第32的方式，就可以顺利调用Redis存放session数据了。

对于生产环境和开发环境，express.js也就是本站使用的node.js框架，提供了一个很便捷的配置方式：

app.configure('development', function() {
  app.use(express.logger('dev'));
  app.use(express.errorHandler());
});

app.configure('production', function() {
  app.use(express.compress());
  app.use(function(req, resp, next) {
    resp.removeHeader('X-Powered-By');
    next();
  });
});

configure方法的第一个参数是环境名，只要你愿意，除了production，其他的环境你可以叫他小黄，小白，旺财，小强...
线上环境相比于开发环境，多了压缩，去除log，取消打印错误堆栈的特征，用这个方法很容易实现。
对于性能的配置上，最重要的一点是网站静态资源的管理，也可以非常大幅度的提升网站的整体请求速度。
一个糟糕的做法，是把静态资源直接挂载在网站的主域下，尤其像BurstNet这种主机在国外的VPS，访问速度本来就不怎么给力。
比如有个叫general.js的文件，我直接放在了botobe.net/general.js下。
这种做法同时也是占用了node.js的处理资源，把更多的任务交给node.js进程（也就是网站所在的VPS）去处理。
通常的做法，是把静态资源给分离出来。比如本站的静态时挂载在百度的App Engine服务器上的。静态的位置是可配置的。
可参考本站的配置文件config.js第7~13行

还有些基本的前端的优化，比如css放在头部，js放在尾部，以及spirit，减少文件请求等等。这里就不做累赘的重复。

b). 对稳定性的需求

如果线上网站的网站三天两头的挂掉，这也不是我们愿意看到的。
上线前也不会有QA进行严格的测试验证，遇到问题宕掉也是正常情况。但是作为一个个人网站，问题的关键在于，服务宕掉后，能迅速的定位出问题出在了哪里。
起初我是直接来翻看nginx的error和access几十兆的文本日志。
这个方法很管用，不过却很繁琐，因为访问你网站的在绝大部分情况下，不会是某个“人”。而是一些搜索引擎的爬虫，以及一些机器的自动请求，他们会测试网站的各种对外暴露的请求是否OK，“404的请求”， “文章不存在在的请求”，“以及错误文章url的请求”等。
在这种情况下，于是我最终使用了(forever.js)[https://github.com/nodejitsu/forever]来运行node。
至此，妈妈再也没有担心过我的网站会宕机了。同时能根据指定的日志文件，更加有效和快捷的定位问题。

c). 对于安全性的需求

这是个很大的话题，最常见的需要考虑的一个是XSS，一个是数据库安全。
这个也不是一句两句能说的清楚了，从本站点的角度来讲，对mongodb的操作，一定要在启动参数中加上bind_ip选项。
对于XSS的操作，如果是一个团队开发的话，则一定要协定 好，XSS的问题要在前端（包括前端模板的拼装）处理或者是后台处理。
这是每个网站开发都会遇到的问题，这里就不作详细介绍。

d). 整体流程的优化

这点对于一个项目的开发来说还是比较重要的。
项目从开发到上线，必然会经历一个从测试环境到正式环境的过程。是不可能直接把开发环境中的代码投放到生产环境中的，尤其是前端的代码，否则会的话，严重的情况下回导致你...................................................被鄙视！
在这个环境转换的过程里，如何做到平滑的过渡，是个很值得思考的问题。
本站则是使用了一个node.js的脚本deploy.js来解决这个问题。
几年的从业经验看来，大部分网站解决线上环境到测试环境前端代码的优化的过程，都是采用的一个脚本自己来完成或是调用ant以及grunt之类的自动化处理的工具来完成包括变量的替换，代码的错误检测，压缩以及优化，自动化测试等等工作。
当然也有其他的方式，这个就取决于整个团队的技术实力是否足够强大，或者是否拥有足够多的时间。
比如人人网就是引入了一个名为OPM的工具（PS. 当然是在人人网鼎盛时期，诸神俱在的时候），支付宝据说使用的一个叫SPM自动工具来完成。
具体的工作原理，我就不在这里班门弄斧了，这些工具也都已经开元并且托管在了Github上，大家可以自行翻阅文档。

e). 后台的管理

相信大部分混迹于互联网的geek们都应该见过workdpress的后台，那可真叫一个赞！
相比于本站，那就是金光灿灿的水晶鞋和底部有一个洞的小塑料拖似得。

我是不会告诉你，这个就是笔者混迹于各个豪华CBD之间的常配装备之一的。
水晶的光芒，刺穿的小破鞋如同海盗船上满是漏洞的破帆似得。

本站自己写了一个专门用于发布文章的发布器进行发布文章。
并且写了个只有寥寥几行html的简易后台操作相应的评论等等。

记在最后：
从谷歌里搜索了一圈，发现介绍node.js部署的文章不是很多，于是尝试着自己撰文一篇。
欢迎交流和拍砖。适合初级选手，大神可略过。
转载请注明出处
http://botobe.net/
本文Github链接

2013.10.28
几个月前来到了鹿妖山，一切安好。
Merci !