Estou construindo uma aplicação web encurtadora de URL e gostaria de saber qual a melhor arquitetura para fazê-lo, a fim de fornecer um serviço rápido e confiável.
Eu gostaria de ter dois serviços separados em máquinas diferentes.
- A primeira máquina terá a própria aplicação com apache, nginx, tanto faz.
- O segundo conterá o banco de dados.
- O terceiro será o responsável pelo tratamento das petições de URLs curtas.
ATUALIZAR:
O serviço não é um encurtador de URL. Era mais fácil explicar assim.
Eu só preciso de uma máquina que receba uma consulta http e insira um registro em um banco de dados. E preciso que esta máquina realize esta tarefa simples de uma forma muito eficiente. O sistema rodará em Linux (ainda não conheço a distro) e estou totalmente aberto a qualquer linguagem ou tecnologia. Estava pensando em usar Yaws, Tornado ou Snap para esse serviço, mas ainda não sei e é hora de planejar a arquitetura dessa parte. O banco de dados será construído em Hadoop.
Para a terceira máquina eu só preciso aceitar um tipo de petição http (GET www.domain.com/shorturl), mas isso tem que ser feito muito rápido e deve ser estável o suficiente.
Responder1
Você realmente acha que há necessidade de mais um encurtador de URL? Existem apenasmuitosdeles por aí... a menos que você por acaso tenha conseguido adquirir um nome de domínio muito curto e apropriado, simplesmente não acho que seu site será notado por ninguém. Apenas meus dois centavos, é claro.
Enfim, vamos à parte técnica:
- Em que idioma você escreverá sua inscrição?
- Em qual sistema operacional você planeja executá-lo?
- Você usará software gratuito ou comercial?
É difícil responder sua pergunta sem saber disso.
A única resposta que pode fazer sentido aqui é "evitar Java como uma praga". Um servidor de aplicativos Java é um exagero para muitos aplicativos e com certeza seria um exagero para um servidor tão simples.
Eu escolheria Linux/Apache/MySQL/PHP aqui...seEu poderia pensar em algum bom motivo para começar o projeto, é claro.
Editar:
Ok, agora faz um pouco mais de sentido; mas a sugestão de começar o mais simples possível eentãoa preocupação com a expansão ainda é válida. Se o seu aplicativo for realmente tão simples, qualquer combinação decente de servidor web/linguagem/banco de dados deverá ser capaz de processargrande quantidadede solicitações por segundo em hardware moderno (mas ainda sugiro evitar Java).
Se o desempenho for fundamental, eu escolheria um aplicativo CGI escrito em C;queserá a solução mais rápida possível, muito mais rápida do que qualquer linguagem interpretada ou VM; e fazer com que ele execute INSERTs e SELECTs simples em um banco de dados não deveria serentãodifícil. Mas acho que o LAMP é mais que suficiente para as suas necessidades... eles realmente funcionamFacebooknisso, você sabe?
Responder2
Eles estão apenas registrando dados ou também enviam algo de interesse? Se eles estão apenas registrando, basta usar o apache e lançar os logs do apache no hadoop. Se eles precisarem retornar algum tipo de dado, não está claro para mim como eles obtêm os dados que estão retornando.
Ainda assim, a configuração do Apache para retornar apenas um arquivo estático para qualquer solicitação é muito rápida.
Responder3
Primeiro, sei que você disse que não é um encurtador de URL, mas se for algo semelhante, um RDBMS é uma maneira terrível de armazenar esses dados; como não há relacionamento real entre dois dados, você deseja um mecanismo de armazenamento simples. Considere o Mongo (ou Couch, dependendo do espaço real da sua solução).
Quanto à sua solução, cuidadootimização prematura. Há muitas maneiras de enlouquecer com isso; já que você perguntou, a coisa mais maluca que consigo pensar de imediato seria iniciar o Varnish, escrever todas as suas páginas na VCL e conectá-lo ao memcache no back-end para armazenar e recuperar os dados correspondentes. Mas realisticamente, isso émerdalouco, a menos que você esteja sob cargas absurdas.