Como deveria ser
a arquitetura do seu serviço escalável, altamente disponível e em tempo real?
Existem muitas opções por aí, mas se você estiver procurando por um template
geral, a arquitetura descrita por Prashant Malik, o responsável pelo time de Mensagens de back end do Facebook em Scaling the Messages Application
Back End, é um
ótimo exemplo a ser considerado.

Apesar de
Messagens ter a tarefa de lidar com mais de 135 bilhões de mensagens por mês, de
e-mails, IM, SMS, mensagens de texto e do Facebook, você pode pensar que esse é
um exemplo de BigArchitecture e não se aplica a sites menores. Mas não. É um
bom exemplo, bem pensado, de uma arquitetura fora do cloud que exibe muitas
qualidades, das quais muitas mães se orgulhariam:

1. Em camadas – os componentes são
   independentes e isolados.
2. Serviço orientado a API – cada camada é conectada
   através de uma interface bem definida, que é o único ponto de entrada para
   acessar o serviço. Isso previne interdependências super complicadas. Os
   clientes se escondem atrás de uma aplicação API. As aplicações usam uma
   camada de dados de acesso.
3. Distribuídas – as camadas são
   distribuídas de forma transparente através dos clusters das máquinas.
4. Lógica de aplicação separada – A lógica da aplicação
   está encapsulada nos servidores das aplicações que fornecem um endpoint da API. A
   lógica da aplicação é implementada em termos de outros serviços. A camada
   do servidor da aplicação também esconde um cache, uma vez que esse é o
   único lugar no qual os dados do usuário são escritos ou recuperados, sendo
   assim o lugar perfeito para o cache.
5. Sem estado (Stateless) – O estado é mantido em uma
   camada da base de dados, camada de caching ou outros serviços, não em
   aplicações ou enfiados em bolsos locais.
6. Componentes de serviços escaláveis –
   Outros serviços que são escaláveis e altamente disponíveis são usados para
   implementar esse serviço. Messagens também usa: Memcache, serviço de indexação de usuário e HayStack.
7. Operações Full Stack – Ferramentas foram
   desenvolvidas para gerenciar, monitorar, identificar
   problemas de performance e atualizar todo o serviço, para cima, para baixo
   e através da pilha.
8. Em células – Mensagens tem como o bloco
   básico da construção do seu sistema um cluster de máquinas e serviços
   chamado célula. Se você precisar de maior captura de energia, as células são
   adicionadas de uma maneira incremental. Uma célula consiste de controles ZooKeeper, um cluster de servidores
   da aplicação, e um armazenamento de metadados.  As células fornecem isolamento, pois quando o
   armazenamento e a aplicação trabalham para processar os pedidos, eles são feitos
   independentemente de outras células. As células podem falhar, ser atualizadas
   e distribuídas através de datacenters independentes de outras células.

As qualidades
de 1-7 são bem conhecidas e distribuídas de uma forma ou de outra. A ideia da célula
não é vastamente distribuída, pois ela aumenta o nível de abstração para 11.

A Salesforce
tem uma ideia parecida chamada pod. Para a Salesforce, cada pod
consiste em 50 nós, servidores Oracle RAC , e servidores de aplicações Java.
Cada pod suporta milhares de consumidores. Vimos outros conjuntos de produtos
shard começarem da mesma maneira. Um shard consistiria em um cluster de banco
de dados e armazenamento que escolhe uma configuração mestre-escravo ou mestre-mestre
em uma unidade altamente disponível e escalável. O Flickr é um exemplo dessa estratégia.

O que é realmente interessante no artigo é
como é feito o gerenciamento de clusters dentro de uma célula, e como o
gerenciamento das células como uma unidade é feito. Essa é a parte difícil de
acertar.

Dessa forma, em um
cluster de máquinas e de nós, os serviços nesses nós podem sair e voltar
a existir a qualquer momento. A configuração pode mudar também a qualquer
momento? Como você mantém todos os sistemas coordenados na célula? ZooKeeper. O ZooKeeper
é usado para alta disponibilidade, sharding, failover e descoberta de
serviços. Todos os recursos essenciais para um cluster de máquinas falíveis.
Dentro de uma célula, os servidores das aplicações formam um anel hash consistente,
e os usuários são fragmentados através desses servidores.  

Mas e as
operações de cross cell, como elas são feitas? O Mensagens tem um Discovery
Service que é como se fosse um
usuário DNS, ele fica em cima das células e mantém um usuário no mapeamento das
células. Se você quiser acessar os dados do usuário, tem que encontrar a célula
correta primeiro, usando o serviço. Na célula, um cliente de lógica distribuída atua
como a interface para o Discovery Service e processa as notificações do
ZooKeeper.

O artigo foi muito bem escrito e tem
muitos detalhes. Vale a pena ler, especialmente se você estiver tentando
entender como estruturar seu próprio serviço.

?

Texto original disponível em http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html