Terminologia

Vários termos novos são introduzidos com o HyperServer. Antes de prosseguir, é bom familiarizar-se com eles.

HyperServer

HyperServer é o ponto de entrada principal para todas as requisições. Ele filtrará as requisições e as direcionará para o Node correspondente. Se uma requisição não estiver associada a um Node, o HyperServer a direcionará para um Node arbitrário com base em um algoritmo de distribuição de carga. O HyperServer também é responsável por criar novos Nodes e reciclá-los quando necessário.

O próprio HyperServer é uma aplicação uniGUI projetada para esse propósito específico. O HyperServer é implantado na forma de arquivos binários pré-compilados (Exe e Dll). Opções de implantação disponíveis: Standalone Server, ISAPI Module e Windows Service. No futuro, componentes do HyperServer serão incluídos na biblioteca uniGUI, permitindo que desenvolvedores criem seus próprios HyperServers personalizados.

(Links preservados:)

• https://unigui.com/doc/online_help/standalone_server.htm

• https://unigui.com/doc/online_help/isapi_module.htm

• https://unigui.com/doc/online_help/windows_service.htm

Node

Um HyperServer Node é um processo worker. Ao mesmo tempo é a própria aplicação uniGUI implantada no modo EXE standalone. Desenvolvedores implantarão suas aplicações na forma de um Node. Desenvolvedores não precisam tomar nenhuma ação especial ao projetar uma aplicação Node. Eles podem desenvolver e testar suas aplicações como fariam com qualquer aplicação uniGUI padrão.

ServerNode

Um ServerNode é uma instância escrava do HyperServer que faz parte de uma Server Farm do HyperServer. Um ServerNode geralmente é um computador ou uma VM que executa uma instância do HyperServer. ServerNodes também podem ser instâncias separadas do HyperServer executando no mesmo PC. Um ServerNode existe apenas em uma configuração de Server Farm.

Node Id

Cada Node tem um Id de Node único. Um Id de Node é atribuído no momento em que o Node é criado. Os Ids de Node serão reutilizados quando os Nodes forem reciclados.

Transport

O HyperServer usa canais de Transport para se comunicar internamente com seus Nodes. Atualmente dois tipos de canais estão implementados: HTTP Transport e Named Pipe Transport.

HTTP Transport

Este é o primeiro tipo de canal de transport implementado para o HyperServer. Ele usa o protocolo HTTP para transportar dados entre o HyperServer e seus Nodes. Está disponível para plataformas Windows e Linux.

Named Pipe Transport

Este é o segundo tipo de canal implementado para o uniGUI HyperServer. A primeira versão só suporta a plataforma Windows. Uma versão para Linux também será implementada. Ele usa a tecnologia Named Pipe, que é um método popular para comunicação entre processos.

Comparado com o canal HTTP, um canal de named pipe é muito mais escalável, muito mais rápido e usa menos memória. Um canal named pipe só pode ser usado para comunicação entre uma instância do HyperServer e seus Nodes. Não pode ser usado para comunicação entre servidores diferentes, então em uma server farm do HyperServer, a comunicação entre o HyperServer master e os ServerNodes escravos ainda será feita usando canais HTTP.

A maior vantagem de usar named pipes é a melhor escalabilidade. Um canal HTTP precisa se vincular a um número de porta, que é um recurso de sistema limitado (porta pode ser um número entre 1 - 65535). Existe a chance de que uma porta configurada conflite com outras aplicações que já estão vinculadas a essa porta. Por outro lado, um named pipe não precisa de número de porta, então o número de named pipes que podem ser criados é limitado apenas pelos recursos do sistema disponíveis. Cada named pipe recebe um nome único que será obtido a partir do parâmetro token.

Reciclagem de Node

Nodes serão reciclados com base em um cenário predefinido. Quando um Node deve ser reciclado, o processo associado será solicitado a terminar a si mesmo. Após esse pedido ser reconhecido, o Node começará a encerrar todas as suas sessões e finalmente terminará seu processo. Se um Node não reconhecer um pedido de reciclagem, ele será terminado à força pelo HyperServer.

Node Ativo

Nodes Ativos são aqueles Nodes que estão atendendo sessões ativamente. Eles são capazes de aceitar novas sessões.

Node Suspenso

Um Node suspenso é um Node que falhou em se comunicar com o HyperServer. Em operações normais o HyperServer consulta (polls) todos os seus Nodes em determinados intervalos. Se um dos Nodes não responder, ele será marcado como suspenso. Se um Node não responder após uma certa quantidade de tentativas, então ele será considerado um Node com falha e será purgado.

Node Purgado

Um Node Purgado é um Node que é removido da lista de Nodes ativos e enviado para a fila de reciclagem. Um Node Purgado não aceitará novas sessões nem processará qualquer requisição recebida. Ele será removido do espaço de processo na próxima vez que a fila de reciclagem for limpa.

Node Descartado

Um Node Descartado é um Node que realmente possui várias sessões, mas não aceitará novas sessões. Ele continuará existindo até que todas as suas sessões sejam encerradas. Uma vez que não houver mais sessões restantes, ele será purgado.

Node Persistente (versão 1.95 e posteriores)

A partir da versão 1.95, o uniGUI introduziu um novo recurso do HyperServer chamado Node Persistente, que substitui o Persistent Node Zero das versões anteriores. Um node persistente não requer sempre um id igual a zero; você pode ter nodes persistentes com diferentes valores de id. Agora você também pode atribuir Nodes Persistentes a aplicações HyperServer. Anteriormente apenas a aplicação padrão do HyperServer poderia possuir Nodes Persistentes; agora cada aplicação pode possuir seu Node Persistente. Isso significa que uma instância do HyperServer pode hospedar múltiplos Nodes Persistentes que pertencem a aplicações diferentes.

O que é um Node Persistente e por que usá-lo?

Um Node Persistente é um Node que tem garantia de executar continuamente (nunca será descarregado permanentemente). Ele será ocasionalmente reciclado como qualquer outro Node, mas tem garantia de ser recarregado imediatamente após ser reciclado. O objetivo principal de um Node Persistente é garantir que você tenha pelo menos um Node em execução a qualquer momento. Por exemplo, se sua aplicação uniGUI precisa executar tarefas em segundo plano em uma thread dedicada (por exemplo, um TUniThreadTimer no ServerModule), em uma aplicação uniGUI clássica existe apenas um processo, então uma tarefa em segundo plano pode rodar como um Singleton. No HyperServer, múltiplas cópias do mesmo processo executam simultaneamente, então você precisa de um mecanismo para garantir que seu método Singleton rode apenas em um Node. Node Persistente fornece essa garantia. Se a propriedade booleana PersistentNode no seu ServerModule for True, então é seguro executar sua tarefa em segundo plano.

Exemplo: evento ThreadTimer só é executado se o Node atual for um Node Persistente.

ServerModule Pascal

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  if PersistentNode then // executar tarefa se eu for um Node Persistente
  begin
    // Sua tarefa aqui
  end;
end;

Nota: A propriedade PersistentNode também retornará True quando sua aplicação não for um Node e não fizer parte de um cluster HyperServer. Isso permite que você use o mesmo código independentemente do modo de implantação.

Nodes Persistentes agora também podem ser habilitados para aplicações HyperServer. Exemplos de trechos INI:

hyper_server.ini

[hyper_server]
binary_name=dbdemo.exe
persistent_node=1

configuração da aplicação

[application-0]
enabled=1
alias=fishfacts
binary_name=fishfacts.exe
persistent_node=1
max_nodes=4

Isso permite executar tarefas em segundo plano não apenas na aplicação padrão, mas também em quaisquer aplicações adicionais que as requeiram. Uma instância do HyperServer pode executar vários Nodes Persistentes: um para a aplicação padrão do HyperServer e outros para aplicações adicionais configuradas na instância.

Observação importante: Para garantir que apenas UM Node Persistente execute para qualquer aplicação em seu cluster HyperServer, configure o parâmetro persistent_node em APENAS UMA das instâncias do HyperServer. Se múltiplas instâncias do HyperServer forem configuradas com persistent_node para a mesma aplicação, múltiplos Nodes Persistentes podem executar simultaneamente, o que é indesejado.

clip0333.png

A partir da versão 1.95, Nodes Persistentes são mostrados em negrito na tela do monitor do HyperServer para que você possa distingui-los de outros Nodes. Na imagem acima há três Nodes Persistentes: um pertence à aplicação padrão do HyperServer e os outros dois pertencem a aplicações adicionais configuradas para esta instância do HyperServer.

Persistent Node Zero (obsoleto — ver seção Node Persistente acima)

Persistent Node Zero é um Node com Id = zero (0) que era garantido executar continuamente (nunca descarregado permanentemente) e seria recarregado imediatamente após ser reciclado. Seu objetivo principal era garantir que um único Node executasse tarefas em segundo plano (Singleton) quando múltiplas cópias do processo existiam.

Exemplo de uso (executar apenas se o Node atual for o Node Zero):

ServerModule Pascal (verificação NodeZero)

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  if NodeZero then // executar código se eu for o Node #0
  begin
    // Sua tarefa aqui
  end;
end;

Ou (para suportar implantação tanto com HyperServer quanto no modo clássico de processo único):

ServerModule Pascal (NodeZero ou não NodeMode)

procedure TUniServerModule.UniThreadTimer1Timer(Sender: TObject);
begin
  if NodeZero or (not NodeMode) then // executar código se eu for o Node #0 ou se eu não for um Node!
  begin
    // Sua tarefa aqui
  end;
end;