A configuração do meu servidor para uma API muito usada

Em breve, comprarei vários servidores para um aplicativo que estou prestes a iniciar, mas tenho preocupações com a minha configuração. Agradeço 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 dessa API. O servidor da API receberá solicitações e as retransmitirá para os servidores de trabalho. A API manterá apenas um banco de dados mysql de solicitações para fins de registro, autenticação e limitação de taxa.

Cada servidor trabalhador realiza um trabalho diferente e, no futuro, em escala, adicionarei mais servidores trabalhadores disponíveis para assumir trabalhos. O arquivo de configuração da API será editado para anotar os novos servidores de trabalho. Os servidores trabalhadores farão algum processamento e alguns salvarão um caminho para uma imagem no banco de dados local, para serem recuperados posteriormente pela API para serem visualizados no meu aplicativo, alguns retornarão seqüências de caracteres do resultado de um processo e o salvarão em um banco de dados local .

Essa 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 entender.

Maior disponibilidade

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

Continue no mesmo caminho

Você menciona o recebimento de solicitações no servidor 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 deles aceitar comandos diretamente de seus Usuários da API. Você pode usar algo tão simples quanto o DNS de rodízio para distribuir cada conexão de usuário da API diretamente a um dos nós de trabalho disponíveis (e tentar novamente se a conexão não for bem-sucedida).

Use um servidor de fila de mensagens

Infraestruturas de enfileiramento de mensagens mais robustas usam software projetado para esse fim, como o ActiveMQ . Você pode usar a API RESTful do ActiveMQ para aceitar solicitações POST dos usuários da API, e os trabalhadores ociosos podem receber 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 tratador

Como meio termo, convém observar o Zookeeper , mesmo que não seja especificamente um servidor de fila de mensagens. Usamos $ work para esse fim exato. Temos um conjunto de três servidores (análogo ao servidor de API) que executam o software do servidor Zookeeper e temos um front-end da 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 se um servidor estiver inativo para manutenção. Quando o trabalho é concluído, o trabalhador 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

• Certifique-se de que os trabalhos sejam concluídos no caso de um trabalhador não responder
• Como a API saberá que um trabalho está concluído e para recuperá-lo do banco de dados do trabalhador?
• Tente reduzir a complexidade. Você precisa de um servidor MySQL independente em cada nó de trabalho, ou eles podem conversar com o servidor MySQL (ou o MySQL Cluster replicado) nos servidores da API?
• Segurança. Alguém pode enviar um emprego? Existe autenticação?
• Qual trabalhador deve conseguir o próximo emprego? Você não menciona se as tarefas devem levar 10 ms ou 1 hora. Se eles forem rápidos, remova as camadas para manter a latência baixa. Se eles forem lentos, você deve ter muito cuidado para garantir que solicitações mais curtas não fiquem atrasadas em algumas solicitações demoradas.

O maior problema que vejo é a falta de planejamento de failover.

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

Sugiro que você analise o projeto Linux Virtual Server ( http://www.linuxvirtualserver.org/ ) para ter uma idéia de como o balanceamento de carga e o failover funcionam e para ter uma idéia de como isso pode beneficiar seu design.

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