두 가지 Python 웹 프레임워크: Django 및 Tornado 비교

다양한 언어 플랫폼 중에서 Python이 가장 많이 등장하는 웹 프레임워크일 것입니다. 그 이유는 py로 프레임워크를 구성하는 것이 매우 간단하기 때문에 휠이 끊임없이 개발되기 때문인 것 같습니다.

다음은 여러분의 참고를 위해 제가 배운 두 가지 py 웹 프레임워크에 대한 설명입니다.

Django

Django는 가장 유명한 py 프레임워크여야 하며, Google App Engine 및 심지어 Erlang에도 영향을 받는 프레임워크가 있습니다. 그것은 영향을 미칩니다.

Django는 완전 자동화된 관리 배경으로 가장 유명합니다. ORM을 사용하고 간단한 객체 정의만 하면 됩니다. 데이터베이스 구조와 모든 기능을 갖춘 관리 백엔드를 자동으로 생성할 수 있습니다.

Django가 제공하는 편리함은 Django에 내장된 ORM이 프레임워크의 다른 모듈과 긴밀하게 결합된다는 의미이기도 합니다.

애플리케이션은 Django에 내장된 ORM을 사용해야 합니다. 그렇지 않으면 이론적으로 프레임워크에서 제공하는 다양한 ORM 기반 편의를 누릴 수 없습니다. ORM 모듈을 제거하지만 이는 개조된 집을 해체하고 개조하는 것과 같습니다. 처음부터 새 장식을 하려면 거친 집에 가는 것이 좋습니다.

Django의 장점은 개발 효율성이 매우 높다는 점이지만, Django를 사용하는 프로젝트는 트래픽이 일정 규모에 도달한 후에 재구성해야 합니다. 성능 요구 사항.

이 분야에 대한 경험은 다음을 참조하세요: http://www.slideshare.net/zeeg/djangocon-2010-scaling-disqus

제 생각에는 Django는 중소 규모의 웹사이트나 대규모 웹사이트에서 제품 프로토타입을 빠르게 구현하기 위한 도구로 적합하다고 생각합니다.

빠른 제품 출시가 왕입니다:

믿거나 말거나, 더 큰 문제는 확장이 아니라 확장해야 하는 지점에 이르렀습니다. . 첫 번째 문제가 없으면 두 번째 문제도 발생하지 않습니다. - http://gettingreal.37signals.com/ch04_Scale_Later.php

===== Django Template= ====

Django의 템플릿 시스템 디자인은 매우 흥미롭고 프레임워크에서 가장 영향력 있고 논쟁의 여지가 있는 부분이 될 것입니다.

Django 템플릿의 디자인 철학은 코드와 스타일을 완전히 분리하는 것입니다. asp.net은 코드/템플릿 분리를 옹호하지만 Django에서는 여전히 혼합될 수 있습니다. 템플릿에서 데이터를 인코딩하고 처리할 가능성을 근본적으로 제거합니다.

예를 들어 asp.net 템플릿에서는 다음과 같이 작성할 수 있습니다.

int i;

for (i==0;i

....

}

%>

Django는 위와 같은 삽입 코드를 전혀 지원하지 않으며 템플릿에 내장된 기능만 사용할 수 있습니다. 실제로 이 "새 언어"는 매우 유용하기 때문에 템플릿에 대한 "새 언어"를 구성합니다. 간단하므로 템플릿을 다른 플랫폼으로 포팅할 수도 있습니다.

대부분의 경우 Django의 템플릿 기능으로 충분하지만 특별한(때때로 "특별"은 그다지 특별하지 않은) 상황에서는 여전히 템플릿 코드에 포함되어야 합니다. , 템플릿 시스템의 규칙에 따라 템플릿 확장을 수행해야 합니다. 때로는 템플릿에 직접 한 줄의 코드를 작성하여 해결할 수 있는 문제가 템플릿 확장으로 구현되면 수십 줄이 넘는 코드가 될 수도 있습니다.

템플릿 프로그래밍이 허용되는지 여부는 Django 템플릿에서 가장 논란이 되는 측면입니다.

Tornado

Tornado( http://www.tornadoweb.org )는 Facebook에서 오픈 소스로 제공하는 프레임워크입니다. 그 철학은 거의 Django의 두 극단에 있습니다.

Tornado는 더 적지만 더 나은 방향을 취하고 있습니다. 권장되지는 않지만 템플릿 기능도 제공하지만 작성자는 템플릿에 약간의 코딩을 허용할 수 있습니다. 한 줄의 py 코드를 직접 삽입하세요).

asp.net과 비교하면 Tornado는 약간 유사하며 그 외에는 AsyncHttpHandler만 구현하므로 모든 것을 직접 구현해야 합니다.

하지만 ORM(mysql의 매우 간단한 캡슐화만 가능)도 없고 세션 지원도 없으며 Django와 같은 자동화된 백엔드도 없습니다. .

대규모 웹사이트라고 가정하면 고성능 요구 사항에 따라 프레임워크의 각 부분을 맞춤 설정해야 하는 경우가 많고 재사용할 수 있는 모듈이 거의 없습니다. ; Django 개발 웹 사이트의 각 부분은 지속적으로 사용자 정의되었으며 Django 프레임워크의 남은 부분은 처음에 tornado가 제공할 수 있는 부분일 가능성이 높습니다.

다른 길은 같은 목적지로 이어진다.

====== HTTP 서버======

Comet/백엔드 비동기 호출을 효율적으로 구현하기 위해 Tornado가 직접 내장되어 있습니다. HTTP 인터페이스.

프런트 엔드는 apache/lighttpd/nginx 등을 추가하지 않고도 브라우저에서 접근할 수 있지만 HTTP 1.1 프로토콜을 완전히 구현하지 않으므로 공식적으로는 문서에서는 사용자가 프로덕션에서 사용하도록 권장합니다. 환경에서는 nginx가 프런트엔드에 사용되고 백엔드는 여러 Tornado 인스턴스에 대한 역방향 프록시입니다.

Tornado 자체는 단일 스레드 비동기 네트워크 프로그램으로, 기본적으로 시작되면 CPU 수에 따라 여러 인스턴스를 실행합니다. 멀티코어 CPU.

====== 단일 스레드 비동기======

웹사이트는 기본적으로 데이터베이스 작업이 있고 Tornado는 단일 스레드이므로 데이터베이스 쿼리가 너무 느리게 반환되면 전체 서버 응답이 막히게 됩니다.

데이터베이스 쿼리는 본질적으로 원격 네트워크 호출입니다. 이상적으로 이러한 작업은 비동기식으로 캡슐화되지만 Tornado는 이를 지원하지 않습니다.

토네이도의 **디자인**이며, 하자가 아닙니다.

높은 트래픽을 수용하는 시스템을 위해서는 데이터베이스 쿼리 속도 문제를 해결해야 합니다!

데이터베이스에 쿼리 성능 문제가 있으면 아무리 전체 시스템을 최적화해도 데이터베이스에 병목 현상이 발생하고 전체 시스템 속도가 느려지게 됩니다!

비동기성은 본질적으로 시스템 성능을 향상시키지는 **않습니다**. 단순히 불필요한 네트워크 응답 대기와 스레드 전환의 CPU 소비를 방지합니다.

데이터베이스 쿼리 응답이 너무 느린 경우 해결해야 할 것은 데이터베이스를 호출하는 프런트엔드 웹 애플리케이션보다는 데이터베이스의 성능 문제입니다.

실시간 반환된 데이터 쿼리의 경우 이상적으로는 모든 데이터가 메모리에 있고 데이터베이스 하드 디스크 IO가 0이어야 합니다. 충분히 빠르면 데이터베이스 쿼리가 충분히 빠르면 프런트 엔드 웹 애플리케이션이 데이터 쿼리를 비동기식으로 캡슐화할 필요가 없습니다.

코루틴을 사용하더라도 비동기 프로그램은 항상 동기 프로그램의 복잡성을 증가시킵니다. 측정해야 할 것은 추가적인 복잡성을 처리할 가치가 있는지 여부입니다.

백엔드에 쿼리가 너무 느려서 우회할 수 없는 경우 Tornaod는 이러한 쿼리를 백엔드에서 독립적으로 HTTP 인터페이스로 캡슐화한 다음 Tornado의 내장된 쿼리를 사용하는 것을 제안합니다. 비동기 HTTP 클라이언트가 호출을 수행합니다.