杂谈——Web框架本质 Django

WSGI（Web Server Gateway Interface）：一种通信协议，定义了 Web 服务器与 Web 应用程序间的通信规范。

uwsgi：一种线路协议（不是通信协议），常用于在 uWSGI 服务器与其他网络服务器的数据通信。

uWSGI ：一个全功能的 HTTP 服务器，实现了 WSGI 协议、uwsgi 协议、http 协议等。它要做的就是把 HTTP 协议转化成语言支持的网络协议。比如把 HTTP 协议转化成 WSGI 协议，让 Python 可以直接使用。

我们再来看下WSGI的定义：一种通信协议，定义了 Web 服务器与 Web 应用程序间的通信规范。

Web应用程序本质上也是服务器。

那为什么要把服务端分成Web Server和App Server呢？
在这里插入图片描述

不难看出，对于一个大项目，不同的App 会加载在不同的 Server。

Web Server和App Server的解耦有助于项目后期的维护、更新。Web Server 可以实现负载均衡。同时，一个App Server挂掉，也不至于影响其他App Server。

那解耦后，它们间是如何进行交互的呢？一般来说，是Web 服务器调用 App 服务器。

另外还有一个问题，就是Web Server对于用不同Web框架开发出来的App ，支持性也不同。这种支持性意味着有的Web Server无法调用一些App Server。

由此，我们可以设立一个标准，只要Web Server支持这个标准，框架也支持这个标准，那么他们就可以配合使用。一旦标准确定，双方各自实现。这样，服务器可以支持更多支持标准的框架，框架也可以使用更多支持标准的服务器。

这就是WSGI的由来。

Web服务器架设

1、用户发起Http Request后，首先Nginx服务器会收到，解包、分析。
如果是静态请求，则根据Nginx配置的静态文件目录，返回请求的资源。
如果是动态的请求,Nginx根据配置文件,将请求传递给uWSGI。

2、uWSGI 将接收到的包进行处理，并转发给Django的wsgi。

3、wsgi根据请求调用Django工程的某个文件或函数，处理完后Django将处理结果交给wsgi，wsgi将返回值进行打包，转发给uWSGI。

4、uWSGI接收后转发给Nginx，Nginx最终将处理结果返回给客户端(如浏览器)。

*注:不同的组件之间传递信息涉及到数据格式和协议的转换

可以发现，相比我们在本地开发时，整个流程还多了个Nginx。

我们知道uWSGI是一个服务器，既然有了uWSGI，那为什么还要额外增设一个Nginx（Web Server）呢？

原因是uWSGI的性能不行，在本地跑跑测试还行，但面临高并发的情况就会歇菜了。

再来说下Nginx，它是一个高性能的 HTTP 和反向代理服务，也是一个 IMAP/POP3/SMTP 服务。

Nginx 的优势：

支持反向代理：所谓的反向代理，即既可以充当客户端（浏览器）到目标服务器的代理服务器，又可以接着充当目标服务器到客户端的代理服务器。

安全：因为所有请求都要经过代理服务器，这样就避免了外部程序直接攻击 Web 服务器。

负载均衡：根据请求情况和服务器负载情况，将请求分配给不同的目标服务器（当然处理结果是一样的），保证服务器性能。