A estabilidade das chamadas de API é considerada o indicador mais importante de serviços de dados. Existem vários fatores que influenciam esse indicador. "Kangaroo Cloud Data Service Platform DataAPI" não apenas conduziu testes de estresse e testes de desempenho e estabilidade de chamadas muitas vezes Ajuste e também fornece uma variedade de métodos de otimização de itens de configuração para os clientes ajustarem por conta própria. No entanto, as chamadas de API ainda podem falhar ao encontrar tráfego intenso inesperado ou outras situações repentinas.
Quando o tráfego continua a crescer e atinge ou excede a capacidade de suporte do próprio serviço, torna-se importante estabelecer um mecanismo de autoproteção para os serviços do sistema. "Kangaroo Cloud Data Service Platform DataAPI" combina chamadas de API e conceitos de controle de fluxo de microsserviços e lança função de downgrade do disjuntor< /span> garante ao máximo a estabilidade das chamadas de API e a disponibilidade do sistema.
Este artigo espera usar a explicação mais popular e exemplos apropriados para ajudar todos a entender o que é degradação do disjuntor.
Visão geral do downgrade do disjuntor
De modo geral, quando se trata de proteção de tráfego de sistemas de microsserviços, três métodos são mencionados: limitação de corrente, disjuntor e downgrade. Na verdade, todos eles são padrões de projeto importantes para tolerância a falhas do sistema.
Limitação de corrente, disjuntor, rebaixamento
● Limitação de corrente
Limitação de corrente é uma medida para limitar a frequência de solicitações do sistema e a frequência de execução de algumas funções internas para evitar que todo o sistema fique indisponível devido a picos repentinos de tráfego. A limitação de tráfego é principalmente um meio de defesa e proteção, pois controla o tráfego e evita problemas a partir da origem do tráfego.
● fusível
O mecanismo disjuntor é uma medida de resposta automatizada. Quando o tráfego é muito intenso ou há um problema com o serviço downstream, ele pode desconectar automaticamente a interação com o serviço downstream para evitar mais falhas. Ao mesmo tempo, o mecanismo do disjuntor também pode autodiagnosticar se os erros no sistema downstream foram corrigidos ou se o tráfego upstream foi reduzido a níveis normais para alcançar a auto-recuperação.
Os circuitos são mais parecidos commétodos de correção automatizados, que podem ocorrer quando o serviço não consegue suportar um grande número de solicitações ou outras falhas ocorrem no serviço e o processamento de solicitações é restrito e você também pode tentar restaurá-lo.
●Rebaixamento do serviço
é principalmente para funções de negócios não essenciais. Se o processo de negócios principal exceder o valor de pico estimado, será necessária uma limitação atual. Downgrade Geralmente considera a integridade do sistema distribuído e corta a fonte de tráfego da origem. O downgrade é mais como um método de previsão: sob a premissa de prever picos de tráfego, a experiência do serviço é reduzida configurando funções antecipadamente, ou funções menores são suspensas para garantir uma resposta suave das principais funções do processo do sistema.
rebaixamento do disjuntor
A limitação de corrente e o disjuntor também podem ser considerados meios de degradação do serviço. Na arquitetura de microsserviços, os serviços e as chamadas entre serviços geralmente se concentram no tráfego. Os desenvolvedores precisam considerar o roteamento de tráfego, controle de tráfego, modelagem de tráfego e disjuntores. Degrade a proteção adaptativa contra sobrecarga do sistema, a proteção de tráfego de pontos de acesso e outras dimensões para garantir a estabilidade dos microsserviços. Entre eles, o disjuntor e o downgrade tendem a garantir a estabilidade dos links principais ou dos serviços principais no link de chamada de microsserviço.
Conforme mostrado na figura abaixo, quando o serviço D está anormalmente indisponível, isso afetará os serviços A, B, G e F. Se não for controlado, todo o microsserviço pode eventualmente ser paralisado. O que o disjuntor faz é parar de chamar o serviço serviceD após atingir um determinado limite de erro; o downgrade retornará o conteúdo de downgrade personalizado do desenvolvedor para, pelo menos, garantir a disponibilidade geral do link.
Introdução às regras do disjuntor
「Kangaroo Cloud Data Service Platform DataAPI」 atualmente fornece três estratégias de disjuntores. Cada API pode e só pode ser associada a um disjuntor. estratégia. Os tipos de estratégia são:
● Proporção de chamadas lenta (SLOW_REQUEST_RATIO)
Selecione taxa de chamada lenta como limite, você precisa definir o RT de chamada lenta permitido (ou seja, o tempo máximo de resposta), o tempo de resposta solicitado tempo de resposta Se o valor for maior que esse valor, será contada como uma chamada lenta. Quando o número de solicitações dentro do período estatístico da unidade (statIntervalMs) for maior que o número mínimo definido de solicitações e a proporção de chamadas lentas for maior que o limite, as solicitações serão automaticamente interrompidas no próximo período de disjuntor.
Após o tempo de queima, o fusível entrará noestado de recuperação de detecção (estado MEIO-ABERTO). Se o tempo de resposta da próxima solicitação for menor que o RT de chamada lenta definido encerrará o disjuntor. Se for maior que o RT de chamada lenta definido, o disjuntor será disjuntor novamente.
● Proporção anormal (ERROR_RATIO)
Quando o número de solicitações dentro do período estatístico da unidade (statIntervalMs) for maior que o número mínimo definido de solicitações e a proporção de exceções for maior que o limite, as solicitações serão automaticamente interrompidas no período de disjuntor subsequente.
Após o tempo de queima, o fusível entrará no estado de recuperação de detecção (estado MEIO-ABERTO).Se a próxima solicitação for concluída com sucesso (sem erro), a fusão terminará, caso contrário, queimará novamente. O intervalo limite para taxas de anomalia é [0,0, 1,0], representando 0% - 100%.
●Número de exceção (ERROR_COUNT)
Quando o número de exceções dentro do período estatístico da unidade exceder o limite, o disjuntor será desconectado automaticamente. Após a duração do fusível o fusível entrará no estado de recuperação de detecção (estado MEIO-ABERTO). Se a próxima solicitação for concluída com sucesso (sem erros), ele terminará o fusível, caso contrário, será fundido novamente.
DataAPI para aplicações de degradação de disjuntores
A seguir será apresentada a aplicação do downgrade do disjuntor em "Kangaroo Cloud Data Service Platform DataAPI" por meio de um exemplo.
fusível
O downgrade do disjuntor dos serviços de dados é implementado com base na estrutura do Sentinel. A definição de recursos do Sentinel é mais de nível de serviço, mas também fornece definição de recursos para código ou conteúdo especificado. Portanto, DataAPI é implementado definindo APIID como o único recurso limite de circuito Julgamento e implementação de ações específicas de disjuntores. Ao mesmo tempo, ao controlar as regras de geração de nomes de recursos, é alcançado o isolamento do ambiente entre a API de teste e a API oficial.
No processo de desenvolvimento e implementação, a maior dificuldade é que o Sentinel suporta nativamente o controle de cluster da estratégia de limitação atual, mas não suporta o controle de cluster da estratégia de disjuntor. O método adotado pela DataAPI é usar o nó mestre para obter o controle do cluster, que inclui principalmente os dois pontos a seguir.
● Como carregar regras de disjuntor somente para o nó mestre
Primeiro de tudo, estratégia de disjuntor é carregada através do DegradeRuleManager com base na memória. Como é baseado em memória, a persistência deve ser feita, caso contrário o programa será reiniciado e as regras serão apagadas. Aqui, o MySQL é usado para criar uma tabela de regras de disjuntores para modificar os detalhes da regra.
Em segundo lugar, ao iniciar, obtenha a lista de instâncias de gateway por meio de nacos e selecione o nó primário. Chame o método namingService.getAllInstance de nacos para obter todas as instâncias de gateway. Selecione a primeira instância de gateway íntegro como o nó mestre e armazene as informações de IP do nó mestre em redis na forma de valor de chave. Essa chave redis será atualizada quando o nó mestre for reeleito. Cada vez que todas as instâncias do cluster de gateway são iniciados, eles primeiro determinam se o nó atual é Como nó mestre, apenas o nó mestre executará a ação de carregamento inicial da política de disjuntor.
A DataAPI para a eleição do nó mestre aqui fezeleição automática. Mesmo que o nó mestre atual esteja inativo, ele ainda poderá ser eleito uma vez a cada minuto. O temporizador obtém instâncias de nós sobreviventes e seleciona novamente o nó primário para garantir alta disponibilidade. Quando o nó mestre for alterado, uma notificação Redis será enviada a todos os nós. Depois de receber a notificação, o novo nó mestre obterá a política de disjuntor mais recente do MySQL e a carregará na memória. No entanto, esta ação limpará o tráfego anterior as estatísticas e a janela de tempo serão redefinidas.
Finalmente, como sincronizar modificações de política no nó mestre. O serviço de dados adota o método de notificação redis channel. Cada gateway monitora as mensagens do canal. Somente o gateway que determina o nó atual como o nó mestre executará regras de memória operação de carga.
● Determinação do limite do cluster
O nó mestre executa o carregamento de regras e o julgamento de limite. Todos os exemplos no cluster executam solicitações de API normalmente. Somentejulgamento de limite iniciará um http solicitação para O nó mestre faz um julgamento e retorna o resultado se foi aprovado ou não. O gráfico geral do fluxo de trabalho é o seguinte:
O julgamento limite é dividido em dois modos:
· Padrões de erro, que também podem ser divididos em número de erros ou taxas de erro
· Modo de chamada lenta, refere-se à proporção de solicitações de chamada lenta
Como o nó primário é considerado a instância B, mas o erro ocorreu na instância A/C, é necessário gerar manualmente exceções ou chamadas lentas na instância B. Quando ocorre uma exceção na solicitação do nó, o nó mestre recebe o sinalizador de exceção e lança a exceção manualmente. Neste momento, o Sentinel pode detectá-lo e o número da exceção será aumentado em um. As chamadas lentas são implementadas modificando o complateTime da solicitação para que o contador possa determinar a chamada lenta.
Downgrade
Ele é usado para configurar o conteúdo rebaixado na página de edição da API. A condição de configuração é que a política do disjuntor precise ser configurada primeiro. Quando o disjuntor for ligado, o gateway retornará conteúdo rebaixado completamente definido pelo usuário. Este conteúdo deve estar no formato json.
A principal solução para o downgrade é a contradição entre recursos insuficientes e maior acesso. Com recursos limitados, ele pode lidar comalta simultaneidade e um grande número de solicitações< uma eu=2 >. Principalmente quando a fonte de dados acessada pela configuração da API não pode transportar grande tráfego, com recursos limitados, para atingir o efeito acima, algumas restrições em algumas funções do serviço precisam ser implementadas, mas não completamente indisponíveis. O sistema retornará ao estado padrão valor para garantir que todo o sistema possa funcionar sem problemas.
A implementação do código de downgrade é relativamente simples: após a condição de julgamento entrar em vigor, basta reescrever a resposta do objeto ServerWebExchange.
Endereço de download do "White Paper do produto Dutstack":https://www.dtstack.com/resources/1004?src=szsm
Endereço para download do "Documento técnico sobre práticas do setor de governança de dados":https://www.dtstack.com/resources/1001?src=szsm
Para quem deseja conhecer ou consultar mais sobre produtos de big data, soluções industriais e cases de clientes, visite o site oficial do Kangaroo Cloud:https://www.dtstack. com/?src=szkyzg
IntelliJ IDEA 2023.3 e atualização anual da versão principal do JetBrains Novo conceito de "programação defensiva": torne-se um trabalho estável GitHub .com roda mais de 1.200 hosts MySQL, como atualizar perfeitamente para 8.0? A equipe Web3 de Stephen Chow lançará um aplicativo independente no próximo mês O Firefox será eliminado? Visual Studio Code 1.85 lançado, janela flutuante Yu Chengdong: Huawei lançará produtos disruptivos no próximo ano e reescreverá a história da indústria EUA CISA Recomenda-se abandonar C/C++ e eliminar vulnerabilidades de segurança de memória TIOBE Dezembro: espera-se que C# se torne a linguagem de programação do ano Artigo escrito por Lei Jun 30 anos atrás: "Princípios e Design de Sistemas Especialistas para Determinação de Vírus de Computador