Hystrix vs. Sentinel: A Tale of Two Circuit Breakers (Part 2)

In the last post, we compared the two libraries at a high level. Now, we are going to see how they are used with some code examples.

Bookstore Example

The example used here is from this Spring tutorial. This is a famous bookstore sample app.

Before we get started, please make sure you follow the steps in the original documentation to download and set up the sample app.

We can re-use the example with some modifications. Sentinel is part of the most recent Spring Framework release. So, there is no additional dependency change.

Let's directly go to reading/src/main/java/hello/BookService.java and paste the following code:

@Service
public class BookService {
  private final RestTemplate restTemplate;
  public BookService(RestTemplate rest) {
    this.restTemplate = rest;
  }
  @SentinelResource(value = "readingList", fallback = "reliable")
  public String readingList() {
    URI uri = URI.create("http://localhost:8090/recommended");
    return this.restTemplate.getForObject(uri, String.class);
  }
  public String reliable() {
    return "Cloud Native Java (O'Reilly)";
  }
}

As you can see, all we did was replace the @HystrixCommand annotation with @SentinelResource. The value attribute labels the method we would like to apply to the circuit breaker. And the fallback attribute points out the fallbackMethod function. Then. we add thefallback function reliable() . The function does the same as in the example.

So far, it has been pretty close to what Hystrix is doing. However, as mentioned in the previous article, Hystrix dictates the circuit breaker behavior. Once you point out the resource, the condition to trigger the circuit breaker is taken care of.

Sentinel, on the other hand, gives that control to the user, which means that the user has to create a rule to define that condition. Let's do that and add the rule. It can be appended to the end of the file.

DegradeRuleManager.loadRules(Collections.singletonList(
    new DegradeRule("readingList") // resource name
        .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO) // strategy
        .setCount(0.5) // threshold
        .setTimeWindow(10) // circuit breaking timeout (in second)
));

We just created a DegradeRule, setting the mode to be exception ratio, the threshold to 0.5 (1 out of 2), and the recovery time to 10 seconds. The DegradeRuleManager will load this rule to take effect.

Let's try it out: We only start the Reading Service but not the Bookstore service. So, every time a request comes in, it will fail. After two attempts (and two failures), we shall see the fallback function kick in:

Cloud Native Java (O'Reilly)

Now, let's start the Bookstore service. After 10 seconds, we shall see the normal response:

Spring in Action (Manning), Cloud Native Java (O'Reilly), Learning Spring Boot (Packt)

In a production environment, it is actually easier to use the Sentinel dashboard to configure this rule than adding the rule via code. Here is a screenshot:

Wait, There's More

So far, we've looked at the same feature as Hystrix has performed. And actually, Sentinel needs one more step. But here is the justification: users can achieve more with that flexibility. Now, let's see an example.

Sentinel allows rules to be based on different metrics. In this example, we are using QPS.

First, let's locate the main class bookstore/src/main/java/hello/BookstoreApplication.java

@RestController
@SpringBootApplication
public class BookstoreApplication {
    private static final Logger LOGGER = LoggerFactory.getLogger(BookstoreApplication.class);
    @SentinelResource(value = "readingList", blockHandler = "handleTooManyRequests")
    @RequestMapping(value = "/recommended")
    public String readingList(){
        return "Spring in Action (Manning), Cloud Native Java (O'Reilly), Learning Spring Boot (Packt)";
    }
    public String handleTooManyRequests(BlockException ex) {
        LOGGER.error("Too many requests: " + ex.getClass().getSimpleName());
        return "Sentinel in Action";
    }
  public static void main(String[] args) {
    SpringApplication.run(BookstoreApplication.class, args);
  }

We added a @SentinelResource, but instead of the fallback function, we use the blockHandler function. This function will simply print out a message showing "Sentinel in Action." Now, we need to add a new rule when this function will be triggered:

FlowRule rule = new FlowRule("readingList")
    .setCount(1);
FlowRuleManager.loadRules(Collections.singletonList(rule));

The rule will apply when we have more than 1 request per second. This piece of code can be appended to the end of the file.

After we start the BookStore service, with the first request, we shall get the normal response:

Spring in Action (Manning), Cloud Native Java (O'Reilly), Learning Spring Boot (Packt)

However, if we generate more than 1 request in one second, we shall see the blockHandlerfunction kick in:

Sentinel in Action

And after 1 second, we can see the normal response again.

Again, in a real production environment, users can use the dashboard to configure and monitor the traffic.

Summary

Sentinel aims to provide users with multiple options to control the flow into their services. By doing so, it requires users to define the rules via GUI or code. Other than QPS, users can control the number of threads, or even create a white list for access control. With the growing complexity of distributed services, this model will better serve the user's requirements.