Arquitetura Micro vs Monolithic Server

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: DataSets

• Responda 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 Parserprocesso
• O Parseranalisa a cadeia, identifica a tarefa e dirige o Executionerprocesso para executar as tarefas.
• Em Executionerseguida, ele passa os dados para o Fomatterprocesso 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, Executionere Formatterpoderia 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)

• 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 PUSHserviços em tempo real do servidor podem ser 'altamente' desejados se o produto clicar!

Às vezes, a economia governa uma resposta muito mais crítica do que a teoria central por trás das escolhas. O mais importante é que, se você estiver olhando para algo 'vasto' no seu caso, em que seu aplicativo precisa de uma implantação genuinamente difícil - quanto menor o número de rodas que você inventa, melhor é. Se funcionar, não vou me importar se é monolítico ou micro; se não, eu também não vou me importar!

Pode ser verdade que aplicativos muito convencionais baseados em páginas da Web podem não ser adequados para você - mas você precisa dar uma olhada um pouco mais ampla e ver que pode usar as coisas prontas para avançar e depois evoluir para descobrir se é possível substituir esse elemento por algo Melhor. Dessa forma, você não apenas economizará tempo para a primeira coisa, mas também melhorará sua compreensão sobre o que realmente importa na vida real. Aqui estão algumas dicas que você pode considerar.

1. Se você realmente precisar de uma escalabilidade muito alta, considere como seus servidores dividirão a tarefa em vez de agitar os números o mais rápido possível. Eventualmente, você terá uma carga que um servidor realmente não pode suportar, mesmo que a Intel faça o processador mais rápido do mundo e o cliente esteja pronto para pagar! Portanto, o roteamento de solicitação e o balanceamento de carga são mais importantes que a eficiência do próprio protocolo.

2. O HTTP ainda é o melhor, se você precisar aumentar a escala. (Você também pode comprar balanceadores de carga com facilidade, se você o usar). O protocolo personalizado requer arranjos personalizados.

3. HTTP não significa que você precise usar HTML, java script. Nem sequer significa que você precisa ter um servidor apache e um navegador regulares. Você pode usar HTTP entre dois clientes personalizados e elementos como servidor AOL ou lighthttpd que podem ser usados ​​como uma biblioteca se a comunicação não for uma grande transferência de dados. Você também pode usar o SOAP dos dois lados com kits de ferramentas como o gSOAP .

4. Mesmo que o HTTP definitivamente não se encaixe no orçamento, considere algo como o BEEP , que ajuda a tornar as coisas mais eficientes. Como alternativa, existem muitos mecanismos comprovados de RPC, RMI que existem.

5. Tente ver que você pode realizar o trabalho máximo ao realizar um processamento paralelo no backend e os servidores só serão consultados quando o trabalho estiver concluído. Se isso funcionar, existem estruturas como MPI ou muitos outros kits de ferramentas de computação distribuída que podem ser úteis.

6. Finalmente, embora eu possa não estar em condições de conhecer as necessidades exatas, mas você pode precisar distribuir muitos dados ou fazer muita computação, se precisar de ambos - ainda existem algumas ineficiências arquitetônicas principais.

Para mim, criar um novo protocolo e criar uma nova estrutura de servidor é um experimento duplo que você não deve fazer juntos. Se suas apostas são tão altas, primeiro você deve tentar experimentar as ferramentas existentes para ver os limites do que foi feito até agora - somente então você conhecerá os desafios reais.

Muito mais foi realizado na pesquisa de sistemas distribuídos do que apenas aplicativos da web. Então você deve pesquisar isso.

Dipan.

Isso me parece muito acadêmico. E, francamente, acho a segunda abordagem igualmente monolítica. Isto é o mais longe que você deve ir:

1. Analisar a solicitação
2. Lidar com a solicitação

O manipulador de solicitação escolhido com base nos parâmetros de solicitação deve encapsular todos os aspectos do tratamento da solicitação. Se o manipulador realmente executa consultas no seu armazenamento de dados ou não e se usa ou não a formatação padrão para retornar os dados, é irrelevante a partir da camada acima. De fato, provavelmente fará exatamente isso, mas não há valor em fazer suposições sobre isso.

1. O kernel monolítico é muito mais antigo que o Microkernel . É usado no Unix. enquanto Idea of ​​microkernel apareceu no final dos anos 80 .

2. o exemplo de sistemas operacionais com núcleos monolíticos é UNIX, LINUX, enquanto sistemas operacionais com microkernel são QNX, L4, HURD , inicialmente Mach (não mac os x) depois serão convertidos em kernel híbrido, até o MINIX não é um kernel puro, pois o driver de dispositivo é compilado como parte do kernel.

3. O kernel monolítico é mais rápido que o microkernel . enquanto o primeiro microkernel Mach é 50% mais lento que o kernel monolítico, enquanto a versão posterior como L4 é apenas 2% ou 4% mais lenta que o kernel monolítico .

4. O núcleo monolítico geralmente é volumoso . enquanto o kernel monolítico puro precisa ser pequeno em tamanho, até caber em s no cache de primeiro nível do processador (microkernel de primeira geração).

5. no driver de dispositivo do kernel monolítico reside no espaço do kernel . enquanto o driver de dispositivo Microkernel reside no espaço do usuário .

6. como o driver do dispositivo reside no espaço do kernel, torna o kernel monolítico menos seguro que o microkernel. (Falha no driver pode levar a uma falha), enquanto os Microkernels são mais seguros do que o kernel monolítico usado em alguns dispositivos militares.

7. Os núcleos monolíticos usam sinais e soquetes para garantir o IPC, enquanto a abordagem por microkernel usa filas de mensagens . 1 geração de IPC mal implementado do microkernel, por isso foi lento nas alternâncias de contexto.

8. adicionar um novo recurso a um sistema monolítico significa recompilar todo o kernel enquanto você pode adicionar um novo recurso ou patches sem recompilar .