通常的部署在过去和现在对我来说如下所示:
+------------------+ +---------+ tcp +-------+ tcp
| PSGI Application |----o| Starman |---->| nginx |<----(internet)
+------------------+ +---------+ +-------+
事实上,我在互联网和实际的 Web 应用程序之间确实有两个完全成熟的 Web 服务器。
由于 nginx 直接内置了 uWSGI 并且 uWSGI 支持 PSGI 协议(protocol),它是 WSGI 的一个分支,我喜欢使用 PSGI 代理(只有 PSGI 没有 HTTP)而不是一个成熟的网络服务器(Starman)。
是否有可用的 PSGI-only 代理解决方案?
最佳答案
PSGI 'protocol'(类似于 WSGI)本质上是一个子程序的调用约定。请求作为子程序调用进入应用程序,并以散列作为参数。应用程序通过子例程的返回值进行响应:一个包含 HTTP 状态代码、HTTP header 和正文的 arrayref。还有更多的东西,但这些是必不可少的。
这意味着如果进程包含 Perl 解释器,则该进程只能实现 PSGI。为了实现这一点,该过程可能在 Perl 中实现,也可能在 C 等可以加载 libperl.so 共享库的语言中实现。同样,如果进程包含 Python 解释器,则它只能实现 WSGI。
您的框图包含三个部分,但实际上 PSGI 应用程序位于 Starman 进程中。所以实际上只有两个部分(尽管两个部分都是多进程容器)。
你说“nginx直接内置了uWSGI”。这并不意味着 WGSI 应用程序在 Nginx 进程内运行。这意味着 WSGI 应用程序在单独的 uwsgi 进程中运行,而 Nginx 使用 uWSGI 协议(protocol)通过 TCP 套接字与该进程通信。这本质上与 Nginx 模型相同,后面有 Starman,但区别在于与 Starman 的套接字连接将使用 HTTP 协议(protocol):
.----------------------. .-----------.
| Starman | | Nginx |
| | HTTP | | HTTP
| .------------------. |<---------| |<-------(internet)
| | PSGI Application | | | |
| '------------------' | | |
'----------------------' '-----------'
HTTP 协议(protocol)确实比 uWSGI 协议(protocol)有更高的开销,因此您可以通过运行一个使用 WSGI 套接字协议(protocol)的应用程序服务器来获得更好的性能,并且可以加载 libperl.so 来实现 PSGI 接口(interface)。 uWSGI can do that :.----------------------. .----------.
| uWSGI | | Nginx |
| | WSGI | | HTTP
| .------------------. |<---------| |<-------(internet)
| | PSGI Application | | | |
| '------------------' | | |
'----------------------' '----------'
关于perl - 是否有一个 Perl PSGI/Plack 服务器可用,它只说 PSGI 而不是说 HTTP?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/48685559/