那时聊下Python Web架构，Python Web架构大体分为四类，依次是Full-Stack Web架构、Non Full-Stack Web架构、Asynchronous 触发器架构。
这是小编准
甚么是Web架构
架构的原意是把此基础的，常见的机能都写好了。比如说：URL递送（路由器）、资料库随机存取（ORM）、实用性文件，admin前台管理工作等， 你只须要认知是不是初始化那个架构，让你把心力放到销售业务方法论同时实现上。
架构是不是分好坏
他们一般来说说的某时架构用出来难受，用出来方便快捷，是如前所述甚么样考量的呢？
我坚信相同的合作开发人员讲出的其原因是不那样的。有的是讨厌机能强大的架构，有的是讨厌易上手的架构，有的是讨厌轻巧，实用性灵巧的架构。
有的是合作开发人员讨厌架构机能很全，不必他们造车轮，比如说Django架构，它提供更多的机能十分全面性，比如说(cache、session、进占、auth授权之类)，和它强悍的合作开发工具，提供更多全计划Web合作开发全力支持。他们把此种架构叫作Full-Stack Web架构。
当然机能强悍和全面性的反面是有点复杂（相对的），有点臃肿，不太灵巧。所以Django上手要慢一点，他们造一个车轮替换Django某些内置机能或者使用第三方机能时不太灵巧。
有的是讨厌架构轻巧，灵巧，就像Flask架构那样。跟Django相反，Flask轻巧、灵巧，它的很多机能须要合作开发人员以插件的形式向里安装，你也可以他们定制。这类不提供更多全计划合作开发全力支持的架构，他们叫作Non Full-Stack Web架构。
有的是讨厌速度，讨厌架构本身的速度很快，讨厌I/O性能吞吐高并发，像Tornado和Sanic架构。它们是触发器架构，I/O性能相对就高一些。当然触发器编程的认知难度要大一点。
上面解释了甚么是Full-Stack Web架构、Non Full-Stack Web架构和Asynchronous 异步架构。下面具体介绍这四个下面的代表架构。
一、Django
Django是Full-Stack Web架构的代表，机能十分全面性和成熟，合作开发文档很完备。它在Python Web合作开发架构的占有率应该是第一。Django的宗旨是尽可能的提供更多所有机能，让你用尽可能少的代码完成销售业务。官方的说法是，如果你的合作开发日期十分紧，那么选用Django是正确的做法。 他们他们合作开发的项目也全都选用的Django。
缺点：
在urls.py里实用性URL路由器有点麻烦；
模板不能像php那样在模板插代码；
资料库ORM组装出来的sql语句性能较差；
二、Flask
Flask算是Non Full-Stack Web架构代表，是一个轻量级的Web Framework，它在中国的应用其实挺广的。它的设计目的是帮助构建一个稳定的Web此基础应用。它的灵巧性体现在，它的模块化设计可以轻松适合合作开发人员的需求。Flask跟Django比出来，你可以他们造车轮，也可以是以插件的形式使用第三方库。使用Restful request的风格，很适合合作开发web api，Flask也更加pythonic。
那时正好是愚人节，其实Flask是在2010年4月1日愚人节这天发布的，作者本意是想在这一天整蛊一番的，谁知Flask在后来却越来越火了。
三、Tornado
Tornado其实也是Non Full-Stack Web架构。因为它全力支持触发器，所以就单独说一下。
跟上面Django和Flask比出来的话，好像没啥可说的了，是IO性能优秀。官方说能全力支持1万个并发请求。适合一些高并发项目。
因为一些其原因，我对Tornado的印象不太好。16年的时候公司收购了一个项目，然后我去杭州接手那个项目的技术部分，系统是用Tornado合作开发的。团队是从杭州大厂出来的，设计得十分繁复，说是要全力支持4万并发的销售业务。但是到他们买的那天，销售业务连4千并发都不到。接下来的一年公司为那个项目付出了很大代价。
”
当然在Python3时代，触发器架构还有其他的，比如说Sanic，性能测试对比显示，Sanic比Tornado快几丢丢。猿人学网站除了有Python教程，我也正在写Sanic教程，感兴趣的可以去看看。
说了这么多，如何选择Python Web架构？
如果你要合作开发一个大型项目，比如说电商系统，须要各种各样的机能都具备，那么使用Full-Stack Web架构是第一选择。如果是一个像内容系统，机能有限，不须要面面俱到，那么用Non Full-Stack是第一选择。
Python Web架构大约有30多种，我介绍了几个典型的和运用面比较大的，上面三种在国内的公司中也是运用比较广泛的，能熟练用其中一种做合作开发，应该可以找到个web合作开发工作。
