Mise en œuvre du modèle de conception du disjoncteur

Pour une implémentation de disjoncteur simple et directe, consultez Failsafe. Ex:

CircuitBreaker breaker = new CircuitBreaker()
  .withFailureThreshold(5)
  .withSuccessThreshold(3)
  .withDelay(1, TimeUnit.MINUTES);

Failsafe.with(breaker).run(() -> connect());

Ne devient pas beaucoup plus simple.

Apache commons a quelques implémentations pour plusieurs types de disjoncteurs légers, voici un lien vers les documents

Le projet fournit les classes EventCountCircuitBreaker et ThresholdCircuitBreaker, et un résumé AbstractCircuitBreaker afin que vous puissiez implémenter le vôtre.

Le code est open sources et est hébergé sur github, donc toute personne essayant d'implémenter le modèle devrait au moins jeter un coup d'œil.

Printemps cloud offre d'intéressants intégration avec Hystrix. Vous devriez probablement y jeter un oeil...

Concernant le motif lui-même

Vous pouvez obtenir beaucoup d'informations utiles sur ce modèle à Martin Fowler's blog. Il contient l'implémentation ruby ainsi que des références pour l'implémentation dans d'autres langages.

Concernant l'implémentation java spring

Veuillez consulter la bibliothèque JRugged. Il contient la mise en œuvre du disjoncteur au printemps ainsi que d'autres modèles de conception.

Vous n'avez pas besoin d'utiliser Spring cloud ou Spring boot pour utiliser Hystrix.
En utilisant hystrix-javanica , il est facile d'utiliser Hystrix avec plain old Spring aussi.

Voici un exemple de méthodes de secours (les deux méthodes, getMessageTimeout et getMessageException, échouent par défaut):

@Configuration
@ComponentScan
@EnableAspectJAutoProxy
public class CircuitBreakingWithHystrix {

  @Bean
  public HystrixCommandAspect hystrixAspect() {
    return new HystrixCommandAspect();
  }

  public static void main(String[] args) throws Throwable {
    ApplicationContext ctx
      = new AnnotationConfigApplicationContext(CircuitBreakingWithHystrix.class);
    ExampleService ex = ctx.getBean(ExampleService.class);
    for (int i = 0; i < 1000; i++) {
      System.out.println(ex.getMessageException());
      System.out.println(ex.getMessageTimeout());
    }
  }

  @Service
  class ExampleService {

    /*
     * The default Hystrix timeout is 1 second. So the default 
     * version of this method will always fail.  
     * Adding the @HystrixProperty will cause 
     * the method to succeed.
     */
    @HystrixCommand(
      commandProperties = { 
      //@HystrixProperty(name = EXECUTION_ISOLATION_THREAD_TIMEOUT_IN_MILLISECONDS,
      //                 value = "5000")
      },
      fallbackMethod = "messageFallback"
    )
    public String getMessageTimeout() {
      try {
        //Pause for 4 seconds
        Thread.sleep(4000);
      } catch (InterruptedException ex) {
        // Do something clever with this
      }
      return "result";
    }

    @HystrixCommand(
      fallbackMethod = "messageFallback")
    public String getMessageException() {
      throw new RuntimeException("Bad things happened");
    }

    private String messageFallback(Throwable hre) {
      return "fallback";
    }

  }

Vous pouvez également examiner le throwable envoyé à la méthode de secours pour identifier pourquoi l'appel de méthode a échoué.

Vous pouvez jeter un oeil à JCircuitBreaker. La mise en œuvre là-bas implémente disjoncteur comme approche.

Veuillez noter que ce n'est pas une implémentation 1:1 du modèle car il ne définit pas d'états fixes comme "half-open". Au lieu de cela, il prend la décision (si le disjoncteur doit être ouvert ou fermé) en se basant sur l'état actuel de l'application (en utilisant ce qu'on appelle la "stratégie de rupture"). Néanmoins, il devrait être possible de définir une telle "stratégie de rupture" qui évalue les échecs seuils-il devrait donc être possible d'implémenter également le modèle original en utilisant JCircuitBreaker.