4

在我看来，过去和现在的常规部署如下所示：

+------------------+     +---------+ tcp +-------+ tcp
| PSGI Application |----o| Starman |---->| nginx |<----(internet)
+------------------+     +---------+     +-------+

事实上，我在 Internet 和实际的 Web 应用程序之间确实有两个成熟的 Web 服务器。

由于 nginx 直接内置了 uWSGI 并且 uWSGI 支持 PSGI 协议，它是 WSGI 的一个分支，我喜欢使用 PSGI 代理（只有 PSGI 没有 HTTP）而不是完整的 Web 服务器（Starman）。

是否有 PSGI-only-broker 解决方案可用？

4

1 回答 1

5

PSGI “协议”（如WSGI）本质上是子程序的调用约定。请求作为带有哈希作为参数的子例程调用进入应用程序。应用程序通过子例程的返回值进行响应：一个包含 HTTP 状态代码、HTTP 标头和正文的数组引用。还有更多的东西，但这些是必需品。

这意味着只有当进程包含 Perl 解释器时，该进程才能实现 PSGI。为了实现这一点，该过程可以用 Perl 实现，也可以用可以加载 libperl.so 共享库的 C 语言实现。类似地，只有包含 Python 解释器的进程才能实现 WSGI。

您的框图包含三个部分，但实际上 PSGI 应用程序位于 Starman 进程中。所以实际上只有两部分（尽管两部分都是多进程容器）。

您说“nginx has uWSGI directly build in”。这并不意味着 WGSI 应用程序在 Nginx 进程中运行。这意味着 WSGI 应用程序在单独的 uwsgi 进程中运行，Nginx 使用 uWSGI 协议通过 TCP 套接字与该进程通信。这本质上与 Nginx 的模型相同，后面有 Starman，但区别在于与 Starman 的套接字连接将使用 HTTP 协议：

.----------------------.          .-----------.
|       Starman        |          |   Nginx   |
|                      |   HTTP   |           |   HTTP
| .------------------. |<---------|           |<-------(internet)
| | PSGI Application | |          |           |
| '------------------' |          |           |
'----------------------'          '-----------'

HTTP 协议确实比 uWSGI 协议具有更高的开销，因此您可以通过运行一个使用 WSGI 套接字协议并可以加载 libperl.so 来实现 PSGI 接口的应用程序服务器来获得更好的性能。 uWSGI 可以做到这一点：

.----------------------.          .----------.
|        uWSGI         |          |  Nginx   |
|                      |   WSGI   |          |   HTTP
| .------------------. |<---------|          |<-------(internet)
| | PSGI Application | |          |          |
| '------------------' |          |          |
'----------------------'          '----------'
于 2018-02-08T21:14:27.750 回答