Minha configuração de servidor para uma API muito usada

Question

Em breve, vou comprar um monte de servidores para um aplicativo que estou prestes a lançar, mas estou preocupado com minha configuração. Eu aprecio qualquer feedback que recebo.

Eu tenho um aplicativo que fará uso de uma API que eu escrevi. Outros usuários / desenvolvedores também farão uso desta API. O servidor de API receberá solicitações e as retransmitirá para servidores de trabalho. A API só terá um banco de dados mysql de solicitações para fins de registro, autenticação e limitação de taxa.

Cada servidor de trabalho faz um trabalho diferente e, no futuro, para dimensionar, adicionarei mais servidores de trabalho para estar disponível para assumir trabalhos. O arquivo de configuração da API será editado para tomar nota dos novos servidores de trabalho. Os servidores de trabalho farão algum processamento e alguns salvarão um caminho para uma imagem no banco de dados local a ser posteriormente recuperado pela API para ser visualizado no meu aplicativo, alguns retornarão sequências de caracteres do resultado de um processo e o salvarão em um banco de dados local .

Esta configuração parece eficiente para você? Existe uma maneira melhor de reestruturar isso? Que questões devo considerar? Por favor, veja a imagem abaixo, espero que ajude a compreensão.

    

Answer 1

Maior disponibilidade

Como Chris menciona, seu servidor de API é o único ponto de falha em seu layout. O que você está configurando é uma infra-estrutura de enfileiramento de mensagens, algo que muitas pessoas já implementaram antes.

Continue pelo mesmo caminho

Você menciona o recebimento de solicitações no servidor da API e insere o trabalho em um banco de dados MySQL em execução em cada servidor. Se você quiser continuar nesse caminho, sugiro remover a camada do servidor da API e projetar os Trabalhadores para cada um dos comandos de aceitação diretamente dos usuários da API. Você poderia usar algo tão simples quanto o DNS round-robin para distribuir cada conexão do usuário da API diretamente a um dos nós do trabalhador disponíveis (e tentar novamente se uma conexão não for bem-sucedida).

Use um servidor de filas de mensagens

Infraestruturas de enfileiramento de mensagens mais robustas usam software projetado para esse fim, como ActiveMQ . Você pode usar a API RESTful do ActiveMQ para aceitar solicitações POST de usuários da API, e os funcionários ociosos podem obter a próxima mensagem na fila. No entanto, isso é provavelmente um exagero para suas necessidades - ele foi projetado para latência, velocidade e milhões de mensagens por segundo.

Use o Zookeeper

Como meio-termo, você pode querer olhar para Zookeeper , embora não seja especificamente um servidor de fila de mensagens. Nós usamos em $ trabalho para este fim exato. Temos um conjunto de três servidores (análogos ao servidor da API) que executam o software do servidor Zookeeper e têm uma interface web para lidar com solicitações de usuários e aplicativos. O front-end da Web, bem como a conexão de back-end do Zookeeper com os trabalhadores, têm um balanceador de carga para garantir que continuemos processando a fila, mesmo que o servidor esteja inativo para manutenção. Quando o trabalho é concluído, o funcionário informa ao cluster do Zookeeper que o trabalho está concluído. Se um trabalhador morrer, esse trabalho será enviado para outro trabalho para ser concluído.

Outras preocupações

• Garanta que as tarefas sejam concluídas no caso de um trabalhador não estar respondendo
• Como a API saberá que uma tarefa foi concluída e recuperada do banco de dados do trabalhador?
• Tente reduzir a complexidade. Você precisa de um servidor MySQL independente em cada nó de trabalho, ou eles poderiam conversar com o servidor MySQL (ou MySQL Cluster replicado) no (s) servidor (es) da API?
• Segurança. Alguém pode enviar um emprego? Existe autenticação?
• Qual trabalhador deve obter o próximo emprego? Você não menciona se as tarefas devem levar 10ms ou 1 hora. Se eles são rápidos, você deve remover as camadas para manter a latência baixa. Se eles forem lentos, você deve ter muito cuidado para garantir que pedidos mais curtos não fiquem presos por trás de alguns pedidos de longa duração.

Answer 2

A maior questão que vejo é a falta de planejamento de failover.

O seu servidor de API é um grande ponto único de falha. Se ele cair, nada funcionará mesmo se os servidores de trabalho ainda estiverem funcionando. Além disso, se um servidor de trabalho ficar inativo, o serviço que esse servidor fornece não estará mais disponível.

Eu sugiro que você veja o projeto Linux Virtual Server ( link ) para ter uma ideia de como funciona o balanceamento de carga e o failover, e para ter uma ideia de como isso pode beneficiar seu design.

Existem muitas maneiras de estruturar seu sistema. Qual é o melhor caminho é uma chamada subjetiva que é melhor respondida por você. Eu sugiro que você faça alguma pesquisa; pesar os tradeoffs dos diferentes métodos. Se você precisar de informações sobre um método de implantação, envie uma nova pergunta.