Uma Visão Mais Detalhada do HyperServer

Nesta seção vamos analisar mais profundamente o uniGUI HyperServer. Podemos agrupar os recursos do HyperServer em diferentes categorias:

1

HyperServer e Estabilidade

HyperServer é uma nova tecnologia de servidor projetada especificamente para melhorar radicalmente a escalabilidade e a estabilidade de aplicações uniGUI. A pergunta imediata aqui é: por que precisamos do HyperServer em primeiro lugar?

Para responder a isso, primeiro precisamos estar familiarizados com uma aplicação uniGUI clássica. Em uma aplicação uniGUI clássica um binário é gerado pelo compilador (tipicamente uma DLL ou um executável). Esse binário atua como o servidor assim que é carregado no espaço de memória do processo. Ele será executado indefinidamente até ser descarregado manualmente por um operador do sistema, automaticamente pelo SO, ou como resultado de um erro de programa que pode levar a uma falha da aplicação. Em condições ideais pode-se esperar que o binário do servidor da aplicação permaneça na memória indefinidamente — algo esperado de um servidor de aplicação robusto e estável.

Outra característica do modelo clássico de aplicação é que um único processo é responsável por criar, manter e servir todas as sessões. É semelhante a colocar todos os ovos em uma cesta (as sessões são os ovos e o servidor da aplicação é a cesta). Várias fraquezas estão associadas a esse modelo:

  • Todas as sessões ativas são descartadas assim que o servidor da aplicação web é encerrado ou reiniciado.

  • Bugs e defeitos no código da aplicação podem levar a vazamentos de memória severos, corrupção de memória, deadlocks ou falhas. Mesmo problemas pequenos podem se acumular ao longo do tempo e afetar a operação do servidor.

  • Tais defeitos podem vir de:

    • Bugs no código do projeto atual

    • Bugs em código legado portado de um projeto mais antigo

    • Bugs em bibliotecas de terceiros

    • Bugs do compilador

    • Bugs nas bibliotecas padrão do Delphi (RTL, VCL, DB, etc.)

Embora muitas aplicações uniGUI sejam desenvolvidas e testadas para rodar indefinidamente no modelo clássico de processo único, e os servidores uniGUI sejam geralmente estáveis e robustos, o modelo de processo único tem limitações — especialmente no tratamento de defeitos que são difíceis de detectar ou que aparecem somente em condições de produção.

HyperServer não corrige código com bugs; ele não reparará vazamentos de memória ou erros de lógica. Seu propósito é aumentar a chance de sua aplicação sobreviver em produção mesmo quando alguns componentes têm defeitos. HyperServer melhora a estabilidade implementando mecanismos tais como:

  • Balanceamento de carga interno — distribuindo a carga geral do servidor entre Nodes.

  • Reciclagem de Node — reduzindo o ciclo de vida dos Nodes ao reciclá‑los com base em regras predefinidas para que os Nodes residam no espaço de processo apenas por um período definido.

Nessa arquitetura, uma aplicação HyperServer é dividida em duas partes essenciais:

  1. O executável HyperServer — o ponto de entrada que atende às requisições de clientes que chegam.

  2. Um cluster de Nodes — processos de trabalho que hospedam sessões e lógica da aplicação.

2

HyperServer e Escalabilidade

Uma das maiores preocupações para aplicações web é sua capacidade de escalar. Isso é especialmente importante para aplicações uniGUI porque as sessões são stateful e mantêm estado na memória do processo. O modelo clássico de processo único normalmente pode escalar até algumas centenas de sessões, embora os limites teóricos dependam dos recursos do servidor e do design da aplicação. A pergunta prática é: é seguro colocar 1.000 ovos em uma única cesta? Normalmente não.

HyperServer divide sua aplicação em múltiplos Nodes e distribui as sessões entre eles. Como cada Node é um processo separado, suas sessões são isoladas das sessões em outros Nodes; problemas em um Node afetam apenas esse Node e suas sessões.

Outras questões relacionadas a manter muitas sessões em um único processo incluem:

  • Aumento do multithreading e a necessidade de locks; com mais sessões, locks podem se tornar gargalos.

  • Locks podem existir no código da aplicação, na RTL, ou em bibliotecas de terceiros.

HyperServer pode gerenciar um cluster de Nodes dentro de um único servidor e pode ser estendido para gerenciar múltiplos clusters de Node através de vários servidores — possibilitando a implantação em uma fazenda de servidores e adicionando uma nova dimensão às aplicações web uniGUI + Delphi.

3

HyperServer e Implantação Remota

HyperServer também possibilita a implantação remota de novas versões da aplicação sem parar o servidor, melhorando continuidade e disponibilidade. No modelo clássico, atualizar uma aplicação tipicamente requer encontrar um período de baixo tráfego, derrubar o servidor (descartando sessões ativas) e pedir aos usuários que façam logout.

Com o HyperServer:

  • Você pode enviar uma nova versão remotamente e o HyperServer atualiza os Nodes gradualmente.

  • Novas sessões são redirecionadas para Nodes executando a nova versão.

  • Nodes com versões mais antigas são descartados e purgados assim que todas as suas sessões fizerem logout.

Isso permite atualizações em rolling com interrupção mínima para os usuários.

uniGUI HyperServer

Referências:

  • Developer's Guide > uniGUI HyperServer: https://unigui.com/doc/online_help/hyperserver.htm

  • Página de origem: https://unigui.com/doc/online_help/index.html?a-more-in-depth-look-at-hypers.htm