Arquitetura do LinkedIn

Esse post é baseado em um artigo do Hurvitz sobre a arquitetura do LinkedIn.

No JavaOne 2008, funcionários do LinkedIn apresentaram duas sessões falando sobre a arquitetura desse site de relacionamento. Podemos ver os vídeos nos links abaixo:

 

O LinkedIn é um dos maiores sites de relacionamento na Internet. Trata-se de uma aplicação Web 2.0 em Java.

Algumas Estatisticas:

 

  • 22 milhões de membros
  • 4+ milhões de únicas visitas por mês.
  • 40 milhões de visualizações por dia.
  • 2 milhões de buscas por dia.
  • 250K de convites enviados por dia.
  • 1 milhão de respostas postadas.
  • 2 milhões de mensagens de e-mail por dia.
Software:
  • Solaris (rodando em plataforma Sun x86 e Sparc)
  • Tomcat e Jetty como servidores de aplicação.
  • Oracle e MySQL como DBs
  • Não usam ORM (como o Hibernate); they use puro JDBC
  • ActiveMQ para JMS. (Particionado pelo tipo de mensagem. Usando MySQL.)
  • Lucene como uma engine de buscas.
  • Spring entre as camadas.
Arquitetura do Servidor
(2003 a 2005)
  • Uma aplicação monolítica.
  • Um único banco de dados (Core Database)
  • O gráfico de rede cacheada em memória no The Cloud
  • Busca de membros usando Lucene. Rodando na mesma máquina que o The Cloud, porque a busca de membros deve ser filtrada de acordo com a busca do usuário de rede.
  • Aplicação Web atualizando o banco de dados principal (Core Database) diretamente. O Core Database atualiza o The Cloud.
( 2006 )
  • Adicionado réplicas de banco (Replica DB’s) para reduzir a leitura no Core Database. As réplicas contém dados read only. Um servidor RepDB gerencia atualizações das réplicas.
  • Movido a engine de Buscas para fora do The Cloud, passando a ser contido em seu próprio servidor.
  • Mudou o lugar onde as atualizações eram feitas, adicionando o Databus. Este é um componente central que distribui atualizações na base. O novo fluxo de atualizações seria:
  1. Alterações originadas da Aplicação Web.
  2. A Aplicação Web atualiza o Core Database
  3. O Core Database envia atualizações para o Databus
  4. O Databus envia as atualizações para: O Replica DB’s, para o The Cloud, e para a engine de Busca
( 2008 )
  • A Aplicação Web não faz mais nada por si só. Ela divide parte das lógicas de negócio em Serviços.
  • A Aplicação Web se torna apenas uma GUI (interface) para o usuário, mas agora ela chama serviços para manipular Perfil, Grupos, etc.
  • Cada Serviço tem seu próprio banco de dados de domínio, ou seja, são partições verticais.
  • A arquitetura permite outras aplicações (através da aplicação Web) acessar o LinledIn. Permite adicionar aplicaçnoes para Recrutar pessoas, adicionar pessoas, etc.
Mais detalhes sobre o The Cloud pode ser encontrado no blog citado no início. O Cache foi implementado em C++ em vez de Java por duas razões.
  • Usar o mínimo de RAM possível.
  • Pausas de Garbage Collection estavam matando eles. [Porém o GC está sendo melhorado desde 2003, isso ainda seria um problema hoje?]
Aparte eles usam o Ehcache para cachear perfis de membros (cerca de 22 milhões de membros). Eles tentaram cachear usando o algoritmo LFU (Least Frequently Used), mas consideraram que o EHcache as vezes bloqueava por 30 segundos para recalcular o LFU, então eles mudaram para o LRU (Least Recently Used)
Arquitetura de Comunicação:
Esse serviço é referente a mensagens permanentes, por exemplo mensagens e e-mail.
  • O sistema inteiro é assíncrono e usa JMS pesadamente.
  • Clientes postam mensagens via JMS
  • Mensagens são depois roteadas via um roteador de serviços para o mailbox apropriado ou diretamente para o processo de email.
  • Entrega de mensagens> tanto Pull ( clientes solicitam suas mensagens), ou Push (envio de email)
  • Eles usam o Spring, com o proprietário LinkedIn Extenção Spring. Usam HTTP-RPC.
Serviço de Actualização na Rede:
Esse serviço é responsável por notificações de vida curta, por exemplo atualização de status de seus contatos. O LinkedIn trabalhou em três grandes interações, detalhadas no blog no início.
Alguns aspectos interessantes da aplicação:
  • Mais de 6500 testes de unidade e de integração.
  • 500 Html Unit testes.
  • Uso de integração continua (Hudson).
  • Uso de EasyMock.
A apresentação termina com algumas dicas sobre escalabilidade. São velhas mas boas:
  • Não pode usar somente um banco de dados. Use muitos banco de dados, particionados horizontalmente e verticalmente.
  • Por causa da partição, esqueça sobre integridade referencial ou cruzamento de domínios com JOINs.
  • Esqueça sobre 100% de integridade de daos.
  • Em larga escala, custo é um problema: hardware, bases de dados, licenças, armazenamento, poder.
  • Depois que você for grande, spammers e scrapers vêm atrapalhar.
  • Cache!
  • Usar fluxos assíncronos.
  • Relatórios e Análises são um desafio, considere eles quando desenhar o sistema.
  • Espere que o sistema falhe.
  • Não subestime a sua trajetória de crescimento.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: