hystrix熔斷 簡介

在過去的幾天里，我一直在探索Netflix Hystrix庫，并欣賞了這個出色的庫所提供的功能。

引用Hystrix網站上的內容：

Hystrix是一個延遲和容錯庫，旨在隔離對遠程系統，服務和第三方庫的訪問點，停止級聯故障，并在不可避免發生故障的復雜分布式系統中實現彈性。

這里有很多關鍵字可以解析，但是在我看來，體驗Hystrix的最佳方法是嘗試一個示例用例。

不可預測的服務

考慮一個服務，一個奇怪的服務，它接受具有以下結構的json消息并返回確認：

{"id":"1","payload": "Sample Payload","throw_exception":false,"delay_by": 0 }

該服務接收有效負載，但另外還接收兩個字段：delay_by使服務在延遲（以毫秒為單位）后確認響應，而“ throw_exceptions”字段將在指定的延遲后導致異常！

這是一個示例響應：

{"id":"1","received":"Sample Payload","payload":"Reply Message" }

如果您一直遵循，這是該示例的 github存儲庫， 本示例已使用Netflix Karyon 2 ，并且可以通過以下方式非常簡潔地表達處理請求的代碼–了解如何放置rx-java庫在這里很好地利用：

import com.netflix.governator.annotations.Configuration; import rx.Observable; import service1.domain.Message; import service1.domain.MessageAcknowledgement;import java.util.concurrent.TimeUnit;public class MessageHandlerServiceImpl implements MessageHandlerService {@Configuration("reply.message")private String replyMessage;public Observable<MessageAcknowledgement> handleMessage(Message message) {logger.info("About to Acknowledge");return Observable.timer(message.getDelayBy(), TimeUnit.MILLISECONDS).map(l -> message.isThrowException()).map(throwException -> {if (throwException) {throw new RuntimeException("Throwing an exception!");}return new MessageAcknowledgement(message.getId(), message.getPayload(), replyMessage);});}}

在這一點上，我們有一個很好的候選服務，可以使其響應任意延遲和失敗。

服務的客戶

現在轉到此服務的客戶端。 我正在使用Netflix Feign進行此調用，這是另一個很棒的庫，它所需要的只是用以下方式注釋的Java接口：

package aggregate.service;import aggregate.domain.Message; import aggregate.domain.MessageAcknowledgement; import feign.RequestLine;public interface RemoteCallService {@RequestLine("POST /message")MessageAcknowledgement handleMessage(Message message); }

它使用以下幾行的配置來創建實現此接口所需的代理：

RemoteCallService remoteCallService = Feign.builder().encoder(new JacksonEncoder()).decoder(new JacksonDecoder()).target(RemoteCallService.class, "http://127.0.0.1:8889");

我有多個終結點，這些終結點將呼叫委派給該遠程客戶端，所有這些終結點都沿以下方式顯示url模式– http：// localhost：8888 / noHystrix？message = Hello＆delay_by = 0＆throw_exception = false ，第一個是終結點的示例不使用Hystrix。

沒有Hystrix案例

作為第一個示例，如果我嘗試調用http：// localhost：8888 / noHystrix？message = Hello＆delay_by = 5000＆throw_exception = false或說http：// localhost：8888 / ，請考慮在沒有Hystrix的情況下調用Remote服務。 noHystrix？message = Hello＆delay_by = 5000＆throw_exception = true ，在這兩種情況下，用戶對端點的請求只會在響應之前掛起5秒鐘。

這里應該立即顯示一些事情：

如果服務響應緩慢，則客戶端對服務的請求將被迫等待響應返回。

在高負載下，處理用戶流量的所有線程很可能會用盡，從而使進一步的用戶請求失敗。

如果服務拋出異常，則客戶端將無法正常處理該異常。

顯然，需要像Hystrix這樣的東西來處理所有這些問題。

Hystrix命令包裝遠程調用

我在前一個案例中使用了50個用戶負載進行了一次小負載測試，結果如下：

================================================================================ ---- Global Information -------------------------------------------------------- > request count 50 (OK=50 KO=0 ) > min response time 5007 (OK=5007 KO=- ) > max response time 34088 (OK=34088 KO=- ) > mean response time 17797 (OK=17797 KO=- ) > std deviation 8760 (OK=8760 KO=- ) > response time 50th percentile 19532 (OK=19532 KO=- ) > response time 75th percentile 24386 (OK=24386 KO=- ) > mean requests/sec 1.425 (OK=1.425 KO=- )

從服務中延遲5秒實質上會導致25秒的第75個百分位時間！，現在考慮使用Hystrix命令包裝服務調用進行相同的測試：

================================================================================ ---- Global Information -------------------------------------------------------- > request count 50 (OK=50 KO=0 ) > min response time 1 (OK=1 KO=- ) > max response time 1014 (OK=1014 KO=- ) > mean response time 22 (OK=22 KO=- ) > std deviation 141 (OK=141 KO=- ) > response time 50th percentile 2 (OK=2 KO=- ) > response time 75th percentile 2 (OK=2 KO=- ) > mean requests/sec 48.123 (OK=48.123 KO=- )

奇怪的是，現在第75個百分位數的時間是2毫秒！這是怎么可能的，使用Hystrix提供的出色工具，答案變得顯而易見，這是此測試的Hystrix儀表板視圖：

此處發生的情況是前10個請求超時，默認情況下使用Hystrix命令超時超過一秒，一旦前十個事務失敗，Hystrix會將命令短路，從而阻止對遠程服務的任何請求，因此低響應時間。 關于為什么這些事務未顯示為失敗的原因，是因為此處存在一個后備，當失敗時該后備會優雅地響應用戶請求。

結論

這樣做的目的是為了闡明為什么需要一個像Hystrix這樣的庫的動機，在此之后，我將詳細介紹將Hystrix集成到應用程序中所需要的內容以及這個出色的庫提供的功能的廣度。

翻譯自: https://www.javacodegeeks.com/2015/10/gentle-introduction-to-hystrix.html

hystrix熔斷 簡介

總結

以上是生活随笔為你收集整理的hystrix熔断 简介_Hystrix简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。