关于Nginx+Gunicorn+uwsgi+后端框架到app架构梳理和思考

今天下午在思考以前一直在疑惑的问题。也就是在拥有nginx这样的服务器存在了为什么还需要uwsgi这样的服务器。他们之间究竟是什么关系。

我一直在疑惑分层的问题，今天也在这里总结写出我的思考。

首先上一个我今天梳理的图片：

 

 

Nginx作为我认为传统意义上的web服务器，一般是认为在最外层也就是暴露在公网上那一层的。其实当我以前还在使用apache服务器的时候就一直在纠结这个问题。当时觉得既然nginx和apache这样的服务器作为http服务器是一件正常而且理所当然的事情。然后他将把所有的消息交由上层的应用直接处理。我当时是这样想的。但是后来我接触了后端，使用了python语言来对web进行开发的时候发现，在nginx和apache 与应用中间似乎还有一段是非透明的，也就是我们今天讨论的主角wsgi，那么wsgi究竟是个什么东西？

 

其实我查了很多资料，资料里面说得最多的就是wsgi就是架起了nginx这种静态服务器与应用框架之间桥梁的东西，这样说非常抽象。我来描述一下今天与?讨论之后我的理解，当我的网站是一个中大型网站的时候，对我们服务的访问将是成千上万的。那么这里面包含着各种各样的服务请求。 nginx作为web服务器将这些请求都收集起来然后主要做一个向背后的真正处理这些请求的应用服务器做转发。 比如nginx收到了1w个请求，其中有3k个请求要求请求flask框架上的某个接口，那么nginx服务器直接将这个请求转发给uwsgi应用服务器。应用服务器监听的端口收到这个请求之后，便开始与框架所在的应用层通信，将该请求按照wsgi的标准交给我们的应用层框架，然后再由引用层将符合标准的数据取出来做处理，处理完毕之后再返回给应用服务器，应用服务器最终将处理好的信息发给nginx再由nginx回给用户。

 

看到这里，其实就可以发现，其实我们常看到的wsgi服务器 根本就不是我们传统意义上理解的nginx和apache这种服务器。而是wsgi_server 应用处理服务器也就是uwsgi gunicorn 和各种框架自带的wsgi开发用的应用处理服务器。理解这点我认为非常重要。 其实抛开nginx不看我们可以把wsgi分成三个部分。 wsgi_server wsgi_middleware and wsgi_application。

 

这个过程看上去非常复杂，而其中的很多细节，现在对我来说是不透明的，因为我现在并没有亲手去试过。

但是我的疑惑其实得到一些解答，也就是为什么拥有像nginx这样的服务器还需要uwgi标准的服务器？试想一下，我们的应用可能拥有各种各样的服务，可能有些使用php有些使用python，如果我只有某一个wsgi的服务器在进行服务，那么他将监听所有来自80端口和443端口的请求，对于无法兼容她们的应用，就无法处理这些请求了。所以我们需要一个能处理各种各样请求并转发的静态服务器也就是nginx服务器这样的角色来做这件事情，然后将对应的请求发给对应的应用服务器进行处理。从而提高效率，分工明确的处理来自互联网的各种各样的需求，也使得背后的逻辑显得更高效和合理。

 

我最近准备找个时间实践一个uwsgi服务器。 这将是更近一步了解服务器方面和socket编程的一个好的契机。现在对我来说这一块还非常不透明。 此篇主要记录了我的理解，不对的地方还请大家多多指出。