Diretório de artigos
Mecanismo de Verificação de Integridade do Registro
Imagine que ocorre um desastre geológico e está soterrado sob as ruínas. A equipe de busca e resgate precisa localizá-lo para resgatá-lo. Dois métodos:
- Grite por socorro, informe a localização e o estado de saúde e avise a equipe de busca e resgate
- Equipes de busca e salvamento utilizam equipamentos especializados para detectar a localização dos corpos soterrados
Esses dois métodos podem ser comparados aos métodos de detecção de serviço:
- O cliente toma a iniciativa de relatar e informar o servidor sobre seu estado de saúde. Se não houver relatório por um período de tempo, é determinado que o serviço não está íntegro.
- O servidor detecta ativamente o cliente para verificar se ele é detectável.
Resumindo, a metáfora do caso real ilustra dois métodos de verificação de integridade do serviço:
- O cliente relata ativamente o status e nenhum relatório é anormal
- O servidor detecta ativamente o cliente
O primeiro se baseia no autorrelato do cliente, que é mais propenso a falhas ou atrasos na identificação de problemas. Este último é verificado regularmente pelo servidor, que pode detectar anomalias do cliente com mais rapidez e precisão. Mas também aumenta a carga do servidor.
Os dois métodos têm suas próprias vantagens e desvantagens, e a escolha real é personalizada ou combinada de acordo com os requisitos do sistema. O objetivo é garantir que o status de integridade do serviço seja efetivamente monitorado e os problemas possam ser detectados a tempo.
Você pode usar este exemplo para entender o mecanismo comum de verificação de integridade do serviço, os princípios, características e cenários aplicáveis dos dois métodos. Ao projetar o monitoramento do serviço, é necessário considerar as vantagens e desvantagens do método e os requisitos de personalização, de modo a obter o efeito de monitoramento ideal.
• Em uma cena metafórica, pedir ajuda ativamente e relatar a localização e o status pode reduzir a carga de trabalho da equipe de busca e resgate e focar no resgate.
• De forma análoga às verificações de integridade do serviço, todos os serviços precisam ser detectados ativamente pelo centro de registro e a carga de trabalho é muito grande, portanto, considere relatar ativamente os serviços para inspeção.
• No entanto, se o pedido de ajuda for fraco, a equipe de busca e resgate ainda conduzirá uma busca e resgate abrangente.
• A analogia é que o próprio serviço não pode relatar ativamente, e o centro de registro verifica ativamente é útil.
• Resumindo, o modo de relatório ativo reduz a carga no centro de registro, mas quando o servidor falha em relatar ativamente, o centro de registro precisa verificar ativamente.
• O primeiro se aplica à maioria dos serviços normais e o último fornece proteção para alguns serviços anormais. A combinação dos dois métodos pode realizar o monitoramento eficaz da integridade do serviço.
• Use metáforas para expressar claramente as funções e cenários aplicáveis dos dois métodos. Em circunstâncias normais, é relatado principalmente ativamente, e situações anormais são complementadas por inspeção ativa. Preste atenção ao uso combinado dos dois métodos para obter um monitoramento completo.
No atual centro de registro convencional, o mecanismo TTL (Time To Live) é adotado principalmente para o mecanismo de verificação de integridade , ou seja, se o cliente não enviar um heartbeat para o centro de registro dentro de um determinado período de tempo, o centro de registro considere o serviço não íntegro e acione a lógica de eliminação subsequente.
Para o método de detecção ativo, dependendo do cenário, o método necessário pode ser diferente
Mecanismo de verificação de integridade do Nacos
Antes de apresentar o mecanismo de verificação de integridade do Nacos, vamos revisar as características dos serviços do Nacos. A Nacos disponibiliza dois tipos de serviço para os usuários escolherem no cadastro de instâncias, que são divididos em instâncias temporárias e instâncias permanentes.
-
As instâncias temporárias existem apenas temporariamente no centro de registro e serão removidas pelo centro de registro quando o serviço estiver offline ou indisponível. A instância temporária manterá uma pulsação com o centro de registro e o centro de registro excluirá a instância após um período de tempo sem receber a pulsação do cliente. Defina-o como não saudável e, em seguida, descarte-o após um período de tempo.
-
A instância permanente existirá permanentemente no centro de registro antes de ser excluída e pode não saber da existência do centro de registro e não relatará ativamente a pulsação ao centro de registro; portanto, neste momento, o centro de registro precisa detectar ativamente atividade .
A partir da introdução acima, podemos ver que ambos os métodos de detecção de saúde em Nacos são usados, e a interação geral de monitoramento e verificação em Nacos é a seguinte. A seguir, apresentaremos o mecanismo de verificação de integridade para duas instâncias em Nacos em detalhes.
Mecanismo de verificação de integridade da instância temporária
No Nacos, os usuários podem registrar instâncias temporárias de duas maneiras, registro de serviço por meio do Nacos OpenAPI ou registro de serviço por meio do SDK fornecido pelo Nacos .
-
O método de registro do OpenAPI é, na verdade, que o usuário chame a interface Http para registrar o serviço de acordo com suas próprias necessidades e, em seguida, envie uma pulsação para o centro de registro por meio da interface Http. Ao registrar o serviço, uma tarefa de detecção de pulsação do cliente global será registrada. Depois que o serviço não receber uma pulsação do cliente por um período de tempo, a tarefa o marcará como não íntegro e, se não receber uma pulsação no intervalo, a tarefa o removerá.
-
O método de registro do SDK é, na verdade, manter uma conexão com o centro de registro através do RPC (na versão Nacos 2.x, a versão antiga ainda usa o método OpenAPI), e o cliente enviará periodicamente um heartbeat para o centro de registro Nacos através da conexão RPC para manter a conexão ativa. Se a conexão entre o cliente e o centro de registro for desconectada, o centro de registro excluirá ativamente os serviços registrados pelo cliente para obter o efeito de ficar offline. Ao mesmo tempo, a central de cadastro Nacos também registrará uma tarefa agendada para limpar clientes expirados quando a central de cadastro iniciar, para excluir aqueles clientes cujo estado de saúde exceda um período de tempo.
Pelas características acima, podemos constatar que para diferentes tipos de uso, o Nacos possui as mesmas características para verificações de saúde: o cliente envia um heartbeat para a central de cadastro, e a central de cadastro desliga após a conexão ser desconectada ou o heartbeat expirar. Remover instâncias não íntegras
Mecanismo permanente de verificação de integridade da instância
No Nacos, o SDK é usado para registrar a instância permanente na forma de OpenAPI, o que pode garantir que a verificação de integridade da instância permanente não seja afetada mesmo depois que o cliente ficar offline.
Para o monitoramento e inspeção das instâncias permanentes, a Nacos utiliza o mecanismo de detecção da central de cadastro.Ao inicializar o serviço permanente, a central de cadastramento registrará a tarefa de temporização da detecção de acordo com o tipo de protocolo selecionado pelo cliente. O Nacos agora fornece três protocolos de detecção integrados, ou seja, Http, TCP e MySQL. De um modo geral, Http e TCP já podem cobrir a maioria dos cenários de verificação de integridade.
O MySQL é usado principalmente em cenários de negócios especiais. Por exemplo, os bancos de dados primário e secundário precisam fornecer acesso externo por meio do nome do serviço. Quando for necessário determinar se o banco de dados atualmente acessado é o banco de dados primário, nossa interface de verificação de integridade neste time é uma verificação se o banco de dados é o banco de dados primário Biblioteca de comandos MySQL.
Devido à característica de que as instâncias de serviço persistentes sempre existem antes de serem ativamente excluídas, as tarefas agendadas para sondar a atividade detectarão continuamente o status de integridade do serviço e marcarão as instâncias que não podem ser detectadas com sucesso como não íntegras.
Mas às vezes haverá tal cenário, alguns serviços não querem verificar seu estado de saúde, Nacos também fornece uma configuração de lista branca correspondente, os usuários podem configurar o serviço para a lista branca, então Nacos desistirá de sua verificação de saúde, O estado de saúde de a instância é sempre o estado de integridade transmitido pelo usuário.
Mecanismo de verificação de integridade no modo de cluster
Para os serviços sob o cluster, um serviço Nacos ficará a cargo apenas de uma central de registro no cluster Nacos, e as informações de serviço dos outros nós são apenas uma cópia do cluster, para que os assinantes sempre possam obter todos os serviços ao consultar a lista de lista de serviços . A instância temporária enviará apenas informações de pulsação para seu nó de registro responsável, e o nó de serviço de registro executará a detecção de integridade na instância permanente pela qual é responsável. Depois de obter o status de integridade, o nó de registro atualmente responsável sincronizará as informações de integridade com o cluster Outros registros em .
Na Nacos, o registro de serviços pode ser dividido em duas categorias do ponto de vista dos métodos de registro. O primeiro tipo é registrado através da conexão SDK RPC, e o cliente manterá um link com a central de cadastro. A segunda categoria é o registro de IP e porta por meio do OpenAPI.
O primeiro tipo de método SDK
Só é necessário estabelecer uma conexão com qualquer nó no cluster do centro de registro, e então esse nó é responsável pelo cliente. O centro de registro registrará uma tarefa de sincronização global na inicialização, que é usada para sincronizar as informações de todos os nós pelos quais é responsável atualmente com outros nós do cluster, e outros nós não responsáveis também criarão o cliente Em geral, conexão -clientes do tipo possuem um conceito de tempo de renovação. Ao receber informações de sincronização de outros nós, o tempo de renovação é atualizado para o horário atual. Se outros nós do cluster não receberem Se as informações de sincronização do nó que não é responsável por si é recebido, o nó é considerado não saudável, para verificar o estado de saúde do nó que não é responsável por si mesmo.
O segundo tipo de método OPENAPI
A instância temporária registrada pelo OpenAPI também atualiza o tempo de pulsação da instância temporária correspondente de outros nós, sincronizando o nó pelo qual é responsável com outros nós, de modo a garantir que outros nós não excluam ou modifiquem o estado de integridade dessa instância.
Anteriormente, apontamos especificamente que é uma instância temporária, mas não todas as instâncias. Você deve ter pensado ou deve ter pensado que esse método seria redundante para nós persistentes. As instâncias permanentes sempre existirão no registro até que sejam ativamente excluídas. Em seguida, verificamos a integridade A instância não será excluída, portanto, só precisamos notificar o restante dos nós quando o status de saúde da instância permanente do nó responsável mudar
