Descoberta de serviço dinâmico
O framework Moleculer possui um módulo integrado responsável pela descoberta e verificação periódica de sinal de vida de cada nó. A descoberta é dinâmica significando que um nó não precisa saber nada sobre outros nós durante a inicialização. Quando ele inicia, ele vai anunciar sua presença a todos os outros nós para que cada um possa construir seu próprio registro de serviço local. Em caso de falha de um nó (ou parada) outros nós irão detectá-lo e remover os serviços afetados do seu registro. Desta forma, as próximas requisições serão encaminhados para nós ativos.
Local
A Descoberta local (opção padrão) usa o módulo de transporte para trocar informações do nó e pacotes de sinal de vida (para mais informações sobre a estrutura dos pacotes, verifique o protocolo Moleculer). É o mais simples e o mais rápido entre os mecanismos de descoberta disponíveis, pois não requer nenhuma solução externa. No entanto, este método de descoberta também tem alguns inconvenientes, especialmente para implantações de grande escala com mais de 100
nós. Os pacotes de sinal de vida podem gerar grande quantidade de tráfego que podem saturar o protocolo de comunicação e, portanto, deteriorar o desempenho de ações e eventos, por exemplo, lentidão na entrega de requisições/resposta e pacotes de eventos.
Observe que o módulo de transporte TCP usa o protocolo Gossip & pacotes UDP para descoberta & sinal de vida, o que significa que só pode funcionar como mecanismo local de descoberta.
Descoberta local com opções padrão
// moleculer.config.js |
Descoberta local com opções personalizadas
// moleculer.config.js |
Redis
A descoberta baseada em Redis usa uma conexão dedicada com o servidor Redis para compartilhar descobertas e pacotes de sinal de vida. Esta abordagem reduz a carga sobre o módulo de transporte; e é usada exclusivamente para compartilhamento de requisições, respostas, pacotes de eventos.
Quando o método de descoberta baseado em Redis está habilitado, os nós do Moleculer publicam e buscam periodicamente a informação no Redis e atualizam seu registro de serviços interno. Mecanismo de expiração de chaves do Redis remove nós que não publicam pacotes de sinal de vida por um determinado período de tempo. Isto permite que nós do Moleculer detectem que um nó específico foi desconectado.
Por favor, note que este método é mais lento para detectar novos nós já que ele depende de verificações periódicas de sinal de vida no servidor Redis. A periodicidade depende da opção heartbeatInterval
do broker.
Para usar a descoberta via Redis instale o módulo
ioredis
com o comandonpm install ioredis --save
.
Exemplo de conexão em um servidor Redis local
// moleculer.config.js |
Exemplo de conexão em um servidor Redis remoto
// moleculer.config.js |
Exemplo com opções
// moleculer.config.js |
Dica: Para reduzir ainda mais o tráfego de rede, use os serializadores MsgPack/Notepack ao invés de JSON.
etcd3
O método de descoberta baseado em Etcd3 é muito semelhante ao descoberta baseada em Redis. Ele armazena sinais de vida e pacotes de descoberta no servidor etcd3. A opção lease do etcd3 removerá as informações de sinal de vida dos nós que caírem ou forem desconectados da rede.
Este método tem os mesmos pontos fortes e fracos da descoberta baseada em Redis. Ele não usa o módulo de transporte para a descoberta, mas também é mais lento para detectar nós novos ou desconectados.
Para usar a descoberta via etcd3 instale o módulo
etcd3
com o comandonpm install etcd3 --save
.
Exemplo para conectar o servidor local etcd3
// moleculer.config.js |
Exemplo de conexão do servidor remoto etcd3
// moleculer.config.js |
Exemplo com opções
// moleculer.config.js |
Dica: Para reduzir ainda mais o tráfego de rede, use os serializadores MsgPack/Notepack ao invés de JSON.
Personalização
Você pode criar seu mecanismo de descoberta personalizado. Recomendamos copiar a fonte do Redis Discoverer e implementar os métodos necessários.
Registro de Serviços Integrado
Moleculer tem um módulo de registro de serviços integrado. Ele armazena todas as informações sobre serviços, ações, assinantes de eventos e nós. Quando você chama um serviço ou emite um evento, o broker pede ao registro para procurar um nó que possa executar a requisição. Se houver vários nós, ele usa a estratégia de balanceamento de carga para selecionar o próximo nó.
Leia mais sobre o balanceamento de carga & estratégias.
Os dados de registro estão disponíveis através de serviço interno.