Modo de disjuntor curcuit
Em ambientes distribuídos, especialmente em sistemas distribuídos com estruturas de microsserviço, é muito comum um sistema de software chamar outro sistema remoto. O Callee desta chamada remota pode ser outro processo, ou outro host da rede. A maior diferença entre essa chamada remota e a chamada interna do processo é que a chamada remota pode falhar ou ficar sem resposta até o tempo limite. Pior ainda, se vários chamadores ligarem para o mesmo serviço pendente, é muito provável que a espera do tempo limite de um serviço se espalhe rapidamente para todo o sistema distribuído, causando uma reação em cadeia e, assim, consuma uma grande quantidade de recursos de todo o sistema distribuído. Pode eventualmente levar à paralisia do sistema.
O modo de disjuntor é impedir desastres causados por uma reação em cadeia semelhante a uma cascata em sistemas distribuídos.
Uma vez que um certo aparelho elétrico tenha problemas, o fusível do circuito soprará para evitar o desastre. Os disjuntores são semelhantes aos fusíveis de circuito. A ideia de implementação é muito simples. Eles podem encapsular serviços remotos que precisam de proteção e monitorar o número de falhas internamente. Quando o número de falhas atingir um determinado limite, todas as chamadas subsequentes para o serviço retornarão diretamente o erro ao chamador após a interceptação do disjuntor e não continuará chamando o serviço que já teve problemas, alcançando assim o objetivo de proteger o chamador. Todo o sistema não experimentará uma reação em cadeia de cascata causada pelo tempo limite.
1. Modo básico
A figura acima é a estrutura de um disjuntor (Curcuit Breaker), que possui dois estados básicos (fechado e aberto) e uma ação básica de viagem:
No estado próximo, o cliente solicita o serviço ao fornecedor diretamente através do disjuntor sem obstáculos. O valor de retorno do fornecedor é retornado diretamente ao cliente pelo disjuntor.
No estado aberto, depois que o cliente inicia uma solicitação de serviço ao fornecedor, o disjuntor não transferirá a solicitação para o fornecedor, mas retornará diretamente o cliente e o caminho entre o cliente e o fornecedor está quebrado.
Trip: No estado próximo, se o fornecedor continuar com tempo e erro, depois de atingir o limite especificado, a viagem ocorrerá no disjuntor e, em seguida, o estado do disjuntor entrará aberto de perto.
2. Modo estendido
No modo básico do disjuntor, ele garante que o disjuntor não seja chamado quando o disjuntor estiver no estado aberto, mas também precisamos de medidas adicionais para redefinir o disjuntor após a restauração do fornecedor. Uma maneira viável é detectar regularmente se o serviço do fornecedor é restaurado e, uma vez restaurado, o status está definido para fechar. O estado do disjuntor da tentativa de disjuntores é meio aberto.
3. Use ocasiões para disjuntores:
Um fornecedor geralmente é muito estável. Se uma falha ocorrer, o tempo de inspeção e recuperação leva muito tempo e não poderá ser reparado rapidamente em pouco tempo, esse serviço é mais adequado para o uso do modo de disjuntor. Caso contrário, é provável que leve a um efeito de pingue-pongue.
3. O disjuntor não é adequado para as ocasiões:
Para impedir que um aplicativo tente invocar um serviço remoto ou acessar um recurso compartilhado, esse padrão pode não ser adequado se a operação for altamente falhar.
Para o processamento de aplicativos que acessam recursos dedicados locais, como estruturas de dados na memória. Nesse ambiente, geralmente não é adequado e o uso de um disjuntor aumenta apenas a sobrecarga do sistema.
A seguir, é apresentada uma introdução direta a como usar o disjuntor do Spring Cloud.
Springcloud Netflix implementa o nome da biblioteca do disjuntor chamada Hystrix. Sob a arquitetura de microsserviços, geralmente existem vários níveis de chamadas de serviço. A seguir, é apresentado um diagrama esquemático do navegador acessando os microsserviços de back -end através da API sob a arquitetura de microsserviços:
A falha de um tempo limite de microsserviço pode levar a uma reação em cadeia em cascata. Na figura abaixo, a Hystrix impede que isso aconteça através de um disjuntor de feedback autônomo.
O serviço B na figura falha por algum motivo e fica indisponível. Todas as chamadas para o Serviço B vão sair. Quando a chamada para B falhar em atingir um limite específico (20 falhas ocorrem em 5 segundos são o valor padrão definido pelo Hystrix), o link estará no estado aberto e, em seguida, todas as chamadas para o Serviço B não serão executadas, em vez disso, uma mensagem de fallback indicando o link aberto fornecido pelo disjuntor. O Hystrix fornece um mecanismo correspondente que permite aos desenvolvedores definir esta mensagem Fallbak.
O Link da Open bloqueia um erro de cascata, permitindo que serviços inundados ou errados tenham tempo para corrigir. Este fallback pode ser outra chamada protegida Hystrix, dados estáticos ou valor nulo legal. Os fallbacks podem formar uma estrutura de cadeia, portanto, o primeiro fallback que chama outros serviços comerciais na parte inferior para retornar dados estáticos.
Em seguida, vamos direto ao ponto, adicionando um disjuntor aos dois clusters de serviço mundial da Hello World anteriores para impedir que um dos Hello World diminua, fazendo com que o sistema não falhe no tempo limite.
1. Adicione a biblioteca Hystrix para apoiar os disjuntores no projeto Pom.xml do MAVEN (projeto de fita ou Feign introduzido no capítulo anterior)
<Depencency> <PuerpId> org.springframework.cloud </frugiD> <TRATIFACTID> Spring-cloud-starter-hystrix </artifactId> </dependency>
2. Use disjuntores em aplicações de fita
1). Adicionar @enablecircuitbreaker anotação na aula de inicialização de inicialização da primavera
@Springbootapplication@habilablediscoveryclient@EnableCircuitBreakerPublic Classe ServiceribbonApplication {public static void main (string [] args) {springapplication.run (serviceribbonApplication.class, args); }2). Anote o método de acessar serviços com @hystrixCommand Anotation
@ServicePublic Class Helloservice {@AUTOWIRED RESTTEMPLAT RESTTEMPLATE; @HystrixCommand (FallbackMethod = "ServiceFailure") public String gethellocontent () {return RestTemplate.getForObject ("http: // service-helloworld/", string.class); } public String serviceFailure () {return "Hello World Service não está disponível!"; }}A anotação @hystrixCommand define um disjuntor que encapsula o método Gethellocontant (). Quando o serviço de serviço-alvo de serviço acessa falhar em atingir o limite, o serviço-alvo de serviço não será mais chamado. Em vez disso, ele retorna o método serviceFailure () definido pelo FallbackMethod. Há dois pontos que precisam receber atenção especial ao definir o método FallbackMethod definido pela anotação @hystrixCommand:
Primeiro, o valor de retorno e o tipo de parâmetro de FallbackMethod precisam ser exatamente os mesmos que o método anotado por @hystrixCommand. Caso contrário, uma exceção será lançada em tempo de execução. Por exemplo, neste exemplo, o valor de retorno de serviçoFailure () e o valor de retorno do método gethellocontant () são ambas as seqüências.
Segundo, quando o serviço subjacente falha, o FallbackMethod não substitui todo o método anotado por @hystrixCommand (Gethellocontant neste exemplo), mas apenas o serviço específico acessado através do RestTemplate. Você pode ver na saída do sistema que, mesmo que falhe, ainda haverá "Call Service-Shelloworld" na saída do console.
Inicie o serviço Eureka, inicie apenas dois serviços Helloworld e, em seguida, interrompa um deles (simule um dos microsserviços suspensos), visite http: // localhost: 8901/e depois atualize, devido ao balanceamento de carga, você pode ver as duas páginas a seguir, alternadamente. Você pode ver que o segundo serviço pendente é substituído pelo método de manuseio de erros definido na faixa de opções.
4. Use os disjuntores em aplicações Feign
1). O Feign já suporta disjuntores, para que você não precise pensar no método da Ribbon, adicione anotações extras à aula de inicialização de inicialização da primavera.
2). Adicione a classe Fallback com a anotação @FeignClient, que deve implementar a interface modificada pelo @FeignClient.
@FeignClient (name = "Service-toLorld", Fallback = HelloworldServiceFailure.Class) Interface pública HelloworldService {@ReQuestMapping (value = "/", Method = requestMethod.get) public string dizhello (); }3). Para criar a classe HelloWorldServiceFailure, você deve implementar a interface HelloworldService modificada por @FeignClient. Observe que você adiciona @Component ou @Service Anotation para gerar um feijão no contêiner de mola.
@ComPonentPublic Classe HelloworldServiceFailure implementa HelloworldService {@Override public String SayHello () {System.out.println ("Hello World Service não está disponível!"); retornar "Hello World Service não está disponível!"; }}4). Nas versões Brixton antes da Spring Cloud, Feign ativou automaticamente o disjuntor por padrão, mas a recente versão do Dalston alterou a configuração padrão para proibir.
Por razões, consulte: https://github.com/spring-cloud/spring-cloud-netflix/issues/1277. Preste atenção a este ponto. Portanto, para usar os disjuntores em Feign, você deve adicionar a seguinte configuração no Application.yml:
Feign: Hystrix: Ativado: true
5). Inicie o aplicativo Feign e visite http: // localhost: 8902/hello para ver o mesmo efeito que a fita.
Referência: http://projects.spring.io/spring-cloud/spring-cloud.html#_circuit_breaker_hystrix_clients
http://projects.spring.io/spring-cloud/spring-cloud.html#spring-cloud-feign-hystrix
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.