《
少写一个`var`是如何毁掉我们网站的》文章地址：http://www.tfxk.com/wangyesheji/jianzhanjingyan/0302341462013.htm
这样会在我的匿名函数作用域内创建这个变量,小规模低性能低流量网站设计原则，因此接下来的请求就不会截断这个值。这是新手才会犯的错误，但是在我做的所有调试或测试中都完整不会带来竞争/并提问题。
initial = extractVariables(req.body);
固然程序还不瓦解，但我仍是没有找到线索。在这里最佳实际也没有措施捕获那一行的毛病（手动前端测试，单元测试，过错处置，等等）。确实，我应该做负载测试，然而即便（测试）达到了竞争前提同样不能让我觉得保险。
Trace: at EventEmitter.<anonymous>(/—/node/privacy.js:118:11) at EventEmitter.emit (events.js:81:20)
在4个小时宕机并令上百个用户绝望而归之后，我找到了问题的关键并修复了产品。风雨之后，拨云见日。我们开始对受到影响的用户致歉，清点这次事变的损失并继承工作。但是，缺乏一个要害字带来这样的丧失还是让我感到难以释怀。少写了一个var会让我成为坏人吗,小网站做新闻资讯 细节不能忽视应注意五点？
Tag：我们 网站 如何 一个 我们 网站 如何 一个
恩，这是货真价实的杯具（很负疚我用这个词，shitstorm）。长话短说，现在MelonCard已经被TechCrunch使用，然而所有事情都可能突然涌现问题。从前多少天里，我们对MelonCard进行了宏大的改良，应用NodeJS长轮询机制以及平滑的KnockoutJS动态jQuery Templates前端。在完成站点无缝进级，在达成“所有功效都是最新”目标的同时，成为外观更美、休会更好的产品。为了防止可能产生的不良影响，我们进行了手工测试和单元测试，并为Node联合使用了一整套Vows。实现所有的体系测试，朝着目的全速前进，对吗？事实并没有那么快。
当初我要对你说的是：你应当用过 CoffeeScript并且可能对TameJS很在行。你可能是准确的。我想理解第一次履行NodeJS调用了哪些函数，但这对我的公司是一个不用要的损失。在其余情形下，它可能带来更重大的问题（如果我在会话中错误的使用了变量会如何？）。最主要的是，缺少真正好的错误处理（在Rails，我们通过backtrace跟踪错误并把错误发送给开发团队）以及真正的调试（依附的是grep和less命令）让我感到我们离好的开发差距很远。或者兴许我应当更加警惕。
我们的系统用的是NodeJS，依据用户输入决议他确当前状况，例如用户输入“我正在期待更新这两条记录”，服务器（基于时间戳检查）会返回“你的记录已经是最新的”或者“记录xxx已更新为yyy。”（实际的过程会比这个更加复杂，我们使用了Redis共享变量和会话，并对Rails、mySQL、Redis和Node之间的接口进行安全检查）。（这个过程）看上去十分简单，但当事情不如预期的那样时，即使是简略的NodeJS 代码也会成为噩梦。今天恶梦发生了。
process.on('uncaughtException', function (err) { console.log(['Caught exception', err]); console.trace(); });
app.all('/apps/:user_id/status', function(req, res, next) {
});
错误出现的那一行（或独一返回给我的Node）如下：
译注：
Vows：Node.js的异步行动开发框架
长轮询（long polling）：是Comet的一种实现方法，也是Facebook，Plurk实现动态更新内容的办法，详细原理是发送一个长时光等候的request，当服务器有材料response的时候立即断掉，接着再发送一个新的request。
我的第一个反映是：NodeJS可以很好地处理负载，这是家喻户晓的。50或100个用户不可能让系统崩溃。在得到Ryan Dahl的辅助之后，我们晓得这不是Node自身的问题（后来的结果也验证了这一点）。服务器开始返回异样结果，用户输入“我的记载是a、b和c”然而服务的答复是“你这个蠢货,将CSS按照层叠式结构化重新组织与构建，删掉x、y和z这里的记载是a、b和c。”即使可能断定问题的范畴并可以反复错误，也简直不可能通过Node可怜的错误处理和调试功能解决。采取的方式就是下面的unix命令（是的，我对production进行查问）
你能够设想对这些结果进行分类是件如许可怕的事。结果是，所有的分段测试和单元测试都正常，我已经一筹莫展了。最为重要的是，我们的系统再一次执行了大量的（安全性）会话检讨。例如，假如用户在（阅读器）不同的标签页之间进行登录和退出时，会有大批的“Unauthorized （未受权）”错误弹出（这让打算懂得真正问题的我们更加糊涂）。当我列犯错误的时候，看上去像这样：
处理完今天的日常工作之后，我们碰到了一个正常的新用户注册顶峰（一个小时内有50-100个新用户注册）。忽然之间，所有事件都开始呈现问题，没有一个页面能够畸形工作。咱们的邮箱开端被“你的产品挂掉了”相似的邮件塞满了。我抓起一杯咖啡筹备战役。
看上去很蹩脚是吧？这是个该逝世的策略。我不是个JavaScript专家，但请容许我尽我所能为你说明（或者也刻意看看这里）。在JavaScript里，你可以声明变量为函数（部分）变量或者全局变量（在变量声明/援用的作用域链表上为其增添庞杂性，直到最后肯定为全局变量）。当我没有使用var来申明一个全局变量initial时，它会遍历作用域链表直到全局规模，最后会创立一个全局变量initial。当下一个请求来到时，它会遍历同样的链表并重写该变量（另一个请求依然盼望使用这个变量）。每个请求都会重复这一进程。当服务器试图在接下来的处理中回复每个请求时，它会读到一直被截断的变量，并返回的结果不正常，甚至可以说是荒谬。因而我应当这么修正：
var initial = extractVariables(req.body);
--> [
网站建设之]少写一个`var`是如何毁掉我们网站的
NODE_ENV='production' node/privacy.js | grep "Returned results"
// …
4个小时当前（当我翻到第503页“ Temporarily Unavailable”，这时我的结合开创人对每一位扫兴或好奇的用户回复了致歉的邮件），我意识到问题出在服务器将我的请求输入（请求参数）错误地当成随机用户要求参数,将CSS压缩至一行的十个步骤。确实的说，服务器的设计只会对你的请求返回你的相干信息，但是对你的请求发生了错误的理解。比方你说“我喜欢苹果跟甜瓜”，但是服务告知你“不要傻了，你爱好的是芒果。”所以，虽然（从安全的角度来说）所有都是平安的，但是成果是错的,导航设计与信息架构。为什么我的ExpressJS服务器不能懂得我的恳求呢。我持续追踪发明了下面的代码：
(责任编辑：网站建设)
少写一个`var`是如何毁掉我们网站的相关文章