Oi Recentemente, deparei com uma descrição bastante interessante da arquitetura dos Canais Pusher e decidi traduzi-la para você. Na minha opinião, o autor descreveu com muita facilidade abordagens para a construção de uma arquitetura altamente carregada e escalável. Muito provavelmente, o artigo será útil para iniciantes e especialistas de áreas relacionadas.
No escritório da Pusher, temos um pequeno balcão com um número cada vez maior. Ele mostra o número de mensagens entregues por toda a existência de canais de empurrador. Na sexta-feira às 22:20 UTC, o número aumentou em uma categoria e atingiu 10.000.000.000.000. Tem 13 zeros - 10 trilhões.
Você pode pensar que a contagem total de mensagens é uma métrica inchada e inútil. Mas esse número é um indicador-chave do sucesso dos Canais Pusher, nosso produto de comunicação em tempo real. Em primeiro lugar, esse contador reflete a confiança depositada em nós pelos usuários. Em segundo lugar, mede a escalabilidade do nosso sistema. Para aumentar o número, nós da Pusher devemos garantir que os usuários confiem no envio de mensagens ao nosso serviço, e devemos ter certeza de que nosso sistema é capaz de processar essas mensagens. Mas o que devemos entregar 10 trilhões de mensagens? Vamos ver
Cerca de 200.000 mensagens são enviadas por segundo pelos canais de pressão e milhões nos horários de pico. Por exemplo, quando o New York Times usou o serviço para manter seus leitores informados sobre o progresso das eleições presidenciais nos EUA.
Vejamos primeiro os Canais de empurrador como uma grande caixa preta pela qual todas essas mensagens passam:
Pusher Channels é um sistema do tipo publicação-assinatura. Clientes assinam canais (por exemplo, “btc-usd” ou “private-user-jim”), enquanto outros clientes enviam mensagens para eles. Se um milhão de pessoas estiverem inscritas no canal "btc-usd" e alguém enviar o custo real do bitcoin para lá, os canais Pusher precisarão enviar um milhão de mensagens. Fazemos isso em alguns milissegundos.
Um servidor não pode entregar tantas mensagens em tão pouco tempo. Portanto, usamos três técnicas testadas pelo tempo: fan-out, sharding e balanceamento de carga. Vamos ver o que há na caixa preta.
Milhões de assinantes são distribuídos em aproximadamente 170 servidores de borda poderosos, cada um com aproximadamente 20.000 conexões. Cada um desses servidores lembra a lista de canais que são interessantes para seus clientes e os assina no serviço Redis central. Mesmo se 2000 clientes estiverem interessados em "btc-usd" no servidor de borda, ele só precisará se inscrever uma vez. Assim, quando uma nova mensagem chega ao canal, o Redis envia 170 mensagens para servidores de borda, que já enviam 20.000 mensagens para seus assinantes. Essa abordagem é chamada fan-out.
Mas apenas a divulgação não é suficiente para nós, porque ainda há um componente central do Redis através do qual todos os que enviam mensagens passam. Essa centralização limita o número de mensagens enviadas por segundo. Para contornar essa limitação, o serviço Redis central consiste em muitos fragmentos Redis. Cada canal, por sua vez, é anexado ao fragmento Redis com hash de seu nome. Quando o cliente deseja enviar uma mensagem, ele vai para o serviço de descanso. Este último faz o hash do nome do canal e, com base no resultado, determina o fragmento Redis necessário para o qual a mensagem deve ser enviada. Essa abordagem é chamada sharding.
Parece que estamos apenas mudando a centralização de um serviço Redis para um serviço de descanso. Mas não é assim, uma vez que o serviço de descanso em si consiste em cerca de 90 servidores que executam o mesmo trabalho: eles recebem pedidos de publicação, calculam os redis shards e enviam mensagens para eles. Quando um editor deseja enviar uma mensagem, ele vai para um dos muitos servidores de descanso. Essa abordagem é chamada de balanceamento de carga.
Juntos, o fan-out, o sharding e o balanceamento de carga permitem que o sistema tenha um componente central. Essa propriedade é essencial para alcançar a escalabilidade horizontal, que permite o envio de milhões de mensagens por segundo.
Examinamos os componentes centrais do serviço Pusher Channels, mas existem outras partes, como métricas (como obtemos esse número de 10 trilhões), webhooks (como informamos os clientes sobre eventos interessantes), autorização (restrição de acesso a canais), dados sobre ativos usuários, limite de taxa (como podemos garantir que nossos clientes usem exatamente quantos recursos pagaram e que não interfiram com outros clientes). Toda essa funcionalidade adicional deve ser implementada sem sacrificar a largura de banda, o tempo de entrega da mensagem e a disponibilidade do nosso serviço como um todo.