O que há de novo no API7 Enterprise 3.2.9: Configuração de Verificação de Saúde Aprimorada

Introdução aos Novos Recursos de Verificação de Saúde

Na versão 3.2.9 do API7 Enterprise, a experiência de interação de configuração para verificações de saúde foi completamente otimizada.

1. Os itens de configuração anteriormente dispersos foram logicamente agrupados, como configurações de sondas e critérios para determinar nós saudáveis e não saudáveis, tornando-os mais estruturados.

2. Alguns nomes de itens de configuração abstratos foram transformados em expressões mais intuitivas e semânticas, permitindo que os usuários insiram diretamente os parâmetros relevantes através de um formato de preenchimento de lacunas, obtendo assim uma compreensão mais clara dos efeitos práticos das configurações.

3. Durante a configuração dos nós upstream e dos processos de verificação de saúde, foram adicionadas mais mensagens de prompt para ajudar os usuários a entender melhor a conexão inerente entre os nós upstream e as verificações de saúde, facilitando assim a conclusão mais fácil das tarefas de configuração.

Conceitos Básicos de Verificações de Saúde

No API7 Enterprise, a configuração de prioridade dos nós upstream está intimamente ligada aos mecanismos de balanceamento de carga e verificações de saúde. Quando os usuários configuram vários nós upstream com diferentes prioridades para o gateway, o gateway prioriza os nós de maior prioridade durante o balanceamento de carga. Isso significa que, enquanto os nós de maior prioridade permanecerem saudáveis, o gateway continuará a rotear o tráfego para esses nós.

Somente quando todos os nós de maior prioridade forem considerados indisponíveis devido a falhas nas verificações de saúde, o gateway degradará automaticamente, redirecionando o tráfego para os nós upstream de próxima prioridade. Esse design garante a utilização eficiente do tráfego e a alta disponibilidade do sistema.

Vale ressaltar que, se vários níveis de prioridade de nós upstream forem configurados no serviço, mas a função de verificação de saúde estiver desativada, todas as solicitações dos clientes serão sempre roteadas para os nós de maior prioridade, independentemente de seu estado de saúde real.

Métodos de Configuração para Verificações de Saúde

Configuração da Sonda

Uma sonda é usada para detectar a vivacidade e o estado do serviço dos nós upstream. No APISIX, a sonda é como um "inspetor" que bate regularmente na porta para verificar se o serviço upstream está funcionando corretamente. Se encontrar algum problema ou se o serviço estiver "indisponível", ele informa ao APISIX: "Este serviço está atualmente indisponível, então segure o envio de solicitações aqui." Esse processo de "bater na porta" é realizado através de sondas.

A sonda inclui principalmente os seguintes itens de configuração:

• Esquema da Sonda: O tipo de protocolo usado pela sonda de verificação de saúde, suportando TCP, HTTP e HTTPS.

• Concorrência: Este item de configuração permite definir o número de solicitações de verificação de saúde concorrentes. Em outras palavras, este é o número de vezes que você deseja "bater na porta" simultaneamente para verificar a responsividade dos serviços upstream. Ajustando a concorrência, você pode simular possíveis solicitações concorrentes em cenários reais, avaliando assim melhor o desempenho e a estabilidade dos serviços upstream.

• Host: Especifica o endereço do host do servidor upstream a ser verificado. É como determinar em qual casa "bater na porta".

• Porta: O número da porta do serviço upstream. É como saber em qual porta bater durante a sonda.

• Caminho: Se você estiver usando uma sonda HTTP, este item de configuração especifica o caminho da URL que você deseja acessar. É como dizer à sonda para verificar o quarto exato uma vez dentro.

Critérios para Determinar Nós Saudáveis

Em relação à determinação de nós saudáveis, o sistema verifica regularmente os nós anteriormente marcados como não saudáveis no intervalo definido pelo usuário (em segundos) para garantir a detecção oportuna e o tratamento adequado de quaisquer anomalias transitórias dos nós.

Se a sonda usar o protocolo TCP, o nó é considerado saudável após a sonda se conectar com sucesso ao nó upstream o número de vezes definido pelo usuário.

Se a sonda usar o protocolo HTTP/HTTPS, o sistema considera o nó saudável apenas quando ele recebe continuamente solicitações de sonda com códigos de status especificados (como 200 e 302) do nó. Isso significa que o nó é considerado como funcionando corretamente apenas quando ele retorna continuamente esses códigos de status específicos.

Critérios para Determinar Nós Não Saudáveis

Em relação à determinação de nós não saudáveis, o método de configuração é semelhante à determinação de nós saudáveis. O sistema verifica regularmente os nós marcados como saudáveis no intervalo definido pelo usuário. Uma vez que esses nós atendem às condições não saudáveis predefinidas, eles são reclassificados como não saudáveis.

Ligeiramente diferente da determinação de nós saudáveis, um item de configuração adicional, a verificação de solicitação do cliente, é adicionado durante o processo de determinação de nós não saudáveis. Quando esse recurso é ativado, o gateway não apenas depende dos resultados da inspeção da sonda, mas também observa e analisa profundamente as solicitações dos clientes e as respostas reais dos serviços upstream. Com base nesses dados e nos critérios de julgamento definidos pelo usuário, o gateway pode avaliar com mais precisão o estado de execução dos serviços upstream.

Melhores Práticas para Verificações de Saúde

Selecionando o Tipo de Sonda Adequado

• Sonda TCP: Adequada para cenários que exigem apenas a confirmação de se a porta do serviço está aberta e acessível. Por exemplo, um serviço de banco de dados pode precisar apenas de uma sonda TCP para confirmar a abertura da porta.

• Sonda HTTP/HTTPS: Mais adequada para cenários que exigem a verificação de que não apenas a conexão de rede está normal, mas também que o serviço pode lidar corretamente com as solicitações. Por exemplo, para um servidor web ou serviço de API, precisamos garantir que ele possa não apenas receber conexões, mas também retornar páginas ou dados corretos.

Configuração Razoável dos Parâmetros de Verificação de Saúde

Ao configurar verificações de saúde, preste atenção a vários parâmetros-chave:

• Intervalo de Verificação: Não deve ser muito curto para evitar sobrecarga desnecessária ou muito longo para evitar resposta lenta em caso de problemas. Por exemplo, para um site de comércio eletrônico de alto tráfego, verificar a cada 30 segundos é uma escolha relativamente razoável. Esse intervalo não consome excessivamente os recursos do sistema nem atrasa a detecção e o tratamento de problemas no site.

  Claro, esse intervalo não é absoluto, e ajustes precisam ser feitos com base na situação real do site. Por exemplo, se o site experimentar flutuações significativas no tráfego ou picos de tráfego durante períodos específicos (como durante campanhas promocionais), pode ser necessário ajustar o intervalo de verificação para acomodar essas mudanças.

• Tempo Limite: O tempo que a sonda espera por uma resposta do serviço. Se o serviço não responder dentro desse tempo, a sonda considera o serviço não saudável. Esse valor deve ser definido de acordo com o tempo de resposta real do serviço.

• Contagem de Tentativas: O número de vezes que a sonda tenta se conectar antes de determinar que o serviço está não saudável. Esse valor deve ser moderado para evitar julgamentos errados.

Ajustando Estratégias com Base no Negócio

As estratégias de verificação de saúde devem ser ajustadas com base na situação real do negócio. Se um serviço normalmente experimenta altas cargas durante períodos específicos, os intervalos de verificação de saúde podem ser aumentados ou as contagens de tentativas reduzidas durante esses períodos para evitar pressão adicional sobre o serviço.

Ativando a Verificação de Solicitação do Cliente conforme Apropriado

A verificação de solicitação do cliente pode determinar efetivamente o estado do serviço com base nas solicitações reais do negócio, especialmente para identificar problemas intimamente relacionados à lógica do negócio. No entanto, pode não ser adequada para todos os cenários de negócio.

1. Serviços de Baixo Tráfego: Se o tráfego do serviço for baixo, as verificações de saúde passivas baseadas em solicitações do cliente podem não fornecer pontos de dados suficientes para avaliar com precisão o estado do serviço. Nesses casos, confiar em verificações de sonda ativas pode ser mais confiável.

2. Considerações de Desempenho em Ambientes de Alta Concorrência: As verificações de saúde passivas exigem o monitoramento e o processamento de cada solicitação do cliente, o que pode aumentar a sobrecarga adicional de desempenho em ambientes de alta concorrência. Se o desempenho for uma preocupação primária e o serviço tiver sido adequadamente monitorado por outros meios, as verificações de saúde passivas podem ser consideradas para fechamento.

3. Existência de Outros Sistemas de Monitoramento: Se sistemas de monitoramento maduros já tiverem sido implantados na empresa, capazes de capturar e analisar o estado do serviço em tempo real, as verificações de saúde passivas podem não ser necessárias para evitar redundância de dados e complexidade adicional.

Conclusão

Verificações de saúde são um aspecto crucial para garantir a alta disponibilidade dos gateways de API. Na versão 3.2.9 do API7 Enterprise, otimizamos completamente a configuração interativa das verificações de saúde, simplificando as operações e melhorando a experiência do usuário.

Ao configurar adequadamente as sondas, definir critérios para nós saudáveis e não saudáveis e ajustar estratégias com base nas necessidades reais do negócio, os usuários podem monitorar com mais eficácia o estado dos serviços upstream, garantindo que o tráfego seja sempre roteado para nós saudáveis. Isso não apenas aumenta a estabilidade e a disponibilidade do sistema, mas também garante que as solicitações dos usuários recebam respostas oportunas e precisas.