最小限のリファクタリング (または期待できる限り) で既存のログ機能を維持しながら、 Steeltoe CircuitBreakerを使用して、Hystrix CircuitBreaker パターンを既存の ASP.NET Core マイクロサービスに追加する作業を行っています。
現在、着信 HTTP リクエストは次のレイヤーを通過します。
Controller -> Service -> DerivedProvider -> AbstractProvider (and out to downstream service)
Hystrix では、次のようになりたいと思います。
Controller -> Service -> HystrixCommand<> -> DerviedProvider (via HystrixCommand's ExecuteAsync) -> AbstractProvider
多くのコンテキストがプロバイダーに保存され、コンストラクターを介してレイヤーに渡されAbstractProvider、発信呼び出しの結果に関係なく、そのコンテキストを使用してログが記録されます。はAbstractProvider、オプションの実行前および実行後のコールバックなど、かなりの量のカスタム ロジックもサポートしています。post コールバックは、成功しなかった応答メッセージが返されたときに呼び出されます。言うまでもなく、レイヤーを大幅に変更することは、私の現在の理解では簡単ではないように思えます。
Hystrix のドキュメントとSteeltoe CircuitBreakerのドキュメントを確認した後、HystrixCommand<>.RunFallbackAsync().
おそらく、その答えは、オーバーライドできるライフサイクル フックに関係しているでしょうか? のようにonFallbackStart(HystrixInvokable commandInstance？
最終的には、これらの既存のコールバック/ロギング機能providersをHystrixCommand. HystrixCommandがプロバイダーとそのコンテキストをどのように管理するか、いつ/どこでそれらにアクセスできるか、またはアクセスできないかを理解できていません。あなたが提供できる提案や方向性は非常に高く評価されます! 乾杯！