Este artigo é uma tradução do artigo de Kevin Goldberg “Uma Introdução aos Servidores WSGI Python: Parte 1” blog.appdynamics.com/engineering/an-introduction-to-python-wsgi-servers-part-1 com pequenas adições do tradutor
Uma Breve História dos Servidores WSGI Python
Os servidores
WSGI apareceram porque os servidores da Web na época não conseguiam interagir com aplicativos escritos em Python.
O WSGI (
pronunciado “whiz-gee” com um “g” sólido ) foi desenvolvido por Philip J. Ebi (junto com Ian Biking e outros) no início dos anos 2000. O módulo Apache, conhecido como
mod_python , desenvolvido por Grigory Trubetskoy no final dos anos 90, naquele momento processava a maioria dos aplicativos Python. No entanto,
mod_python não
era uma especificação oficial. Foi simplesmente criado para que os desenvolvedores possam executar o código Python no servidor. Infelizmente, essa abordagem não era segura e os desenvolvedores começaram a procurar uma nova solução.
O WSGI (Web-Server Gateway Interface) é um descendente do
CGI (Common Gateway Interface). Quando a web começou a evoluir, o
CGI cresceu devido ao suporte de um grande número de idiomas e à falta de outras soluções. No entanto, esta solução foi lenta e limitada.
O WSGI foi desenvolvido como uma interface para rotear solicitações de servidores da web (Apache, Nginx, etc.) para aplicativos da web.
Servidor e aplicativo da web
No caso mais simples, o
WSGI consiste em duas entidades principais:
- Servidor Web ( Nginx, Apache , etc.);
- Uma aplicação web escrita em Python.
Princípio de funcionamento:
O servidor da web executa o código e envia as informações e a função de retorno de chamada associadas à solicitação http para o aplicativo da web. Em seguida, a solicitação no lado do aplicativo é processada e uma resposta é enviada ao servidor da web.
Periodicamente, entre o servidor da Web e o aplicativo da Web, uma ou mais camadas intermediárias existem. Tais camadas permitem, por exemplo, equilibrar entre vários aplicativos da Web e o pré-processamento (pré-processamento) do conteúdo entregue.
Aqui estão exemplos de estruturas que suportam o WSGI:
Porquê WSGI?
Você pode perguntar:
"OK, mas por que WSGI?" . Existem várias razões para isso:
- Os servidores WSGI foram projetados para lidar com muitos pedidos de uma só vez. E as estruturas não foram projetadas para lidar com milhares de solicitações e não tomam uma decisão sobre como melhor rotear (solicitações) a partir do servidor da web.
- O WSGI acelera o desenvolvimento de aplicativos da Web escritos em Python. Se você usa uma estrutura (Django ou outra coisa) no desenvolvimento de aplicativos da web, não precisa se preocupar com o modo como sua infraestrutura específica usa o padrão WSGI .
- O WSGI oferece a flexibilidade de modificar componentes da pilha da web sem alterar o aplicativo que funciona com o WSGI .
Os servidores
WSGI estão disponíveis em várias variações. Alguns são direcionados para uma solução fullstack, enquanto outros são adequados para estruturas específicas. Por exemplo, o
Gunicorn trabalha com o
Django imediatamente. Aqui está uma olhada mais de perto nos seis servidores WSGI no mercado hoje:
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy e
Gunicorn .
Bjoern
Bjoern é um servidor WSGI assíncrono escrito em C. Escrito desde o início para ser pequeno e rápido, foi desenvolvido usando
http_parser de Ryan Dahl (criador do Node.js) e o
loop de eventos
Libev de Mark Lehmann.
Com um tamanho de download de apenas 18 KB, consiste em menos de 800 linhas de código. Ele ocupa menos de 1 MB de RAM e não usa
corotinas ou threads.
O Bjoern é totalmente compatível com o
WSGI e é considerado um dos servidores
WSGI de mais alto desempenho.
O Bjoern suporta conexões persistentes e pode ser vinculado a soquetes Unix ou endereços TCP.
Bjoern é considerado mais rápido que Gunicorn e menos inchado que
uWSGI e
Meinheld . Uma das desvantagens deste servidor é a falta de documentação normal com exemplos claros.
uWSGI
O uWSGI foi desenvolvido pela
Unbit (Itália) com o objetivo de se tornar uma solução fullstack capaz de criar serviços de hospedagem. É nomeado após o padrão
WSGI e foi criado como um plug-in para um dos projetos da empresa.
Um projeto amplo e em constante evolução, o
uWSGI permite fazer muito mais do que aplicativos de hospedagem na web. Muitos acham o
uWSGI uma ferramenta poderosa, enquanto outros acham um pouco inchado. A partir da versão 2.0, o uWSGI também suporta o lançamento de aplicativos da web nos idiomas Lua, Perl, Ruby e outros.
mod_wsgi
O mod_wsgi , um módulo do servidor HTTP Apache desenvolvido por Graham Dumpleton (anteriormente um dos desenvolvedores do
mod_python ), fornece a interface
WSGI para aplicativos da web. Compatível com as versões de linguagem Python2 e Python3. Criado como alternativa a outras soluções para integrar aplicativos da web como
CGI ,
FastCGI e
mod_python . Pode ser instalado como um módulo Apache ou via
mod_wsgi express . O segundo método simplifica a instalação para desenvolvedores Python que não estão tão familiarizados com o Apache. Outros benefícios:
• Você não precisa de privilégios de root com uma instalação completa.
• Um ambiente local é criado, o que reduz o risco de impacto negativo nas configurações existentes.
O desenvolvimento de
mod_wsgi como um projeto pode parecer lento devido ao fato de o módulo ser desenvolvido por um desenvolvedor. Outra desvantagem é que a documentação está atualmente mal organizada e pode estar desatualizada.
Atualmente, o foco está na simplificação da implementação do Apache usando
mod_wsgi em ambientes usando o
Docker .
Meinheld
Criado por Yutaka Matsubara, o
Meinheld é um servidor compatível com
WSGI que aproveita o poder do
picoev e do
greenlet para executar E / S assíncronas. Pode ser usado com um servidor HTTP independente ou através do
Gunicorn .
O Meinheld depende de um componente de terceiros chamado greenlet.
O repositório de código-fonte está localizado no
GitHub .
O Meinheld suporta soquetes da Web e inclui vários
monkeypatches sobre outros módulos para funcionalidade aprimorada.
Cherrypy
CherryPy - mais conhecido como uma estrutura Python minimalista para escrever aplicativos da Web, o
CherryPy também vem com um servidor da Web WSGI com pool de threads e suporte para o protocolo HTTP / 1.1. A equipe de desenvolvimento
CherryPy descreve seu servidor Web como um servidor HTTP pronto para produção, alta velocidade e pool de encadeamentos. Ele tem:
• Configuração rápida e fácil;
Escalabilidade;
• Uma solução pequena e fácil de usar para seus aplicativos Python;
Suporte a SSL.
O CherryPy se distingue dos servidores
WSGI mais conhecidos devido à sua facilidade de uso e conveniência do desenvolvedor. Você pode gravar um pequeno aplicativo Web em alguns minutos, executando-o em vários processos e criando apenas um arquivo chamado server.py. Ao combinar o
CherryPy com o Nginx como um servidor proxy, você obtém uma maneira confiável de servir seus aplicativos da web.
CherryPy foi criado por Remy Delon. Ele queria criar uma estrutura que fosse o mais próxima possível dos
principais princípios de desenvolvimento em Python .
Gunicorn
Gunicorn é um
servidor WSGI projetado para uso em sistemas UNIX. O nome é uma versão resumida e combinada das palavras "unicórnio verde". Há um unicórnio verde no próprio local do projeto.
Gunicorn foi portado do projeto Unicorn de Ruby. É relativamente rápido, consome muitos recursos, fácil de lançar e funciona com uma ampla variedade de estruturas da web.
A equipe de desenvolvimento recomenda o uso do
Gunicorn em conjunto com o Nginx, onde o Nginx é usado como servidor proxy.
Conclusão
Neste artigo, os seis servidores WSGI mais populares no momento foram
analisados :
Bjoern ,
uWSGI ,
mod_wsgi ,
Meinheld ,
CherryPy e
Gunicorn . Qual servidor usar para você depende das condições e requisitos do seu aplicativo. A próxima parte analisará o desempenho desses seis servidores WSGI.