Решение ключа команды Hystrix, Имя службы +IP-адрес экземпляра + Имя API?

Question

Я хочу внедрить Hystrix в шлюз (например, zuul). Шлюз обнаружит службу A, B или C, при условии, что служба A имеет 10 экземпляров и 10 Api. Мой вопрос

Какова лучшая практика для решения командного ключа? Имя службы +IP-адрес экземпляра + имя API.

Похоже, это дает лучший уровень детализации, так как различные API, различные экземпляры не будут нарушать окружность, но это может занимать большой объем командной клавиши.

Вот пример. Предположим, я общаюсь со службой A, есть 5 экземпляров службы A, я общаюсь со службой A с балансировщиком нагрузки, а ip - как показано ниже.

• 192.168.1.1
• 192.168.1.2
• 192.168.1.3
• 192.168.1.4
• 192.168.1.5

и сервис А имеет 4 API, как

• CreateOrder
• deleteOrder
• UpdateOrder
• GetOrder

Теперь есть много вариантов для выбора клавиши управления.

1. уровень обслуживания, как serviceA
2. уровень экземпляра, например 192.168.1.1
3. Экземпляр + уровень API, как 192.168.1.1_getOrder

для первого варианта есть только одна команда hystrix, она требует меньше ресурсов процессора или памяти, но если один API потерпит неудачу, все API - это разрывы круга.

Answer 1

Ваш HystrixCommandKey идентифицирует HystrixCommand, который инкапсулирует aService.anOperation(), Таким образом, HystrixCommandKey может быть назван с использованием составного ключа Service + Command (но не экземпляры, запускающие службу или IP-адреса). Если вы не предоставите явное имя, имя класса HystrixCommand используется по умолчанию HystrixCommandKey,

Панель инструментов Hystrix затем агрегирует метрики для каждого из HystrixCommandKey (Service+Command) из каждого экземпляра, работающего в кластере служб.

В вашем примере это было бы serviceA_createOrder,