번역가 | Li Rui
리뷰어 | Sun Shujuan
Python 웹 애플리케이션은 오랫동안 웹 서버와 통신하는 방법을 설명하는 WSGI(웹 서버 게이트웨이 인터페이스) 표준을 따라왔습니다. 2003년에 처음 소개되어 2010년에 업데이트된 WSGI는 Python 2.2에서 기본적으로 사용할 수 있는 구현하기 쉬운 기능에만 의존합니다. 그 결과, WSGI는 모든 주요 Python 웹 프레임워크에 빠르게 통합되었으며 Python 웹 개발의 초석이 되었습니다.
빨리 2022년을 맞이하세요. Python2는 더 이상 사용되지 않으며 Python에는 이제 네트워크 호출과 같은 비동기 작업을 처리하기 위한 기본 구문이 있습니다. 기본적으로 동기식 동작을 가정하는 WSGI 및 기타 표준은 비동기식의 성능 및 효율성 이점을 활용하지 못합니다. 이는 결국 WSGI가 WebSocket과 같은 고급 프로토콜을 효율적으로 처리할 수 없음을 의미합니다.
비동기 서버 게이트웨이 인터페이스인 ASGI를 입력하세요. WSGI와 마찬가지로 ASGI는 Python 웹 애플리케이션과 웹 서버 간의 공통 인터페이스를 설명합니다. WSGI와 달리 ASGI는 애플리케이션당 여러 비동기 이벤트를 허용합니다. 또한 ASGI는 동기 및 비동기 애플리케이션을 모두 지원합니다. 개발자는 레거시 동기식 WSGI 웹 애플리케이션을 ASGI로 마이그레이션하거나 ASGI를 사용하여 새로운 비동기식 웹 애플리케이션을 구축할 수 있습니다.
WSGI는 일반적으로 애플리케이션 또는 앱이라는 이름의 웹 서버에 Python 함수를 노출하여 작동합니다. 이 함수는 두 가지 매개변수를 사용합니다.
함수에서 반환된 데이터는 응답 본문을 구성합니다.
간단한 애플리케이션 기능은 다음과 같습니다:
def application(environ, start_response): start_response('200 OK', [('Content-Type', 'text/plain')]) return [b'Greetings universe']
WSGI 호환 웹 프레임워크(예: Flask)를 사용하는 경우 프레임워크 자체는 모든 구성 요소와 함께 애플리케이션 기능을 제공합니다. 자동으로 연결됩니다.
WSGI에는 두 가지 단점이 있습니다. 첫째, WSGI는 한 번에 하나의 요청과 응답만 처리하고 응답이 즉시 반환된다고 가정합니다. WebSocket 또는 장기 폴링 HTTP 연결과 같이 오랫동안 유지되는 연결을 처리할 방법이 없습니다.
둘째, WSGI는 동기식입니다. 다중 스레드 연결 풀링을 사용하더라도 각 연결은 응답을 반환할 때까지 차단됩니다. 많은 WSGI 설정은 스레드 풀과 프로세스 풀을 처리할 수 있지만 이는 WSGI 인터페이스 자체의 동기화로 인해 제한됩니다.
ASGI는 외관상 WSGI와 유사합니다. WSGI와 마찬가지로 개발자는 애플리케이션 함수 개체를 정의할 수 있지만 이는 두 개가 아닌 세 개의 매개 변수를 사용하는 비동기 함수입니다.
범위: WSGI 환경과 유사하지만 현재 요청에 대한 정보가 포함된 사전입니다. 명명 규칙이 약간 다릅니다.
send: 애플리케이션이 클라이언트에 메시지를 다시 보낼 수 있도록 하는 비동기 호출 가능 함수입니다.
receive: 애플리케이션이 클라이언트로부터 메시지를 수신할 수 있도록 하는 비동기 호출 가능 함수입니다.
간단한 ASGI 애플리케이션 함수는 다음과 같습니다.
async def application(scope, receive, send): await send({ 'type': 'http.response.start', 'status': 200, 'headers': [ [b'content-type', b'text/plain'], ], }) await send({ 'type': 'http.response.body', 'body': b'Hello, world!', })
WSGI 웹 프레임워크와 마찬가지로 ASGI 웹 프레임워크는 자체 application() 함수를 생성하고 필요에 따라 연결합니다.
ASGI와 가장 분명한 차이점은 함수 전반에 걸쳐 비동기식 메타포를 사용한다는 것입니다. 함수 자체는 비동기식이며 HTTP 헤더와 응답 본문은 두 개의 별도 wait send() 명령을 통해 전송됩니다. 이런 방식으로 함수 자체와 해당 send 명령은 애플리케이션의 호출과 얽혀서 다른 많은 연결에서 동시에 전송될 수 있습니다.
receive는 이 예에서는 사용되지 않지만 비동기 함수이기도 합니다. 다른 작업을 차단하지 않고 요청 본문을 수신할 수 있습니다. 요청과 응답은 이러한 방식으로 서버에 점진적으로 전달될 수 있습니다. 이는 WSGI로는 제대로 수행할 수 없거나 전혀 수행할 수 없는 작업입니다.
ASGI를 사용할 때는 비동기 함수와 비동기 친화적인 라이브러리를 최대한 많이 사용해야 합니다. 동기 전용 코드를 사용하면 문제가 심각해질 수 있으므로 비동기를 사용하는 습관을 들이는 것이 좋습니다. 동기 함수에 대한 긴 호출은 전체 호출 체인을 차단하므로 비동기 사용의 이점이 거의 사라집니다.
장기 실행 동기 호출을 사용할 때 문제가 발생하면 asyncio.run_in_executor를 사용하여 호출을 스레드 풀이나 프로세스 풀에 아웃소싱해야 합니다. 외부 이벤트나 CPU를 많이 사용하지 않는 작업을 기다릴 때마다 스레드 풀을 사용해야 합니다. 프로세스 풀은 CPU 집약적인 로컬 작업에 사용해야 합니다.
예를 들어 웹 애플리케이션에 원격 웹 사이트를 호출할 수 있는 경로가 있는 경우 스레드를 사용해야 합니다. 또는 더 나은 방법은 비동기 HTTP 요청을 만드는 aiohttp 라이브러리를 사용하는 것입니다. Pillow 이미지 라이브러리를 호출하여 이미지 크기를 조정하려면 프로세스 풀과 함께 run_in_executor를 사용해야 할 것입니다. 프로세스 간에 데이터를 주고받는 데 약간의 오버헤드가 있지만 run_in_executor를 사용하면 다른 이벤트가 차단되지 않습니다.
application() 객체를 구현하면 ASGI 웹 애플리케이션을 수동으로 작성할 수 있습니다. 그러나 대부분의 경우 비동기 네이티브 ASGI 중심 Python 웹 프레임워크를 사용하는 것이 더 간단합니다. 다음은 몇 가지 일반적인 ASGI 호환 웹 프레임워크입니다.
Starlette 및 FastAPI: 이러한 새로운 프레임워크(FastAPI는 Starlette를 기반으로 구축됨)는 비동기 우선이므로 모두 ASGI를 지원한다는 것은 놀라운 일이 아닙니다. 웹 애플리케이션을 처음부터 개발하는 경우 이는 Python을 위한 가장 현대적이고 최첨단 웹 프레임워크입니다.
Quart: 주요 Python 웹 프레임워크인 Flask는 ASGI를 지원하지만 Flask는 내부에서 비동기 메타포를 활용하도록 설계되지 않았습니다. GitLab의 Quart는 Flask의 구문과 비유를 사용하지만 비동기 경로 처리기를 허용합니다.
Django 3.0 이상: Django 3.0부터 유명한 Django 웹 프레임워크가 ASGI를 지원합니다. Django 애플리케이션의 비동기 코드 지원은 Django를 ASGI 핸들러에 마운트할 수 있는 기능이 아닌 Django 3.1에 추가되었습니다. 실행 속도가 알려지지 않은 프레임워크의 경우 비동기가 있으면 이를 활용하려는 사용자에게 더 나은 성능이 제공됩니다.
원본 링크: https://www.infoworld.com/article/3658336/asgi-explained-the-future-of-python-Web-development.html
위 내용은 ASGI 설명: Python 웹 개발의 미래의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!