我们正在考虑node.js作为一个网络平台。但我有一个关键问题，因为我认为我没有得到以下架构node.js：
看起来默认情况下您被迫使用他们的自定义 HTTP 服务器，没有 WSGI 或任何东西？！
看起来当在响应中做一些“真正的计算”（不仅仅是一些 I/O）时，所有的基础设施都被搞砸了，并且ab -n ... -c ...与 Python 相比，每个请求返回大量的时间——Pyramid/Flask 或其他什么？！
所以，作者node.js假设我们只做 I/O 还是我错过了一些非常基本的东西？
您自相矛盾：“默认”和“强制”不兼容。你可以使用任何你想要的 HTTP 库。核心http模块可能被认为是“默认”模块，但没有什么能阻止您使用另一个模块。
JavaScript 是一种单线程语言，而 Node.js 是一种 JavaScript 运行时，而不是像许多其他语言那样产生一个每次响应的线程的 Web 服务器。如果你愿意，你仍然可以为每个响应创建一个线程，并且有一些基于 Node 构建的项目可以做到这一点，但是你失去了 Node 的大部分好处。如果您正在为响应 Web 请求而进行大量计算（并且您有愿意等待您执行此操作的客户），您应该通过许多可用的解决方案之一（网络工作者、线程-a-go-go、child_process 等）。
Node.js 的作者假设您正在编写一个 Web 服务器。本质上，您在 Web 服务器中所做的大多数事情都是 IO，无论该 IO 涉及文件系统、数据库，甚至是用于在其他济贫院进程上排队计算密集型任务的消息总线。
查看您的问题，如果您尝试将它与 Python 和 WSGI 集成，您似乎对 Node.js 是什么有一个基本的误解。Node.js 用于编写 Web 服务器，所以尝试使用它......与 Python 一起使用？在 Python 里面？（我真的不确定你想要完成什么）没有什么意义。
如果您的任务不仅受 I/O 限制，那么您可能不应该将这些任务托管在与 Web 服务器相同的机器上。因此，在 3 中简要提到了消息总线方法。但是，如果您决心这样做，并且确定这些任务不会占用所有 CPU，您应该确定此类任务的流行频率。如果它们出现在每个 Web 请求中，则不应使用 Node.js；您正在放弃其最基本的优势，只留下次要的优势（例如围绕它成长的生态系统）。如果它们很少见，那么您应该通过 2 中可用的许多方法在单独的线程中分离它们。
如果您是基于 Python 的商店，您可能还想考虑Twisted，它是一个用 Python 编写的事件驱动框架。Twisted 还能够将长时间运行的阻塞工作推迟到线程。
最重要的是你首先定义你需要什么以及你的问题是什么。不要仅仅因为每个人都在谈论它而跳上新奇的事物。查看您的需求并使用可以解决它们的东西。