Hystrix command key decision, Service Name+Instance IP+Api Name?

user_3630822 0
Viewed 454

I want to implement Hystrix in gateway(like zuul). The gateway will discover service A, B or C, assume the service A has 10 instances and 10 Api. My question is.

What is the best practice for the command key decision? Service Name+Instance IP+Api Name.

it seems this gain the best detail level, as the different api, different instance fail will not circle break the other, But it may occupy large volume of command key.

Here is the example. Suppose I talk to service A, there are 5 instances of service A, I talk to service A with a load balancer, and the ip as below

  • 192.168.1.1
  • 192.168.1.2
  • 192.168.1.3
  • 192.168.1.4
  • 192.168.1.5

and service A has 4 api, like

  • createOrder
  • deleteOrder
  • updateOrder
  • getOrder

Now there are many options for the command key choosen.

  1. serivce level, like serviceA
  2. instance level, like 192.168.1.1
  3. instance + api level like 192.168.1.1_getOrder

for the first option, there are only one hystrix command, it take less cpu or memory, but if one api fail, all api are circle breaks.

hystrix fallback high-availability
1 Answers

Your HystrixCommandKey identifies a HystrixCommand, which encapsulates aService.anOperation(). Thus a HystrixCommandKey could be named using the composite key Service+Command (but not instances running the service or the IP addresses). If you do not provide an explicit name, the class name of HystrixCommand is used as the default HystrixCommandKey.

The Hystrix Dashboard then aggregates metrics for each of the HystrixCommandKey (Service+Command), from each instance running in the service cluster.

In your example, it would be serviceA_createOrder.

user_41240760
Related