程序员是一个相对来说比较高薪的职业之选，虽然难免有吃青春饭的嫌疑。
不少程序员中年就会隐退，或者被公司辞退。
所以说，程序员的压力不仅仅是编程上的压力，更多的还是市场层次的压力。
要想延长花期，程序员可谓是想尽了办法，不仅想到去做兼职的方法试图维持经济自由，还有的人会选择去程序员客栈这类专业的外包平台做外包挣钱。
作为靠技术吃饭的一员，程序员也不例外，需要经常跟更新自己的知识。
一个合格的程序员除了会java，更多的大家都会去研究研究python。
那么今天的挑战课题就来了，你真的玩转python了么？
咱们先把关于uwsgi你需要知道的基础打牢：
HTTP client ↔ Nginx ↔ uWSGI ↔ Python app
这是一个最基础的uwsgi的位置类的问题，就是它处在python app的哪一个层级。
Http client就是web使用端，顾名思义，就是客户端的端口。
Http client到达nginx这一端，然后就会进入负载均衡的阶段，主要就是接受信号，获得待处理的任务，然后通过负载均衡的几大算法实现合理的任务分配。
并且考虑到上线服务器和响应时间的下限的问题，这已不是关键的一步，做好了可以实现很多功能：诸如高并发之类。
最后就到了我们今天的主人公，uwsgi这一块。
有别于传统的其他软件，（比如java）这里在负载均衡层和app层中间多出来了一个过渡，就是uwsgi。
这里有个点，就其实不是所有的软件都需要ngnix+uwsgi。
因为uwsgi本身就是一个web服务器，可以实现一定的功能。
如果需求量不是很大，其实不加nginx也可以，但如果要实现功能的最优化，还是要搭配使用。
具体nginx和uwsgi怎么配合呢？
主要分为以下四点：
简而言之就是浏览器发送http请求给nginx，nginx进行负载均衡的协调算法。
然后就划分成两条路径，静态请求就交给静态资源处理器之间返还给网页。
而动态请求，这时候就需要调用uwsgi进行逻辑处理。
最终返还给网页前端，实现print out。
可以说逻辑上还是很简单的，但是uwsgi最难理解的点其实是他的抽象性，即他是一个协议。
作为一个二进制协议，他可以携带任何数据和信息。
同时，作为一个线路性协议，他有独特的存在位置。就像我们之前讲的那样。
那到底什么是一个协议呢？这就必须要提到我们的WSGI协议来对比一下了。
不同于线路协议，WSGI是一个传统的通讯协议。
作为通讯协议，主要的作用自然就是定义端口的类型了，比如usb 或者typeC。
而线路协议，顾名思义，就是定义了路径上的数据类型的协议。
是不是差别还蛮大的？
但是名字很像，大家不要弄混了哦~
还有什么想看的，欢迎评论区点赞收藏，我们下期见！
