Контекст поставщика услуг доступа в RunFallbackAsync HystrixCommand
Я работаю над добавлением шаблона Hystrix CircuitBreaker в существующий микросервис ASP.NET Core, используя Steeltoe CircuitBreaker, сохраняя при этом существующую функциональность ведения журналов с минимальным рефакторингом (или так мало, как я могу надеяться).
В настоящее время входящий HTTP-запрос проходит через следующие слои:
Controller -> Service -> DerivedProvider -> AbstractProvider (and out to downstream service)
с Hystrix я хотел бы, чтобы это было:
Controller -> Service -> HystrixCommand<> -> DerviedProvider (via HystrixCommand's ExecuteAsync) -> AbstractProvider
В поставщиках хранится много контекста, который передается через слои через конструкторы, а затем ведется регистрация в AbstractProvider
используя этот контекст, независимо от результата исходящего вызова. AbstractProvider
также поддерживает достаточное количество настраиваемой логики, такой как дополнительные обратные вызовы до и после выполнения. Почтовый обратный вызов вызывается, когда возвращается неуспешное ответное сообщение. Излишне говорить, что радикальное изменение слоев не кажется мне легким, с моим нынешним пониманием.
После просмотра документации Hystrix и документации Steeltoe CircuitBreaker мне неясно, могу ли я поддерживать поставщика и его контекст и доступ к нему в рамках HystrixCommand<>.RunFallbackAsync()
,
Возможно, ответ может касаться хуков жизненного цикла, которые вы можете переопределить? подобно onFallbackStart(HystrixInvokable commandInstance
?
В конечном счете, цель состоит в том, чтобы просто убедиться, что любая существующая функция обратного вызова / регистрации не потеряна, оборачивая эти существующие providers
в HystrixCommand
, Я не понимаю, как HystrixCommand
управляет провайдерами и их контекстом, а также когда / где у вас есть или нет доступа к ним. Любые предложения или направления, которые вы можете предложить, будут очень благодарны! Ура!
0 ответов
Команды Hystrix могут быть добавлены в контейнер службы или могут быть "новыми" (т.е. new MyHystrixCommand(...), в зависимости от того, что наиболее подходит для вашей ситуации.
Помните, что команды Hystrix нельзя использовать повторно... т.е. после того, как вы создадите и выполните команду, вы не должны пытаться использовать ее повторно.
Ясно, что если вы новичок в HystrixCommand, вы можете определить любые аргументы, которые вы хотите, в конструкторе и предоставить ему правильные аргументы (т.е. состояние), которые он должен выполнить.
Если вы вводите его в контроллер или другую службу... то перед использованием... вы можете инициализировать его любым состоянием, которое вы хотите, используя свойства, а затем выполнить его.