일반적으로 사용되는 여러 Python 웹 프레임워크에 대한 간략한 분석

다양한 언어 플랫폼 중에서 웹 프레임워크가 가장 많이 등장하는 분야는 아마도 Python일 것입니다. 수많은 마이크로 프레임워크와 프레임워크가 있는 세상이 바로 Python에서 프레임워크를 구성하는 것이 매우 간단하기 때문일 것입니다. , 만들기 바퀴는 계속해서 발명됩니다. 그래서

그래서 Python 커뮤니티에는 Python 프레임워크의 장단점에 대한 주제가 항상 있습니다. 몇 가지 주요 Python 프레임워크를 소개하겠습니다.

Django

Django는 Google App Engine, 심지어 Erlang과 같이 가장 유명한 py 프레임워크여야 합니다. 영향을 받는 프레임워크가 있습니다.

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

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

애플리케이션은 Django에 내장된 ORM을 사용해야 합니다. 그렇지 않으면 이론적으로 ORM을 기반으로 프레임워크가 제공하는 다양한 편의를 누릴 수 없습니다. ORM 모듈인데 이게 꽤 되네요. 이미 리모델링한 집을 헐고 리모델링을 하고 싶으면 거친 집에 가서 처음부터 새로 꾸미는 게 낫습니다.

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

Django의 단점은 주로 전체 시스템이 상대적으로 폐쇄적이라는 Django의 주장에서 비롯됩니다.

· 시스템은 긴밀하게 결합되어 있으므로 Django에 내장된 특정 기능이 그다지 좋지 않다고 생각되면 아래에 언급된 ORM 및 템플릿과 같이 선호하는 타사 라이브러리로 교체하기 어려울 것입니다. Django에서는 SQLAlchemy나 Mako를 사용하는 것이 거의 불가능합니다. 패치를 몇 개 적용하더라도 매우 어색한 느낌이 들 것입니다.

· Django와 함께 제공되는 ORM은 SQLAlchemy보다 훨씬 덜 강력합니다. Django를 제외하고 SQLAlchemy는 Python 세계에서 사실상의 ORM 표준이지만 Django는 여전히 이를 고집합니다. 세트. Django의

개발자들도 SQLAlchemy 지원을 논의하고 시도했지만, 비용이 너무 비싸고 다른 Django 모듈과의 통합이 어렵다고 추정됩니다.

· 템플릿 기능은 상대적으로 약하고 Python 코드에 삽입할 수 없습니다. 더 복잡한 논리를 작성하려면 Python을 사용하여 태그 또는 필터를 구현해야 합니다. Django의 템플릿 시스템 디자인은 매우 흥미롭고 프레임워크에서 가장 영향력 있고 논쟁의 여지가 있는 부분이 될 것입니다.

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

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

int i;

for( i= =0;i

....

}

%>

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

대부분의 경우 Django의 템플릿 기능이면 충분하지만 특별한(때때로 "특별"은 그다지 특별하지 않은 경우도 있음) 상황에서는 여전히 템플릿에 코드를 삽입해야 합니다. 템플릿 시스템의 규칙에 따라 템플릿 확장을 수행합니다.

을 템플릿에 직접 한 줄의 코드로 작성하면 해결될 수 있는 문제가 템플릿 확장으로 구현되면 십여 줄이 넘는 코드가 되기도 합니다.

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

Pylons & TurboGears & repoze.bfg

Django 외에 또 다른 큰 것은 Pylons입니다. TurboGears2.x는 Pylons를 기반으로 하기 때문입니다. repoze.bfg도 Pylons 프로젝트의 대규모 프로젝트에 통합되었으며 repoze.bfg는 나중에 별도로 논의되지 않습니다.

Pylons와 Django의 디자인 컨셉은 완전히 다릅니다. Pylons 자체에는 약 2천 줄의 Python 코드만 있지만 Pylons에서 거의 사용하는 일부 타사 모듈도 함께 제공됩니다. Pylons는 하나의 쉘프와 옵션 솔루션만 제공하며 사용자의 선호도에 따라 템플릿, ORM, 양식, 인증 등의 구성 요소를 자유롭게 선택할 수 있습니다. 우리는 종종 Python을 Glue 언어라고 말하므로 Pylons는 Glue 언어로 설계된 Glue 프레임워크라고 확실히 말할 수 있습니다.

Pylons를 선택하는 것은 아마도 자유를 선택하는 것과 같습니다.

· 학습의 악몽인 Pylons는 Made in Pylons가 아닌 많은 타사 라이브러리에 의존합니다. Pylons를 배우려면 이러한 라이브러리를 사용하는 방법도 배워야 합니다. 중요한 점은 때로는 무엇을 배우고 싶은지 알 수 없다는 것입니다. Pylons의 학습 곡선은 Django의 학습 곡선보다 훨씬 높으며

Pylons의 이전 공식 문서는 항상 비판의 대상이었습니다. 다행히 The Definitive Guide to Pylons라는 책이 나중에 출판되었고 이러한 상황은 바뀌었습니다. 이러한 이유로 Pylons는 한때 전문가에게만 적합한 Python 프레임워크로 알려졌습니다.

· 디버깅 악몽은 관련된 모듈이 많기 때문에 오류가 발생하면 문제를 찾기가 어렵습니다. 작성한 프로그램의 문제일 수도 있고, Pylons가 잘못되었거나, SQLAlchemy가 잘못되었거나, formencode에 버그가 있는 것일 수도 있습니다. 어쨌든 매우 지저분합니다

.

. 이 문제는 잘 알고 있어야만 해결할 수 있습니다.

· Pylons를 설치하려면 각각 고유한 버전 번호가 있는 거의 20개의 Python 모듈을 설치해야 합니다. Pylons 버전을 업그레이드하려면 모든 모듈이 호환되지 않을 가능성이 있습니다. . 업그레이드 기본적으로 매우 어렵습니다. 지금까지 Reddit의 Pylons는 여전히

의 골동품 0.9.6에 머물러 있고, SQLAlchemy는 여전히 버전 0.5.3에 있는데, 이는 이와 관련이 있을 것입니다.

Pylons와 repoze.bfg의 통합은 Django의 위상에 도전할 수 있는 다음 프레임워크를 탄생시킬 수 있습니다.

Tornado & web.py

Tornado( http://www.tornadoweb.org )는 Facebook의 오픈 소스 프레임워크로, 그 철학은 Django와 거의 정반대입니다. Tornado는 웹 서버(이 기사에서는 이에 대해 자세히 설명하지 않음)이며 web.py와 유사한 마이크로 프레임워크이기도 합니다.

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

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

글쎄, 실제로 템플릿, 국제 지원, 심지어 내장 OAuth/OpenID 모듈까지 있어 제3자 로그인을 용이하게 합니다. 실제로 HTTP 서버를 직접 구현합니다.

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

고성능 요구 사항에 따라 프레임워크의 각 부분을 사용자 정의해야 하는 경우가 많고 재사용할 수 있는 모듈이 거의 없다고 가정합니다. Django로 개발된 웹사이트, 각각 지속적인 사용자 정의 후에 Django 프레임워크에 남은 것은 tornado가 처음부터 제공할 수 있는 것일 가능성이 높습니다.

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

HTTP 서버

Tornado는 HTTP 인터페이스에 대한 Comet/백엔드 비동기 호출을 효율적으로 구현하기 위해 HTTP 서버를 직접 내장합니다.

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

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

단일 스레드 비동기

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

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

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

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

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

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

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

으로 캡슐화할 필요가 없습니다.

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

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