Atualmente, estamos trabalhando em nosso novo produto / projeto, é um aplicativo cliente-servidor direcionado a determinadas empresas industriais / de serviços. Estamos construindo um servidor (somente linguagem C e Linux) executando um protocolo personalizado sobre o TCP com um front-end Java. Estamos em cerca de 20% no trabalho de codificação e enfrentamos uma situação que precisa ser escolhida entre a Arquitetura de Kernel Micro ou Monolítica.
Estou ciente de que o Micro vs. Monolítico geralmente está relacionado à arquitetura do kernel, mas estamos falando especificamente de servidores.
Por que um servidor personalizado e não algo existente?
- Nossas necessidades de interface do usuário são significativas e muito dinâmicas, portanto, as soluções baseadas na Web / navegador da Web não eram apropriadas.
- O processamento estatístico é significativo no final do cliente e, portanto, novamente, os navegadores foram de pouca ajuda. (Obviamente, poderíamos fazer o processamento no final do servidor e repassar os dados processados ao cliente, mas isso implicaria muita carga no servidor e desperdício de recursos do cliente).
- Além disso, com pelo menos três tecnologias (JS / HTML / CSS) para gerenciar até um único evento, toda a experiência é como varrer a casa no meio de uma tempestade no deserto - você varre n vezes, a poeira acumula n + 1 vezes.
E o Servidor Micro e Monolítico? O que você está falando?
Considere a seguinte solicitação do cliente (hipotética):
request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010
Ao receber essa solicitação, normalmente um servidor faz (estamos ignorando técnicas de simultaneidade, como encadeamentos e garfos para simplificar):
- Analisar a sequência de solicitação
- Identifique a ação (buscar
HistoricDataSets LIMIT Year (2010)
no nosso caso) - Interaja com a camada de persistência (Oracle, digamos, em nosso exemplo) e busque os dados.
Formate os dados conforme o protocolo. Ex:
response-id: 123
success: true
response-text: DataSetsResponda ao cliente com os dados assim formatados.
É isso que estamos chamando de servidor monolítico (semelhante a um kernel monolítico, onde todo o funcionamento do sistema operacional é feito no espaço do kernel).
Considere o mesmo pedido novamente, no recebimento, desta vez no servidor (assumimos apenas a memória compartilhada como IPC, novamente por simplicidade):
- Coloca a solicitação na memória compartilhada para o
Parser
processo - O
Parser
analisa a cadeia, identifica a tarefa e dirige oExecutioner
processo para executar as tarefas. - Em
Executioner
seguida, ele passa os dados para oFomatter
processo que, após formatar os dados em uma sequência de protocolos, retorna ao servidor. - O servidor o despacha para o cliente (resposta).
Obviamente, em vez de Parser
, Executioner
e Formatter
poderia ter sido um processo único, mas separado. É isso que chamamos de Micro Server (semelhante a um micro kernel que faz o mínimo necessário). O servidor efetivamente está apenas ouvindo e respondendo, enquanto todas as etapas são resolvidas por diferentes processos.
Qual escolher? Nós estamos confusos! Enquanto os servidores monolíticos são testados e testados (a maioria dos servidores HTTP-Web?), São mais fáceis de programar e podem lidar com a concorrência muito bem. Micro servidores, prima facie, parecem rápidos e alinhados com o princípio UNIX de um programa para executar uma tarefa, mas também são complicados de desenvolver, especialmente. mantendo a simultaneidade em mente.
Pergunta (s)
- Quais são (possivelmente poderiam) os prós e os contras de cada abordagem?
- Quando usar qual? (Também pode ser interpretada como uma pergunta geral: quando usar o IPC?)
- Se o Micro kernel for escolhido, quais funções precisam fazer parte do servidor núcleo e quais não?
Questões semelhantes / relacionadas
- Perigos de enorme aplicação monolítica
- Navegador Vs externo incorporado (tangencial)
- Conselhos para converter aplicativos Monolíticos em multithread (Tangencial)
Algumas informações que podem ser úteis:
- Nossos clientes em potencial podem ser divididos em duas categorias:
- Grande: cerca de 1.700 - 2.000 solicitações por minuto
- Pequeno: cerca de 650 - 700 solicitações por minuto
- Pode-se presumir que o volume de dados por ciclo de solicitação (solicitação e resposta subsequente) seja distribuído normalmente com média de ~ 1,20 MB e, na pior das hipóteses, de 250 a 300 MB.
- O conceito de produto é relativamente novo, mas tem a capacidade de impactar as operações principais; portanto, esperamos que os orçamentos do cliente sejam flexíveis apenas após um certo atraso (9 a 12 meses) após a implantação, isso limita a quantidade de hardware que o cliente desejará comprometer esp. os pequenos.
- Cada cliente terá sua própria pilha cliente-servidor. O servidor estará executando no hardware do cliente gerenciado pela equipe do cliente, enquanto os clientes serão implantados nas máquinas dos funcionários funcionais
- Atualizações remotas para aplicativos cliente e servidor são uma obrigação
- Os
PUSH
serviços em tempo real do servidor podem ser 'altamente' desejados se o produto clicar!