您必须知道的几个Node.js编码习惯

前言

前面的两篇,以sacdl工程为例,简单介绍了Node.js的环境搭建和代码组织。这一篇,做个简单的小结,把涉及到的编码习惯用我个人的理解,提示性的说明一下。

编程,其实就是用特定的语言讲故事、写规则。特定就是习惯,就像中国的方言,掌握了技巧,很快可以交流,剩下的细节慢慢积累就是。

比特币体现了人类去中心化的本质,Node.js也是最能体现人类特质的编程语言之一,比如:一切都是数据流,事事皆回调。下面,让咱们慢慢品鉴一下吧。

1、一切都是数据流

概念理解

Node.js默认提供了Stream模块,即:流,我们在第二篇讲解gulp的时候说起过。作为一个抽象接口,它是Node.js的基础模块,被其他很多模块所使用。

流,最早是linux环境下的概念,与之对应的方法经常是pipe,即:管道(方法)。我个人理解,这种设计非常形象合理。流的概念存在于人类生活的任何场景,数据流,与水流、空气流等具有相同的特性。如:

(1)流,兼具时间和地点两个坐标,时间代表一个过程,地点代表流入、流出(对应发生、结束的编码)位置;

(2)流,是一个时间上的线性过程,而非一个时间点。在时间段内的传输只是部分数据,若要获得完整的数据,就需要花费足够的时间;

(3)流,只能沿着构建在从发生到结束的编码位置的管道传输,在传输的过程中,可以被调整和改变;

再直白一些,流,不可能一下子发生或结束,再快也得有个时间差。就像人类社会,始终以时间为单位,这一刻到下一刻,已经发生变化。而Node.js严格尊重这个现实,无论是远程访问,还是本地请求,每一个data都被分成一段一段数据流(通常是Buffer对象)传输。

因此,Node.js里没有简单拷贝的概念,或者说拷贝其实可以通过流来简单实现。

代码示例

比如:

//引用模块
var fs = require('fs');

var rs = fs.createReadStream('test.md');
var chunks = [],
    size = 0;

//接受数据:一段段的接受
rs.on("data", function (chunk){
  chunks.push(chunk);
  size += chunk.length;
});

//拼接数据,并转换为字符串(**注**:如果 test.md 不是 UTF-8 编码格式的,如果直接
//转换为字符串,可能会出现乱码,这时需要使用其他的模块(比如:iconv-lite)来进行转换)
rs.on("end", function() {
  var data = Buffer.concat(chunks, size);
  var str = data.toString("utf8");
  console.log(str);
});

其实,在Express的编码中,默认也是在处理buffer数据流,上面的方法照样适用。

思维习惯

记住,在Node.js的世界里,无论是处理文件,还是请求远程资源,处理的就是“数据流”,处理方法都是如此。为了直观,还是用第二篇里那张管道图吧:

pipe

进一步:因为任何都是时间的函数,为了节省时间、提高效率,最好的方式,当然是并行处理。也就是说每一个最好使用一个独立的线程,而不影响其他的。事实上,Node.js就是这么处理的,这就是下面要说的回调。看看上面的代码形式,就是典型的回调用法。

2、事事皆回调

概念理解

中文回调这个词,总不能让人一下子就理解得那么透亮。其实,如果按英文callback直译最好,调回虽然直白,但好理解。

“事事皆回调”,是不是有点绝对?其实不然,它贯穿在人类沟通交往的全过程。大到工程项目,小到求助问路,只要是你必须或需要别人帮你干的事,就得用到回调,即:让他人完成并获得明确的回应。让别人为你做某件事,叫事件触发;给一个方法获得该事结束后的结果,就是回调

举个典型的示例:假如你是一位老板,很多事情需要下属去做,然后获得结果。如果下属合格,安排的事情,他(她)会按照要求给你回应,即便没有达到预期的结果,聪明的下属也会及时向你汇报进展。但现实普遍存在的现象是,老板安排的很多事情并不能得到及时回应,这时候你就得亲自过问,要不打电话、要么派秘书或办公室人员去追踪,总之,要有一条通信线路让你得到回馈(无论好坏)。

这里,优秀员工主动汇报工作的行为,以及老板打电话或派人的行为,都是回调方法。很容易想象,假如没有这些回调,我们还能做成什么事,世界会是什么样。一些国字号的企业,为什么效率低下?几个人干着其他公司一个人的活?社会批评说是懒散,是不干活吗?不尽然,其中大部分是不给你回调(或者给你不明确的回调),让你无从干起。

因此,一个优秀的老板,一定是一个会选人、用人和培养人的人,如果员工只知道埋头干活,不知道及时反馈信息,老板一定会有自己的招式应对;一个优秀的员工,一定是一个让老板节省脑力的人,事前、事中、事后都会适时汇报情况。总之,只要想做事、做成事,一个企业或组织会自觉地对信息回调的方法进行优化,降低沟通成本,提高效率。

具体到Node.js的程序,我们形象的比喻一下就是,主线程是老板,子线程(线程池)是员工,而回调就是它们之间的通信方法。使用回调的代码,我们称为异步编程。说白了,就是你干自己擅长的、份内的事,其他的都交给别人去做。即:对主线程而言,是异步,而从局外人来看,是在同步做事情。

注意:Node.js是单进程的(而非单线程,官网解释的很清楚),只不过我们写的js代码仅在单(主)线程运行罢了,回调都放在事件轮循里处理,而事件轮循等底层代码跑在多线程上(即大家公认的线程池)。这部分讨论,我们会在后续章节,比如加密解密部分,结合如何编写CPU密集型程序去深入讨论。

代码示例

具体形式,在前面的文章中用过多次了,这里再举个例子,类比一下:

(1)在前端开发时,我们用d3.js通过Ajax的方式请求数据的代码,可以简化为:

d3.json('/resource.json', function(err, data){
   //code
   console.log("Hello, ", data);
});

console.log("I`m end.");

这里,我们请求的/resource.json,其实就是远程服务器上的资源http://localohost:3000/resource.json,后面紧跟的函数就是回调函数,要在资源请求结束之后,才会调用。所以,`Hello,...必然要出现在I'm end.`之后。

(2)在后台开发时,我们也有与之几乎一样的代码:

var fs = requrie('fs');
fs.readFoile('/resource.json', function(err, data){
   //code
   console.log("Hello, ", data);
});

console.log("I`m end.");

这里,我们请求的/resource.json,其实就是本地的资源resource.json文件,后面紧跟的函数也是回调函数,同样要在资源请求结束之后,才会调用。所以,`Hello,...也会出现在I'm end.`之后。

思维习惯

在Node.js的世界,到处是回调(多数使用callback、next、cb等命名回调函数),到处是异步,当你不自觉的编写了下面的代码,而反复调试,得不到data预期的结果时,要意识到,您已掉进了异步的陷阱,忘记了回调

var fs = requrie('fs');
var data = fs.readFile('/resource.json'); //异步方法

//code
console.log("Hello, ", data);

console.log("I`m end.");

当然,可以这样修改上面的错误代码:

var data = fs.readFileSync('/resource.json'); //同步方法

在很多其他编程语言里,就是这么用的。这样做的好处,就是直观,便于人类直线思考。坏处就是,数据(流)大时,必然需要长时间执行,直接阻塞进程,整个程序只好停下来等着,这就是I/O阻塞

Node.js因为用了回调,js代码所在的(主)线程会把一切回调扔给后台的线程池去处理,而自己一步到底,所以叫I/O非阻塞

进一步:既然“事事皆回调”,那么回调里面也可能有回调,事实上,这种情况非常多。这也是很多人对Node.js畏惧的原因之一,多年的高手也经常栽在上面,于是大家总结有回调大坑的说法,就是回调嵌套太多,流程复杂,难以驾驭。

不过,社区已经提供了很多方案,比如:Async,promise等流程化组件,就能很好的解决这个问题。具体细节,后面在阅读代码时再说。下面说说因为回调而更加棘手的问题——程序异常(错误)的处理。

3、异常要捕捉

回调太多、异常难捕捉,是Node.js被广为诟病的地方。Node.js是单进程的应用,异常如果未被正确处理,一旦抛出,就会引起整个进程死掉。而异常多发生在回调函数里,回调非常复杂的时候,异常很难定位。所以,很多人说,Node.js很快,但很脆弱。有利就有弊,这就是真实的世界。

与之形成鲜明对比的是,使用ruby on rails的小伙伴一定印象深刻,任何一个error发生,RoR抛出的错误信息里,都会明确给出出错的代码位置,而且通常都非常准确。

概念理解

(下面的内容,主要学习引用了这篇文章,NodeJS 错误处理最佳实践,我个人受益匪浅,感谢原作者)

异常,通常分类两种类型,一个是失败:正确的程序在运行时因为其他因素导致的失败,如:内存不足、网络不通、远程服务器塔机等,是可以预期的;另一个是失误,也就是bug,通常是程序员个人的问题,比如敲错了变量名、方法名,甚至逻辑错误等。

我们这里所讲的异常处理,就是第一类失败的情况,能够让正确的程序在任何情况下永远不失败,那才叫健壮。而对于另一种失误的处理,也就是Bug,只能要求程序员个人加强修炼,避免一些低级错误;对于一些深层次的逻辑错误,努力提高调试和测试水平,力争找到问题所在;或者发挥社区力量,群策群力。

失败类型

失败的原因通常是客观存在的,可以在代码里被有效处理。比如:系统本身(内存不足或者打开文件数过多),系统配置(没有到达远程主机的路由),网络问题(端口挂起),远程服务(500错误,连接失败)。主要场景,如:

  • 连接不到服务器
  • 无法解析主机名
  • 无效的用户输入
  • 请求超时
  • 服务器返回500
  • 套接字被挂起
  • 系统内存不足

失误的原因多为主观因素,除非修正错误,否则永远无法被有效处理。主要场景,如:

  • 读取一个 undefined 属性
  • 调用异步函数没有指定回调
  • 传递了错误参数:该传对象的时候传了一个字符串,或其他内容等

处理方法

错误处理并不是可以凭空加到一个没有任何错误处理的程序中的。没有办法在一个集中的地方处理所有的异常。需要考虑任何会导致失败的代码(比如打开文件,连接服务器,Fork子进程等)可能产生的结果。包括为什么出错,错误背后的原因。

更具体点说。对于一个给定的错误,可以做这些事情:

(1)直接处理。有的时候该做什么很清楚。如果你在尝试打开日志文件的时候得到了一个ENOENT错误,很有可能你是第一次打开这个文件,你要做的就是首先创建它。更有意思的例子是,你维护着到服务器(比如数据库)的持久连接,然后遇到了一个“socket hang-up”的异常。这通常意味着要么远端要么本地的网络失败了。很多时候这种错误是暂时的,所以大部分情况下你得重新连接来解决问题。(这和接下来的重试不大一样,因为在你得到这个错误的时候不一定有操作正在进行)

(2)报告给客户端。如果你不知道怎么处理这个异常,最简单的方式就是放弃你正在执行的操作,清理所有开始的,然后把错误传递给客户端。这种方式适合错误短时间内无法解决的情形。比如,用户提交了不正确的JSON,你再解析一次是没什么帮助的。

(3)重试操作。对于那些来自网络和远程服务的错误,有的时候重试操作就可以解决问题。比如,远程服务返回了503(服务不可用错误),你可能会在几秒种后重试。如果确定要重试,你应该清晰的用文档记录下将会多次重试,重试多少次直到失败,以及两次重试的间隔。另外,不要每次都假设需要重试。如果在栈中很深的地方(比如,被一个客户端调用,而那个客户端被另外一个由用户操作的客户端控制),这种情形下快速失败让客户端去重试会更好。如果栈中的每一层都觉得需要重试,用户最终会等待更长的时间,因为每一层都没有意识到下层同时也在尝试。

(4)直接崩溃。对于那些本不可能发生的错误,或者由程序员失误导致的错误(比如无法连接到同一程序里的本地套接字),可以记录一个错误日志然后直接崩溃。其它的比如内存不足这种错误,是JavaScript这样的脚本语言无法处理的,崩溃是十分合理的。(即便如此,在child_process.exec这样的分离的操作里,得到ENOMEM错误,或者那些你可以合理处理的错误时,你应该考虑这么做)。在你无计可施需要让管理员做修复的时候,你也可以直接崩溃。如果你用光了所有的文件描述符或者没有访问配置文件的权限,这种情况下你什么都做不了,只能等某个用户登录系统把东西修好。

(5)记录错误。有的时候你什么都做不了,没有操作可以重试或者放弃,没有任何理由崩溃掉应用程序。举个例子,你用DNS跟踪了一组远程服务,结果有一个DNS失败了。除了记录一条日志并且继续使用剩下的服务以外,你什么都做不了。但是,你至少得记录点什么(凡事都有例外。如果这种情况每秒发生几千次,而你又没法处理,那每次发生都记录可能就不值得了,但是要周期性的记录)。

编码实践

(1)错误的编码方式

下面的代码是不能正确处理异常的。如果不明白,请重新温习一下回调部分,记住“事事皆回调”。

function myApiFunc(callback)
{
    /*
     * 这种模式并不工作
     */
    try {
      doSomeAsynchronousOperation(function (err) { //异步的原因,这里的回调函数被放在另一个线程独立工作,并不在try/catch下工作
        if (err)
          throw (err);
        /* continue as normal */
      });
    } catch (ex) {
      callback(ex);
    }
}

用惯了其他语言进行同步编程,一开始很容易这么写代码。直观上,上面的代码是想要在出现异步错误的时候调用callback,并把错误作为参数传递。他们错误地认为在自己的回调函数(传递给 doSomeAsynchronousOperation 的函数)里throw一个异常,会被外面的catch代码块捕获。

try/catch和异步函数不是这么工作的。回忆一下,回调(异步)函数的意义就在于被调用的时候myApiFunc函数已经执行了(非柱塞),这意味着try代码块已经退出。这个回调函数外面,事实上,并没有try的代码块在作用。如果用这个模式,结果就是抛出异常的时候,程序崩溃了。

(2)怎么传递错误?

Node.js提供了3种基本的传递模式,分别是Throw, Callback,以及 EventEmitter:

  • throw以同步的方式传递异常--也就是在函数被调用处的相同的上下文。如果调用者(或者调用者的调用者)用了try/catch,则异常可以捕获。如果所有的调用者都没有用,那么程序通常情况下会崩溃(异常也可能会被domains或者进程级的uncaughtException捕捉到,详见下文)。

  • Callback是最基础的异步传递事件的一种方式。用户传进来一个函数(callback),之后当某个异步操作完成后调用这个 callback。通常 callback 会以callback(err,result)的形式被调用,这种情况下, err和 result必然有一个是非空的,取决于操作是成功还是失败。

  • 更复杂的情形是,函数没有用 Callback 而是返回一个 EventEmitter 对象,调用者需要监听这个对象的 error事件。这种方式在下面两种情况下很有用,

一种是:当在做一个可能会产生多个错误或多个结果的复杂操作的时候。比如,有一个请求一边从数据库取数据一边把数据发送回客户端,而不是等待所有的结果一起到达。在这个例子里,没有用 callback,而是返回了一个 EventEmitter,每个结果会触发一个row 事件,当所有结果发送完毕后会触发end事件,出现错误时会触发一个error事件。

另一种:用在那些具有复杂状态机的对象上,这些对象往往伴随着大量的异步事件。例如,一个套接字是一个 EventEmitter,它可能会触发“connect“,”end“,”timeout“,”drain“,”close“事件。这样,很自然地可以把”error“作为另外一种可以被触发的事件。在这种情况下,清楚知道”error“还有其它事件何时被触发很重要,同时被触发的还有什么事件(例如”close“),触发的顺序,还有套接字是否在结束的时候处于关闭状态。

其实,callback 和 EventEmitter 可以归为一类,不要同时使用。

(3)怎么使用它们?

通用的准则是:你即可以同步传递错误(抛出),也可以异步传递错误(通过传给一个回调函数或者触发EventEmitter的 error事件),但是不用同时使用。具体用哪一个取决于异常是怎么传递的,这点得在文档里说明清楚。

(4)domainprocess.on('uncaughtException') 用还是不用?

客观上,失败可以被显示的机制所处理。Domain 以及进程级别的uncaughtException主要是用来从未料到的程序错误恢复的,这两种方式不鼓励使用。其实,它们通常被用在整个应用级别,作为一种保障机制,而不是在具体编码过程中。

代码示例

下面的函数会异步地连接到一个IPv4地址的TCP端口。

/*
* Make a TCP connection to the given IPv4 address.  Arguments:
*
*    ip4addr        a string representing a valid IPv4 address
*
*    tcpPort        a positive integer representing a valid TCP port
*
*    timeout        a positive integer denoting the number of milliseconds
*                   to wait for a response from the remote server before
*                   considering the connection to have failed.
*
*    callback       invoked when the connection succeeds or fails.  Upon
*                   success, callback is invoked as callback(null, socket),
*                   where `socket` is a Node net.Socket object.  Upon failure,
*                   callback is invoked as callback(err) instead.
*
* This function may fail for several reasons:
*
*    SystemError    For "connection refused" and "host unreachable" and other
*                   errors returned by the connect(2) system call.  For these
*                   errors, err.errno will be set to the actual errno symbolic
*                   name.
*
*    TimeoutError   Emitted if "timeout" milliseconds elapse without
*                   successfully completing the connection.
*
* All errors will have the conventional "remoteIp" and "remotePort" properties.
* After any error, any socket that was created will be closed.
*/
function connect(ip4addr, tcpPort, timeout, callback)
{
assert.equal(typeof (ip4addr), 'string',
    "argument 'ip4addr' must be a string");
assert.ok(net.isIPv4(ip4addr),
    "argument 'ip4addr' must be a valid IPv4 address");
assert.equal(typeof (tcpPort), 'number',
    "argument 'tcpPort' must be a number");
assert.ok(!isNaN(tcpPort) && tcpPort > 0 && tcpPort < 65536,
    "argument 'tcpPort' must be a positive integer between 1 and 65535");
assert.equal(typeof (timeout), 'number',
    "argument 'timeout' must be a number");
assert.ok(!isNaN(timeout) && timeout > 0,
    "argument 'timeout' must be a positive integer");
assert.equal(typeof (callback), 'function');

/* do work */
}

这个例子很简单,但是展示了上面所谈论的一些建议:

  • 参数,类型以及其它一些约束被清晰的文档化。
  • 这个函数对于接受的参数是非常严格的,并且会在得到错误参数的时候抛出异常(程序员的失误)。
  • 可能出现的失败集合被记录了。通过不同的"name"值可以区分不同的异常,而"errno"被用来获得系统错误的详细信息。
  • 异常被传递的方式也被记录了(通过失败时调用回调函数)。
  • 返回的错误有"remoteIp"和"remotePort"字段,这样用户就可以定义自己的错误了(比如,一个HTTP客户端的端口号是隐含的)。
  • 虽然很明显,但是连接失败后的状态也被清晰的记录了:所有被打开的套接字此时已经被关闭。

Error 对象属性命名约定

强烈建议在发生错误的时候用这些名字来保持和Node.js核心以及Node.js插件的一致。这些大部分不会和某个给定的异常对应,但是出现疑问的时候,应该包含任何看起来有用的信息,即从编程上,也从自定义的错误消息上。

localHostname,localIp,localPort,remoteHostname,remoteIp,remotePort,path,srcpath,vdstpath

hostname,ip,propertyName,propertyValue,syscall,errno

总结

本文讨论的内容,不仅是初学者经常困惑的地方,很多高手也会不自觉的掉进陷阱。理解了流,有效解决了回调和异常,编写Node.js程序就是一个简单且享受的过程。

本文原本想具体讨论Async、domain等非常具体的解决方案的,不过,限于篇幅和时间,只好暂时放在后面文章里说明。参考里,有几篇较好的文章,有兴趣的,自行翻阅吧。

截至本文,我们用4篇文章,首先考查了币圈Node.js的应用情况,简单介绍了Node.js入门知识,为研究学习Node.js应用奠定了基础。接下来,正式进入源码解读阶段,请看下一篇:亿书,一个面向未来的自出版平台,简单介绍之后,我们会从整体上分析它的功能模块布局。

参考

node.js中流(stream)的理解:http://segmentfault.com/a/1190000000519006

Linux管道PIPE的原理和应用: https://www.hitoy.org/pipe-aplication-in-linux.html

在单线程的情况下,NodeJs是如何分发子任务去执行的? http://www.zhihu.com/question/24780826

Node is Not Single Threaded: http://rickgaribay.net/archive/2012/01/28/node-is-not-single-threaded.aspx

Node.js 异步异常的处理与domain模块解析: https://cnodejs.org/topic/516b64596d38277306407936

results matching ""

    No results matching ""