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:

• LinkedIn – A Professional Social Network Built with Java™ Technologies and Agile Practices
• LinkedIn Communication Architecture

 

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.