O uniGUI versão 1.50.0 apresenta o uniGUI HyperServer, que foi projetado principalmente para melhorar radicalmente a disponibilidade, estabilidade e escalabilidade dos aplicativos uniGUI. Ele também apresenta outros recursos importantes, como permitir atualizar aplicativos remotamente sem a necessidade de parar o servidor de aplicativos.

O que é HiperServer?

O uniGUI HyperServer é uma nova arquitetura de servidor projetada para melhorar muito a disponibilidade, a estabilidade e especificamente a escalabilidade dos aplicativos uniGUI. Este objetivo é alcançado através da aplicação de técnicas conhecidas e amplamente utilizadas na indústria, como balanceamento de carga e reciclagem de processos.

Um servidor de aplicativos uniGUI tradicional consiste em um único processo e vários threads. O processo único pode ser um executável uniGUI ou um processo de trabalho ISAPI ou Apache. Em todos os casos, todas as sessões residem dentro de um único processo e várias threads no mesmo processo são usadas para lidar com solicitações recebidas.

O uniGUI HyperServer muda o modelo acima e se transforma em um modelo multi-processo multi-thread. Nesse novo modelo, vários processos de trabalho são gerados para atender ao mesmo aplicativo da web. As sessões serão divididas entre os processos de trabalho e com base na configuração, você pode ter vários processos de trabalho para o mesmo aplicativo uniGUI. Os processos de trabalho são gerenciados e orquestrados por outro processo que é, na verdade, o próprio HyperServer. O HyperServer será o principal ponto de entrada para todas as solicitações recebidas. O HyperServer receberá todas as solicitações e as distribuirá entre os processos de trabalho. O HyperServer também tem a responsabilidade de gerar novos processos de trabalho quando necessário e reciclá-los assim que forem eliminados. Como as sessões uniGUI são stateful, outro dever importante do HyperServer é direcionar as solicitações de sessão recebidas para o processo de trabalho correto que criou aquela sessão específica. No hiperservidorterminologia cada processo de trabalho é chamado de Node.

Uma visão mais aprofundada do HyperServer

O HyperServer é uma nova tecnologia de servidor projetada especificamente para melhorar radicalmente a escalabilidade e a estabilidade do aplicativo uniGUI. A questão imediata aqui é por que precisamos do HyperServer em primeiro lugar?

Para responder a esta pergunta, primeiro precisamos nos familiarizar com um aplicativo uniGUI clássico. Em um aplicativo uniGUI clássico, um binário é gerado pelo compilador, que normalmente é uma DLL ou um executável. Este arquivo binário é responsável por atuar como um servidor assim que é carregado no espaço de memória do processo. Ele será executado indefinidamente até que seja descarregado manualmente pelo operador do sistema, automaticamente pelo sistema operacional ou como resultado de um erro de programa que pode levar ao travamento do aplicativo. Em condições ideais, pode-se esperar que o binário do servidor de aplicativos permaneça na memória por um período de tempo indefinido. Algo que se espera de um servidor de aplicações 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. É como colocar todos os ovos na mesma cesta. Nesse caso, as sessões são ovos e o servidor de aplicativos é a cesta. Existem várias fraquezas e desvantagens que podem ser associadas a este modelo. O problema mais óbvio é que todas as sessões ativas serão descartadas assim que o servidor de aplicativos da web for encerrado ou reiniciado. Outro problema que pode afetar muito a estabilidade do aplicativo são os bugs e defeitos no código do aplicativo. Esses bugs podem levar a graves vazamentos de memória e outros problemas que eventualmente podem levar à corrupção de memória e travamento do servidor de aplicativos da web. O problema aqui é que os efeitos cumulativos de até mesmo pequenos problemas de memória podem aumentar com o tempo e afetar a operação do servidor. Como no modelo clássico, o servidor de aplicativos está destinado a ser executado por um período de tempo indefinido, mesmo pequenos problemas podem se tornar fatais com o tempo. Claro, isso só é verdade para aplicativos que sofrem de bugs ocultos, vazamentos de memória, problemas de ponteiro e outros problemas que podem não ser visíveis para o desenvolvedor. Alguns desses problemas podem ser difíceis de detectar e corrigir se um código de aplicativo herdado for transferido de um aplicativo VCL de desktop para uniGUI.

É desnecessário dizer que aplicativos bem desenvolvidos que são desenvolvidos de acordo com padrões de design comuns e bem testados contra problemas de memória, vazamentos e bugs são capazes de rodar indefinidamente no modelo clássico de aplicativo de processo único. Os servidores de aplicativos uniGUI são conhecidos por serem bastante estáveis ​​e robustos. É um fato conhecido que muitos desenvolvedores têm poucos problemas com a estabilidade no uniGUI. No entanto, deve-se enfatizar que, embora o modelo de processo único possa ser considerado estável para aplicativos uniGUI típicos, o mesmo não pode ser dito para escalabilidade. Considerando a estabilidade, o principal problema dos desenvolvedores é que eles podem enfrentar defeitos de software em muitos níveis que podem ser difíceis de detectar, corrigir ou encontrar uma solução alternativa. Vejamos uma lista de tais defeitos:

•Bugs no código do projeto atual.

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

•Bugs em bibliotecas de terceiros.

•Erros do compilador.

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

Algumas das fontes acima podem ser muito raras, como bugs do compilador e bugs da biblioteca Delphi, não podemos negar sua existência. Entre os bugs acima, apenas aqueles que podem levar a vazamento de memória, corrupção de memória ou bloqueio no código podem ser prejudiciais para um aplicativo de servidor. Os bugs mais comuns são aqueles que existem diretamente no código do projeto. A natureza nativa dos aplicativos Delphi os torna vulneráveis ​​a problemas de memória e, até que todos esses problemas sejam corrigidos, os aplicativos não podem ser aceitos como totalmente estáveis. O maior problema das equipes de desenvolvimento de software, especialmente as grandes, é que nem sempre conseguem garantir que o código seja produzido com a mesma qualidade e que cada nova versão esteja livre de defeitos. Mesmo os longos testes de estresse podem não ser suficientes para detectar, isolar e corrigir defeitos de código ocultos.

Para lidar com o problema acima, precisamos de um modelo de servidor que possa tolerar melhor o código do aplicativo com bugs. O principal truque aqui é aumentar a chance de sobrevivência do seu código no ambiente de produção, mesmo quando ele não está pronto para o horário nobre. O HyperServer visa melhorar a estabilidade quando tais condições existem. O HyperServer atinge esse objetivo implementando diferentes mecanismos. Balanceamento de carga interno e reciclagem de nós. O balanceamento de carga distribuirá a carga geral do servidor entre os nós. A reciclagem de nós reduzirá o ciclo de vida dos nós, reciclando-os com base em regras predefinidas. A reciclagem garantirá que os nós residam no espaço de memória do processo apenas por um período definido. Ao contrário do modelo clássico que mantém o processo do servidor de aplicativos na memória indefinidamente.

Deve-se dizer que neste sentido o HyperServer não deve ser considerado como uma solução para um código bugado ou como uma ferramenta para lidar com problemas de memória. O HyperServer não corrigirá os erros de seu aplicativo nem fornecerá uma solução alternativa para eles. A principal tarefa do HyperServer é garantir que todo o servidor de aplicativos não trave como resultado de um defeito de memória ou outro problema em um Node.

Provavelmente agora você é capaz de descobrir que um aplicativo HyperServer é dividido em duas partes essenciais. A primeira parte é o executável do HyperServer, que é o ponto de entrada para seu aplicativo da web. Ele atenderá a todas as solicitações recebidas do cliente. A segunda parte do aplicativo HyperServer é um cluster de nós.

uniGUI HyperServer