Node.js 现实中的异步与非同步 背景

我正在节点中编写下一个服务器项目。以前的版本是用语言D编写的，这主要是一个同步实现。我们都知道，JS使用了大量异步，这对性能有好处，但很难维护（至少对我来说）。因为节点及其节点模块可能使用不同的异步方法（回调、承诺和等待/异步），这使得代码看起来风格不一致。我正在寻找一种平衡的方法，它不仅可以创建一个高质量和高性能的节点应用程序，而且适合常见的编程风格

问题 在第一轮原型设计之后，我有了我的第一台服务器。当我启动服务器时，它将首先读取配置，然后加载一组模块。我希望它们按顺序加载。但正如我上面提到的，节点模块可能以异步方式工作。我希望模块b能在模块a加载时准确加载，我必须使用

Promise

模式。我不得不疯狂地编写代码，尽管

Promise

已经是一种非常友好的编程方法

不，我去另一个方向。目前我选择了

deasync

，这是节点的gyp模块。它真的可以像这样阻止代码执行

const deasync = require('deasync');

let done = false;
loadModule1Async((err, result) => {
    done = true;
});
deasync.loopWhile(() => !done);

done = false;
loadModule2Async((err, result) => {
    done = true;
});
deasync.loopWhile(() => !done);

或者像这样更神奇

const deasync = require('deasync');

const loadModule1Sync = deasync(loadModule1Async);
const loadModule2Sync = deasync(loadModule2Async);

try {
    loadModule1Sync();
    loadModule2Sync();
} catch(ex) {
    console.error(ex);
}

在我看来，

deasync

方法对我来说更为直接，但我有两个顾虑：

它需要针对目标平台进行编译，因此部署过程对于生产来说会很复杂

我查看了它的发行清单。存在一些已知的严重问题，例如，在某些extream案件中被绞死

问题 即将推出的新功能

async/await

真的能像

deasync

那样做吗？如果由于JS的本性，这永远不会发生。我可能不再想这个了

---

请在前往node的途中与我分享一些指示灯。

我不太了解

deasync

的工作原理，我看了一下，看起来非常方便，但我不认为它可以在服务器中的所有代码中使用

少量性能降级

这取决于你的情况，但可能不仅仅是降级。您正在将所有异步方法包装到代码中，这通常听起来不太好。制定基准可能是个好主意

其他事项：

因为节点及其节点模块可能使用不同的异步方法（回调、承诺和等待/异步）

通常，模块遵循回调风格、承诺风格或两者兼而有之。大多数大型的应用程序都与它们兼容（一般来说，如果您不通过回调，则会返回一个承诺）

async/await

不同，它在承诺之上工作，因此返回承诺的模块方法可以与代码中的

async/await

一起使用

所以回答你的问题，我会在整个代码中坚持承诺，这是现在的趋势，一般来说，与回调相比，它们更容易处理

---

对我来说，

async/await

是最简单的方法，因为它使调用保持异步，但代码是以同步方式编写的。遗憾的是，

async/await

目前只能通过一个标志在Node.js中使用，因此不建议在生产中使用。

感谢您的回复。对不起，我的问题不清楚。现在我更新了我的问题。我不是说我想用sync构建所有东西。只是在某些情况下，例如检查进程是否存在（在启动阶段），我可能需要同步。我想我应该多研究一下

await/async

，看看它是否可以取代

deasync

。我明白了。我认为您的想法是用相同的样式统一所有代码。不管怎么说，如果你只是想要一个“同步风格”的代码，我不会使用

deasync

，因为我认为它不是为了这个目的。我会坚持一些标准的东西，并且已经在JS引擎中实现了。我自己在deasync上玩了一些游戏——不足以写一个答案，但我确实做了一些观察。在一次最多运行一个deasync的情况下，它似乎工作得很好，但如果在deasync期间触发的回调尝试使用自己的deasync，则效果会较差。在主线启动代码中使用deasync可能是合理的，但我不建议在可能在另一个deasync运行时从回调调用的函数中使用它。