python常用的8个框架

python常用的8个框架

1Django

Django是一个开放源代码的Web应用框架由Python写成。采用了MVC的框架模式，即模型M,视图V和控制器C。Django是一个基于MVC构造的框架。但是在Django中，控制器接受用户输入的部分由框架自行处理，所以Django里更关注的是模型(Model)、模板(Template)和视图(Views称为MTV模式。它们各自的职责如下：

模型(Model),即数据存取层处理与数据相关的所有事务：如何存取、如何验证有效性、包含哪些行为以及数据之间的关系等。

模板(Template),即表现层处理与表现相关的决定：如何在页面或其他类型文档中进行显示。视图(View),即业务逻辑层存取模型及调取恰当模板的相关逻辑。模型与模板的桥梁。

2Tornado

Tornado是一种Web服务器软件的开源版本。Tornado和现在的主流Web服务器框架（包括大多数Python的框架)有着明显的区别：它是非阻塞式服务器，而且速度相当快。得利于其非阻塞的方式和对epollf的运用，Tornado每秒可以处理数以千计的连接，因此Tornado是实时Web服务的一个理想框架。

3bottle

Bottle是一个Python Web框架，整个框架只有一个文件，几十K,却自带了路径映射、模板、简单的数据库访问等web框架组件，确实是个可用的框架。初学web开发可以拿来玩玩，其语法简单，部署也很方便。

4webpy

webpy是一个轻量级Python web框架，它简单而且功能强大。webpy是一个开源项目。该框架由已故美国作家、Reddit联合创始人、RSS规格合作创造者、著名计算机黑客Aaron Swartz开发。webpy目前已被很多家大型网站所使用。webpy简单易学，只要有Python基础，掌握webpy就非常容易。

5Flask

Flask是一个使用Python编写的轻量级Web应用框架。其WSGl工具箱采用Werkzeug模板引擎则使用Jinja2。Flask使用BSD授权。Flask也被称为“microframework”，因为它使用简单的核心，用extension增加其他功能。Flask没有默认使用的数据库、窗体验证工具。

6pyramid

Pyramid是一个小型，快速的Python webframework,是Pylons Project的一部分，采用的授权协议是BSD-like license。Pyramid吸取了Zope、Pylons和Django的优点，适合开发大型项目，也适合小项目，拥有非常好的性能。

7scrapy

Scrapy,Python开发的一个快速、高层次的屏幕抓取和web抓取框架，用于抓取web站点并从页面中提取结构化的数据。Scrapy用途广泛，可以用于数据挖掘、！监测和自动化测试Scrapy吸引人的地方在于它是一个框架，任何人都可以根据需求方便的修改。它也提供了多种类型爬虫的基类，如BaseSpider、sitemap爬虫等，最新版本又提供了web20爬虫的支持。Scrap,是碎片的意思，这个Python的爬虫框架叫Scrapy。

8pandas

pandas是基于NumPy的一种工具，该工具是为了解决数据分析任务而创建的。Pandas纳入了大量库和一些标准的数据模型，提供了高效地操作大型数据集所需的工具。pandas提供了大量能使我们快速便捷地处理数据的函数和方法。它是使Python成为强大而高效的数据分析环境的重要因素之一。

可以用WINDOWS完成端口(等同于Linux下的epoll模型)来实现你的需求,以下是简介:

Win32重叠I/O(Overlapped I/O)机制允许发起一个操作，然后在操作完成之后接受到信息。对于那种需要很长时间才能完成的操作来说，重叠IO机制尤其有用，因为发起重叠操作的线程 在重叠请求发出后就可以自由的做别的事情了。在WinNT和Win2000上，提供的真正的可扩展的I/O模型就是使用完成端口（Completion Port）的重叠I/O完成端口---是一种WINDOWS内核对象。完成端口用于异步方式的重叠I/0情况下，当然重叠I/O不一定非使用完成端口不 可，还有设备内核对象、事件对象、告警I/0等。但是完成端口内部提供了线程池的管理，可以避免反复创建线程的开销，同时可以根据CPU的个数灵活的决定 线程个数，而且可以让减少线程调度的次数从而提高性能其实类似于WSAAsyncSelect和select函数的机制更容易兼容Unix，但是难以实现 我们想要的“扩展性”。而且windows的完成端口机制在操作系统内部已经作了优化，提供了更高的效率。所以，我们选择完成端口开始我们的服务器程序的 开发。

阻塞socket和非阻塞socket的区别： 1、读操作 对于阻塞的socket,当socket的接收缓冲区中没有数据时，read调用会一直阻塞住，直到有数据到来才返回。当socket缓冲区中的数据量小于期望读取的数据量时，返回实际读取的字节数。

阻塞socket和非阻塞socket的区别： 1、读操作 对于阻塞的socket,当socket的接收缓冲区中没有数据时，read调用会一直阻塞住，直到有数据到来才返回。当socket缓冲区中的数据量小于期望读取的数据量时，返回实际读取的字节数。

引言

有人说，Java确实过于臃肿，经常“小题大做”。但PHP、Nodejs扩展方面短板太明显，做小应用可以，大型应用就玩不转了。另外，JavaEE领域有太多优秀框架可以解决开发效率的问题，事实上借用Spring等框架，开发的效率丝毫不亚于PHP。

互联网时代的Java开发者，很多都不是基于Servlet和EJB来开发Web应用，而且WebLogic、WebSphere也只会存在于大公司的存量系统中，互联网公司的Java都是Tomcat的世界。

那么，微服务能完全弥补JavaEE的短板吗对于JaveEE来说，微服务扮演的，究竟是拯救者还是掘墓人的角色

在Java问世之初，包括IBM、BEA、Oracle在内的一些巨头公司，看到了Java作为一门杰出的Web编程语言可能给他们带来的巨大商机。那么如何通过一门编程语言来赚钱呢答案就是，使用这门语言构建复杂无比的服务器，让那些大公司支付一大笔费用来购买这些服务器。于是紧接着就出现了JavaEE规范、JSR规范，以及WebLogic、WebSphere等服务器中间件。

在这些服务器上面部署了大型的程序包，它们运行缓慢，消耗大量的内存。基于这些容器的开发和调试对开发人员来说简直就是噩梦，作为对他们的补偿，他们从雇主那里获得了丰厚的报酬。

因为耗资巨大，几乎找不到一家公司可以使用合理的费用长时间地支持Java。如果你要用Java构建一个网站，你必须支付一大笔费用来运行这些服务器，哪怕你只用到了Servlet容器。在很长一段时间里，Java被用在企业和公司里，因为只有这些大公司能够负担得起数百万美元的服务器费用，并为那些企业级开发人员支付高额的薪水。

RodJohnson在2003年发布了Spring框架，Spring提供了IoC和对POJO的支持，帮助开发人员逃脱EJB魔掌。开发效率因此得到大幅的提升，大量开发人员转向Spring，把EJB丢在一边。应用服务器开发商看到了这一点，他们在JavaEE5里提供了一些可以减轻开发人员负担的特性。可惜的是，Spring被一路追捧，人们几乎把它跟JavaEE容器混为一谈，它仍然运行在JavaEE的Servlet容器里，这些容器沿用的是十年前的设计，并没有考虑到多核CPU和NIO。

在这期间，PHP奋起直追。PHP使用更少的内存和资源，得到很多公司的支持。一些CMS平台，比如WordPress、Drupal等都是基于PHP构建的，这些平台吸引了大批PHP开发人员。不过，虽然PHP仍然是现今最流行的编程语言，但它也有自己的短板。它运行速度不是很快，而且难以横向扩展。

2009年，RyanDahl启动了Nodejs项目，它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当，Nodejs可以极大地提升响应速度，单个服务器的吞吐量可以媲美一个JavaEE服务器集群。Nodejs是一个很好的作品，但它也有自己的局限性。Nodejs难以扩展，也难以与遗留的系统集成。

2014年，Undertow出现了，它是一个基于Java的非阻塞Web服务器。从#的测试结果来看，在一个价值8000美金的戴尔服务器上，它可以每秒钟处理几百万个请求，而谷歌需要使用一个集群才能处理一百万个同样的请求。它是轻量级的，它的核心部分只需要1M内存，它还包含了一个内嵌的服务器，这个服务器使用不到4M的堆内存。

基于UndertowCore构建的LightJavaFramework是一个微服务容器，它支持设计驱动及生成代码，并支持运行时安全和运行时验证。

JavaEE厂商多年前，JavaEE厂商，比如Oracle和IBM，他们花费数亿美元开发应用服务器(WebLogic和WebSphere)，这些服务器以数百万的价格卖给了大型组织。但现在这些服务器卖不动了，因为JBoss迅速抢占了市场份额，Oracle对JavaEE的支持正在走下坡路：

#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee

随着微服务越来越多地受到关注，这些应用服务器很难有好的销量，因为这些服务器更适合用来部署单体应用。有一个包含了数百个EJB的应用，为了在WebLogic上测试一行代码改动，居然用了45分钟时间。

JavaEE客户

从客户角度来看，耗费巨资购买这些服务器是不值得的，因为JavaEE所承诺的未必都是真的。一个为WebSphere开发的应用无法部署在WebLogic上，所以你需要花更多的钱去升级服务器，因为厂商可能不再支持旧版的服务器，而这样的更新会花费你数百万美元。

于是一些聪明人不禁要问，为什么我们要把应用部署在这些庞然大物上为什么我们要把应用打包成一个ear包或war包，而不是jar包为什么我们不能把大型的应用拆分成更小的块，让它们可以独立部署和扩展

微服务

微服务是这些问题的解药。Wikipedia把微服务定义为“一种软件架构风格，复杂的应用由一些独立的进程组成，这些进程使用与语言无关的API进行交互。这些进程服务规模很小，高度离散，聚焦在一个很小的任务上，使用模块化方式来构建系统”。

微服务架构让构建应用变得更加容易，而且应用被拆分成单独的服务，这些服务可以被任意组合。每个服务可以被独立部署，也可以被组合成一个应用。这些服务还可能会被其他应用依赖。它加快了服务的开发速度，因为只要定义好接口，服务可以并行开发。

微服务具备弹性和伸缩性。微服务不只依赖单个服务器和部署，它们可以被发布到多个机器上，或者多个数据中心及其它任何可用的区域。如果一个服务失效，可以启动另外一个。因为整个应用被分解成了微服务(小型服务)，可以很容易地对其中某些热门的服务进行横向扩展。

如果你曾经使用过COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就会知道服务和组件并不是什么新生事物。企业在使用组件方面存在的一个最大问题是他们依赖大型的硬件服务器，并在同一个服务器上运行很多应用。我们有EJB、WAR包和EAR包，以及各种组件包，因为服务器资源太过昂贵，要尽可能地物尽其用。

不过从最近几年的发展情况来看，之前的方式有些落伍。操作系统服务器一直在变化，虚拟资源可以被当成组件发布，比如EC2、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势，硬件、云技术、多核CPU和虚拟技术也在发展，所以我们要改变以前的开发方式。

在开始新项目的时候不要再使用EAR包或WAR包了。现在我们可以在Docker里运行JVM，Docker只不过是一个进程，但它可以表现得像一个操作系统一样。Docker运行在云端的操作系统上，而云端的操作系统运行在虚拟机里，虚拟机运行在Linux服务器上。这些服务器不是归谁所有，而是被很多互不相识的人共享。如果出现流量高峰怎么办很简单，使用更多的服务器实例。这就是为什么要把Java微服务运行在一个单独的进程里，而不是JavaEE容器或servlet容器。

微服务一般会提供基于HTTP/JSON的API端点。这样可以很容易地与其他服务(开源或闭源的)集成，只要这些服务提供了HTTP/JSON接口。服务可以通过更有意义的方式被消费、被组合。EC2、S3及其他来自Amazon(或其他公司)的服务就是最好的例子。基础设施会成为应用程序的一部分，而且它们是可编程的。

使用微服务架构的应用程序应该是模块化、可编程和可组合的。微服务之间可以相互替换。应用程序的局部可以被重写或改进，而不会影响到整个应用。如果所有的组件都提供了可编程的API，那么微服务之间的交互就会变得更简单(永远不要相信那些不能通过curl访问的微服务)。

随着微服务逐渐流行起来，很多厂商开始尝试把他们的JavaEEWeb服务转成微服务，这样他们就可以继续卖他们的过时产品，APIGateway就是这些厂商中的一个。

JasonBloomberg是Intellyx的主席，他在一篇文章里指出了传统Web服务和微服务的区别，并对把传统Web服务转成微服务的趋势提出了质疑：

#/dangers-microservices-washing-get-value-strip-away-hype

微服务不是企业服务总线里的Web服务，也不是传统的面向服务架构，尽管它沿袭了SOA的一些基本概念。从根本上来说，微服务跟SOA是不一样的，因为整个环境已经发生了彻底的转变。

微服务架构的环境是没有边界的：端到端，基于云的应用程序运行在完全虚拟和容器化的基础设施上。容器把应用程序和服务组件化，DevOps为IT基础设施提供框架，帮助自动化开发、部署和管理环境。

虽然容器对微服务来说不是必需的，不过微服务可以很容易地运行在容器里。况且，把非微服务的代码部署在容器里不是一个明智的选择。

Docker和其他容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。Docker简化了微服务的开发，让集成测试变得更简单。

容器有助于微服务开发，但不是必需的。Docker也可以被用来部署单体应用。微服务与容器可以很好地相融并进，不过微服务包含的东西远比容器多!

结论

应用开发的风格这几年一直在变化，而微服务变得越来越流行。大公司把大型应用拆分成可以单独部署的小型应用，这些小型应用被部署在云端的容器里。开源微服务框架LightJava为这些运行在容器里的微服务提供了很多特性，它支持设计驱动，开发者只需要把注意力专注在业务逻辑上，剩下的事情可以由框架和DevOps流程来处理。

那么问题来了，你怎么看

导读目前，Python比较火的三大web框架有Django、Flask和Tornado，要论这三个Web框架哪个更好的话，建议一点，Django帮我们事先搭建了好多，上手会快一些，学习的话可以先从Django学起，然后再学习Flask和Tornado，下面我们就来具体了解一下Python三大web框架的详情。

1、Django

Django是一个开放源代码的Web应用框架，由Python写成。采用了MTV的框架模式，即模型M，模板T和视图V。它最初是被开发来用于管理劳伦斯出版集团旗下的一些以新闻内容为主的网站的，即是CMS(内容管理系统)软件。

2、Flask

Flask是一个使用Python编写的轻量级Web应用框架。其 WSGI工具箱采用Werkzeug ，模板引擎则使用 Jinja2

。Flask使用BSD授权。

Flask也被称为 “microframework” ，因为它使用简单的核心，用 extension

增加其他功能。Flask没有默认使用的数据库、窗体验证工具。

Flask 很轻，花很少的成本就能够开发一个简单的网站。非常适合初学者学习。Flask 框架学会以后，可以考虑学习插件的使用。例如使用 WTForm +

Flask-WTForm 来验证表单数据，用 SQLAlchemy + Flask-SQLAlchemy 来对你的数据库进行控制。

3、Tornado

Tornado是一种 Web 服务器软件的开源版本。Tornado 和现在的主流 Web 服务器框架(包括大多数 Python

的框架)有着明显的区别：它是非阻塞式服务器，而且速度相当快。

得利于其 非阻塞的方式和对epoll的运用，Tornado 每秒可以处理数以千计的连接，因此 Tornado 是实时 Web 服务的一个

理想框架。

关于Python三大web框架的简单介绍，就给大家分享到这里了，当然学习是永无止境的，学习一项技能更是受益终身，所以，只要肯努力学，什么时候开始都不晚，希望大家抓紧时间进行学习吧。

Java NIO ： 同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。

Java AIO(NIO2) ： 异步非阻塞，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理，

NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK14开始支持。

AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持

I/O属于底层操作，需要操作系统支持，并发也需要操作系统的支持，所以性能方面不同操作系统差异会比较明显。另外NIO的非阻塞，需要一直轮询，也是一个比较耗资源的。所以出现AIO