flask 源码之旅（基础）---什么是 WSGI？

想学习python web编程，WSGI是一个绕不开的概念，那么问题来了，WSGI到底是什么呢？我们又为什么需要它？ 在正式开始对WSGI讲解之前，先让我们的思绪一起穿越历史，来到那个战火纷飞的抗战年代《谍战1938》......

小码是一名英勇的地下党员，他的手里掌握了一份珍贵的敌方情报，急需把这份情报上交给组织处理。

小码遮遮藏藏的找到了领导发生了如下对话：

小码： “领导你那边安全吗？”

领导：“我安全！你那边安全吗？”

小码：“我安全啊！”

于是小码放心的上交了情报，领导欣慰的拍了拍小码的肩：“小伙子干的不错嘛！等通知吧”。

之后，领导带着情报回到了组织，按照组织章程找到专业的情报分析人员。

情报人员经过一顿分析后，再按照组织章程反馈一个分析结果给领导。

领导拿到分析结果后，会把相关情况通知给小码，英勇的小码同志会根据这个情况决定下一步的行动。

现在我们通过图像化的方式表达一下上面的小故事：

猜测一下，在python web里WSGI是故事中的什么角色？

......

是领导？

哈哈哈，其实是组织章程啦！那么故事中的小码、情报传递约定、领导、情报分析员又都是什么呢？

这里我再提供一张图，大家对照一下：

前后两张图片对应一下，是不是就明白了呢。

uWsgi是web服务器，浏览器发起HTTP请求，web服务器接收请求后，会根据WSGI协议调用flask框架实现的web应用程序处理请求，flask app处理完毕后把结果反馈回uWsgi web服务器，web服务器对浏览器进行HTTP应答。

扮演uWsgi这种web服务器角色的大家耳熟能翔的还有apache，而和flask一样的web框架在 python 中还有很出名的django。

web服务器负责接收HTTP请求，解析HTTP请求，根据配置调用后面的处理程序。flask这种框架则可以认为是一套 工具 集，有了这套工具集我们写起来应用处理程序更加的方便，得心应手。

那么Nginx又是什么呢？我们每次google搜索flask部署，nginx+uWsgi+flask此类部署形式充斥屏幕。现在让我们再回到前面的故事......

小码这种地下党员有很多，分布在全国各地。每天的情报像雪花一样从四面八方涌来，领导的能力主要体现在组织能力强，可以胜任调度情报分析人员处理情报的工作，但是这么多情报领导根本就协调处理不过来啊。

这个时候应该怎么办呢？人不够那就加人呗！于是，组织就新增一些办事处，每个办事处任命领导和情报分析小组，问题就自然可以得到解决啊。

但是，小码懵逼了！那么多办事处，他该找那个啊？这个时候，组织又想办法了，其中一个办法就是再成立一个情报接收处。情报一律到接收处，情报接收处再根据一些章程把情报分派到各个办事处去，问题就又解决了。

回归正题，想必大家已经明白了，nginx就是情报接收处。nginx优势在于性能高，可以专门用来接收请求，在Nginx后面我们可以部署多个uWsgi Server，由Nginx把请求分发到各个uWsgi Server上去。

问题又来了~没错，我就是问题宝宝。Nginx是怎么把这些请求传递到各个uWsgi Server上的呢？

上面，我们提到了uWsgi服务器本身是可以直接接收情报的，也就是可以直接处理HTTP请求。那么Nginx会直接再把HTTP请求转发给uWsgi吗？

理论上是可以的啊，但是并没有这么做......因为HTTP作为一个文本协议，实在是不够高效而且浪费空间。那怎么办呢？干脆我们另外想一个更好、更快、更强的协议得了！

于是uwsgi横空出世~(ps：此处有音乐~葫芦娃~葫芦娃~一颗藤上七朵花~滴蜡鞭打全不怕~)

没错，大家和我一起拼写一遍，这个协议叫u-w-s-g-i，不是u-W-s-g-i。uwsgi是协议，uWsgi是服务器程序，Nginx可以通过uwsgi协议和uWsgi服务器交流信息。

于是，新的通信流程变成了这个酱紫：

好了~文章讲到这里已经基本上要结束了，没错是基本上要结束了，也就是还没有结束呢~呵呵

眼尖的童鞋想必已经发现了(我知道并没有人发现......)，我上面在讲故事的时候提到了一个问题：“那么多办事处，小码该找那个上交情报？”的时候，有说到“其中一个办法是成立情报接待处”。那就是说还有其他办法喽~

这里再给大家多讲两句，浏览器在访问web服务的时候一般是通过域名去访问的。

也就是说，小码在上交情报的时候，很少会直接去碰头地点，而是先去一个地方，低声说一句：“天王盖地虎”，会有人告诉他，去某某地方吧，那里有个风一样的男子在等你。

于是办法就来了，既然可以告知小码这种地下党员去那里上交情报，那么我们在小王上交情报的时候让他去办事处A，在小李上交情报的时候告诉他去办事处B就可以了啊。

然后，第二种解决方案的交互图，给各位读者老爷们双手奉上：

最后的最后，把第一种方案的完整交互也补一下：

好了，到这里整个文章真的要结束了！（长吁一口气~）

什么？你问我，如果第一种方案里Nginx性能也不够了怎么办？ 请参考第二种方案，把它和第一种方案结合一下，是不是感觉又能抗的住了，哈哈。

这里有一个萌萌的二维码~请大家使劲扫它，不要客气！