域模块已死

使用中的问题

隐式行为

对于一个开发者而言，创建一个新的域然后简单地通过 domain.enter() 运行起来，然后在将来它就可以捕获全部抛出异常者无法观察到的异常。允许模块作者截取不同模块中无关代码的异常而不让原来的代码知道它的自身异常。

下面是一个间接链接模块如何影响另一个模块的例子：

  1. // module a.js
  2. const b = require('./b');
  3. const c = require('./c');
  5. // module b.js
  6. const d = require('domain').create();
  7. d.on('error', () => { /* silence everything */ });
  8. d.enter();
  10. // module c.js
  11. const dep = require('some-dep');
  12. dep.method(); // Uh-oh! This method doesn't actually exist.

因为模块 b 进入了域中且从未退出，任何未捕获的异常将被吞掉。茫茫然地留下模块 c 而为什么它没有运行整个脚本？留下一个可能部分填充的模块 module.exports。这么做与监听 'uncaughtException'是不同的。后者明显指全局捕获异常错误，另外一个问题是域在任何 'uncaughtException' 处理程序之前进行处理，并阻止它们继续执行。

另一个问题是如果在事件激发者上没有相关 '错误' 控制，域自动路由错误。这种选择机制对你而言没的选择，它会在整个异步链上自动传播。这个或许一开始看起来有用，但是一旦异步调用是两个或多个模块，其中有一个不包含域的创建者的错误处理程序突然遇到了意想不到的例外，抛出异常的也就不会被作者注意到。

下面是一个简单的例子，说明丢失的 '错误' 处理程序是如何允许的主动域劫持错误的：

  1. const domain = require('domain');
  2. const net = require('net');
  3. const d = domain.create();
  4. d.on('error', (err) => console.error(err.message));
  6. d.run(() => net.createServer((c) => {
  7.   c.end();
  8.   c.write('bye');
  9. }).listen(8000));

即便通过 d.remove(c) 手动移除连接也不会阻止连接错误不会自动捕获。

困扰错误路由和异常处理的故障是不一致的错误如何冒泡。下面是一个例子说明嵌套域怎样在异常发生时向上冒泡异常：

  1. const domain = require('domain');
  2. const net = require('net');
  3. const d = domain.create();
  4. d.on('error', () => console.error('d intercepted an error'));
  6. d.run(() => {
  7.   const server = net.createServer((c) => {
  8.     const e = domain.create(); // No 'error' handler being set.
  9.     e.run(() => {
  10.       // This will not be caught by d's error handler.
  11.       setImmediate(() => {
  12.         throw new Error('thrown from setImmediate');
  13.       });
  14.       // Though this one will bubble to d's error handler.
  15.       throw new Error('immediately thrown');
  16.     });
  17.   }).listen(8080);
  18. });

可以预期嵌套域始终保持嵌套，并且总是将异常传播到域堆栈上。或者那些例外不会自动发生冒泡。不幸的是，这两种情况都会发生，导致可能混淆的行为，甚至可能很难调试时序冲突。

API 缺陷

虽然基于 EventEmitter 的 API 可以使用 bind() ，而错误回调风格的回调可以使用 intercept()，但是隐式绑定到活动域的替代 API 必须在 run() 中执行。这意思是，如果模块作者想用一种机制来支持域，那么就可以使用必须手动实现域自身的支持机制。而不是能够利用已经存在的隐含机制。

错误传递

如果可能的话，跨嵌套域传播错误不是直截了当的。现有文档显示了在请求处理程序中出现错误时如何使用 close() 方法关闭 http 服务器的简单示例。它没有解释的是，如果请求处理程序为另一个异步请求创建另一个域实例，则如何关闭服务器。以下作为错误传播失败的简单例子：

  1. const d1 = domain.create();
  2. d1.foo = true; // custom member to make more visible in console
  3. d1.on('error', (er) => { /* handle error */ });
  5. d1.run(() => setTimeout(() => {
  6.   const d2 = domain.create();
  7.   d2.bar = 43;
  8.   d2.on('error', (er) => console.error(er.message, domain._stack));
  9.   d2.run(() => {
  10.     setTimeout(() => {
  11.       setTimeout(() => {
  12.         throw new Error('outer');
  13.       });
  14.       throw new Error('inner');
  15.     });
  16.   });
  17. }));

即使在域实例被用于本地存储的情况下，使得对资源的访问仍可用，仍然没有办法允许错误从 d2 继续传播到 d1。快速检查可以告诉我们简单地从 d2 域 '错误' 处理程序中抛出将允许 d1 捕获异常并执行它自己的错误处理程序。虽然不是这种情况。在检查 domain._stack 时，您会看到堆栈只包含 d2 。

这可能被认为是 API 的一个失败，但即使确定它在这方面可以运行，还有一个问题，就是当异步执行中的某个分支发生了失败，那么所有进一步的操作都必须终止。在 http 请求处理程序的示例中，如果我们发起几个异步请求，然后每个 write() 方法数据返回到客户端，试图对一个已经关闭的处理调用 write() 方法时会出现更多的错误。关于 异常的资源清理 中对此进行了更多的讨论。

异常的资源清理

下面的脚本包含一个更复杂的示例。它是关于在一个小的资源依赖树中正确资源清理，在一个给定的连接或其任何依赖关系中发生异常的情况下，将脚本分解为基本操作：

  1. 'use strict';
  3. const domain = require('domain');
  4. const EE = require('events');
  5. const fs = require('fs');
  6. const net = require('net');
  7. const util = require('util');
  8. const print = process._rawDebug;
  10. const pipeList = [];
  11. const FILENAME = '/tmp/tmp.tmp';
  12. const PIPENAME = '/tmp/node-domain-example-';
  13. const FILESIZE = 1024;
  14. let uid = 0;
  16. // Setting up temporary resources
  17. const buf = Buffer.alloc(FILESIZE);
  18. for (let i = 0; i < buf.length; i++)
  19.   buf[i] = ((Math.random() * 1e3) % 78) + 48; // Basic ASCII
  20. fs.writeFileSync(FILENAME, buf);
  22. function ConnectionResource(c) {
  23.   EE.call(this);
  24.   this._connection = c;
  25.   this._alive = true;
  26.   this._domain = domain.create();
  27.   this._id = Math.random().toString(32).substr(2).substr(0, 8) + (++uid);
  29.   this._domain.add(c);
  30.   this._domain.on('error', () => {
  31.     this._alive = false;
  32.   });
  33. }
  34. util.inherits(ConnectionResource, EE);
  36. ConnectionResource.prototype.end = function end(chunk) {
  37.   this._alive = false;
  38.   this._connection.end(chunk);
  39.   this.emit('end');
  40. };
  42. ConnectionResource.prototype.isAlive = function isAlive() {
  43.   return this._alive;
  44. };
  46. ConnectionResource.prototype.id = function id() {
  47.   return this._id;
  48. };
  50. ConnectionResource.prototype.write = function write(chunk) {
  51.   this.emit('data', chunk);
  52.   return this._connection.write(chunk);
  53. };
  55. // Example begin
  56. net.createServer((c) => {
  57.   const cr = new ConnectionResource(c);
  59.   const d1 = domain.create();
  60.   fs.open(FILENAME, 'r', d1.intercept((fd) => {
  61.     streamInParts(fd, cr, 0);
  62.   }));
  64.   pipeData(cr);
  66.   c.on('close', () => cr.end());
  67. }).listen(8080);
  69. function streamInParts(fd, cr, pos) {
  70.   const d2 = domain.create();
  71.   const alive = true;
  72.   d2.on('error', (er) => {
  73.     print('d2 error:', er.message);
  74.     cr.end();
  75.   });
  76.   fs.read(fd, Buffer.alloc(10), 0, 10, pos, d2.intercept((bRead, buf) => {
  77.     if (!cr.isAlive()) {
  78.       return fs.close(fd);
  79.     }
  80.     if (cr._connection.bytesWritten < FILESIZE) {
  81.       // Documentation says callback is optional, but doesn't mention that if
  82.       // the write fails an exception will be thrown.
  83.       const goodtogo = cr.write(buf);
  84.       if (goodtogo) {
  85.         setTimeout(() => streamInParts(fd, cr, pos + bRead), 1000);
  86.       } else {
  87.         cr._connection.once('drain', () => streamInParts(fd, cr, pos + bRead));
  88.       }
  89.       return;
  90.     }
  91.     cr.end(buf);
  92.     fs.close(fd);
  93.   }));
  94. }
  96. function pipeData(cr) {
  97.   const pname = PIPENAME + cr.id();
  98.   const ps = net.createServer();
  99.   const d3 = domain.create();
  100.   const connectionList = [];
  101.   d3.on('error', (er) => {
  102.     print('d3 error:', er.message);
  103.     cr.end();
  104.   });
  105.   d3.add(ps);
  106.   ps.on('connection', (conn) => {
  107.     connectionList.push(conn);
  108.     conn.on('data', () => {}); // don't care about incoming data.
  109.     conn.on('close', () => {
  110.       connectionList.splice(connectionList.indexOf(conn), 1);
  111.     });
  112.   });
  113.   cr.on('data', (chunk) => {
  114.     for (let i = 0; i < connectionList.length; i++) {
  115.       connectionList[i].write(chunk);
  116.     }
  117.   });
  118.   cr.on('end', () => {
  119.     for (let i = 0; i < connectionList.length; i++) {
  120.       connectionList[i].end();
  121.     }
  122.     ps.close();
  123.   });
  124.   pipeList.push(pname);
  125.   ps.listen(pname);
  126. }
  128. process.on('SIGINT', () => process.exit());
  129. process.on('exit', () => {
  130.   try {
  131.     for (let i = 0; i < pipeList.length; i++) {
  132.       fs.unlinkSync(pipeList[i]);
  133.     }
  134.     fs.unlinkSync(FILENAME);
  135.   } catch (e) { }
  136. });
  • 当一个新的连接发生时，同时也发生：
    • 打开文件系统上的文件
    • 针对唯一的套接字打开文件管道
  • 异步读取文件块
  • 将块写入 TCP 连接和任何监听套接字中
  • 如果这些资源中的任何一个出错，则通知其它需要清理和关闭的附加资源

正如我们从这个例子中看到的那样，当某些事情发生故障时必须做正确的清理。所有域提供的是异常聚合机制。在这个例子中，即使通过域传递数据的潜在有用能力也很容易通过将需要的资源作为函数参数传递。

一个问题是把域持久化。它是对能够继续执行的简单假设，与文档所述的相反，尽管有一个意外的例外。这个例子说明了这个想法背后的谬误。

当应用程序本身的复杂性增加时，尝试对意外异常进行适当的资源清理变得更加复杂。此示例只有三个基本资源在应用中，并且它们都具有明确的依赖路径。如果应用程序使用诸如共享资源或资源重用之类的东西，清理和测试该清理的能力已经大大提高。

最后，在处理错误方面，域不仅仅是一个值得骄傲的 'uncaughtException' 处理程序。除第三方更隐秘和不可观察的行为以外。

资源传播

域的另一个用例是使用它来沿着异步数据路径传播数据。一个问题是当在堆栈中有多个时，期望何时得到正确的域的模糊性（必须假定）。异步堆栈与其它模块一起工作。还可以依赖于域进行错误处理，同时也有可能用于检索必要的数据。

下面是一个示例，演示了使用域沿着异步堆栈传输数据的失败情况：

  1. const domain = require('domain');
  2. const net = require('net');
  4. const server = net.createServer((c) => {
  5.   // Use a domain to propagate data across events within the
  6.   // connection so that we don't have to pass arguments
  7.   // everywhere.
  8.   const d = domain.create();
  9.   d.data = { connection: c };
  10.   d.add(c);
  11.   // Mock class that does some useless async data transformation
  12.   // for demonstration purposes.
  13.   const ds = new DataStream(dataTransformed);
  14.   c.on('data', (chunk) => ds.data(chunk));
  15. }).listen(8080, () => console.log('listening on 8080'));
  17. function dataTransformed(chunk) {
  18.   // FAIL! Because the DataStream instance also created a
  19.   // domain we have now lost the active domain we had
  20.   // hoped to use.
  21.   domain.active.data.connection.write(chunk);
  22. }
  24. function DataStream(cb) {
  25.   this.cb = cb;
  26.   // DataStream wants to use domains for data propagation too!
  27.   // Unfortunately this will conflict with any domain that
  28.   // already exists.
  29.   this.domain = domain.create();
  30.   this.domain.data = { inst: this };
  31. }
  33. DataStream.prototype.data = function data(chunk) {
  34.   // This code is self contained, but pretend it's a complex
  35.   // operation that crosses at least one other module. So
  36.   // passing along "this", etc., is not easy.
  37.   this.domain.run(() => {
  38.     // Simulate an async operation that does the data transform.
  39.     setImmediate(() => {
  40.       for (let i = 0; i < chunk.length; i++)
  41.         chunk[i] = ((chunk[i] + Math.random() * 100) % 96) + 33;
  42.       // Grab the instance from the active domain and use that
  43.       // to call the user's callback.
  44.       const self = domain.active.data.inst;
  45.       self.cb(chunk);
  46.     });
  47.   });
  48. };

以上表明，尝试使用一个以上的异步 API 借助域来传播数据是困难的。这个例子是固定假设通过在 DataStream 构造函数中赋值 parent: domain.active。然后通过 domain.active = domain.active.data.parent 在用户的回调函数被调用前恢复它。 DataStream 的实例化'连接'回调必须在 d.run() 中运行，而不是简单地使用 d.add(c)，否则将没有活动域。

简而言之，倘若要祈祷有机会运用这样的方式处理问题，需要严格遵守一组很难实施或测试的指导方针。

性能问题

使用域名的显著威慑是开销。使用节点内置的 http 基准，http_simple.js，没有域，它可以处理超 22000 个请求/秒。而如果它运行的是 NODE_USE_DOMAINS=1，则该数字下降到 17000个请求/秒以下。在这种情况下只有一个全局域。如果我们编辑基准，那么 http 请求回调会创建一个新的域实例，性能进一步下降到 15000 个请求/秒。

虽然这可能不会影响每秒只有几百甚至一千个请求的服务器，但开销的数量与异步请求的数量成正比。因此，如果单个连接需要连接到其它几个服务，所有这些都将对最终交付给客户机的等待时间产生影响。

使用 AsyncWrap 并跟踪次数 init/pre/post/destroy 在以上基准中所提及，我们发现所有事件的总和超过每秒 170000 次。这意味着即使为每种类型的设置增加 1 微秒的开销，任何类型的安装或拆除都会导致 17% 的性能损失。当然，这是针对基准的优化方案，但我相信这证明了一种机制，如域尽可能简单方便地运行的必要性。

展望未来

自从 2014 年 12 月以来，域模块已经被软弃用，但由于节点目前暂时没有替代功能，所以还没有彻底被移除。在撰写本文时，AsyncWrap 的 API 的工作正在进行，以及为 TC39 准备的区域的建议。在这种时候，如有合适的功能来替换域，它将经历完整的弃用周期而最终从核心移除。