Hystrix文档-实现原理
流程圖
下圖展示了當(dāng)你使用 Hystrix 來(lái)包裝你請(qǐng)求依賴服務(wù)時(shí)的流程：
接下來(lái)將詳細(xì)介紹如下問(wèn)題：
1. 構(gòu)建?HystrixCommand?或者?HystrixObservableCommand?對(duì)象
使用 Hystrix 的第一步是創(chuàng)建一個(gè)?HystrixCommand?或者?HystrixObservableCommand?對(duì)象來(lái)表示你需要發(fā)給依賴服務(wù)的請(qǐng)求。你可以向構(gòu)造器傳遞任意參數(shù)。
若只期望依賴服務(wù)每次返回單一的回應(yīng)，按如下方式構(gòu)造一個(gè)?HystrixCommand?即可：
| 1 | HystrixCommand command = new HystrixCommand(arg1, arg2); |
若期望依賴服務(wù)返回一個(gè) Observable，并應(yīng)用『Observer』模式監(jiān)聽(tīng)依賴服務(wù)的回應(yīng)，可按如下方式構(gòu)造一個(gè)?HystrixObservableCommand：
| 1 | HystrixObservableCommand command = new HystrixObservableCommand(arg1, arg2); |
2. 執(zhí)行命令
Hystrix 命令提供四種方式（HystrixCommand?支持所有四種方式，而?HystrixObservableCommand僅支持后兩種方式）來(lái)執(zhí)行你包裝的請(qǐng)求：
- execute()?—— 阻塞，當(dāng)依賴服務(wù)響應(yīng)（或者拋出異常/超時(shí)）時(shí)，返回結(jié)果
- queue()?—— 返回?Future?對(duì)象，通過(guò)該對(duì)象異步得到返回結(jié)果
- observe()?—— 返回?Observable?對(duì)象，立即發(fā)出請(qǐng)求，在依賴服務(wù)響應(yīng)（或者拋出異常/超時(shí)）時(shí)，通過(guò)注冊(cè)的?Subscriber?得到返回結(jié)果
- toObservable()?—— 返回?Observable?對(duì)象，但只有在訂閱該對(duì)象時(shí)，才會(huì)發(fā)出請(qǐng)求，然后在依賴服務(wù)響應(yīng)（或者拋出異常/超時(shí)）時(shí)，通過(guò)注冊(cè)的?Subscriber?得到返回結(jié)果
| 1 2 3 4 | K value = command.execute(); Future<K> fValue = command.queue(); Observable<K> ohValue = command.observe(); // hot observable（注：調(diào)用observe()方法時(shí)，請(qǐng)求立即發(fā)出） Observable<K> ocValue = command.toObservable(); // cold observable（注：只有在返回的ocValue上調(diào)用subscribe時(shí)，才會(huì)發(fā)出請(qǐng)求） |
在內(nèi)部實(shí)現(xiàn)中，execute()?是同步調(diào)用，內(nèi)部會(huì)調(diào)用?queue().get()?方法。queue()?內(nèi)部會(huì)調(diào)用?toObservable().toBlocking().toFuture()。也就是說(shuō)，HystrixCommand?內(nèi)部均通過(guò)一個(gè)?Observable?的實(shí)現(xiàn)來(lái)執(zhí)行請(qǐng)求，即使這些命令本來(lái)是用來(lái)執(zhí)行同步返回回應(yīng)這樣的簡(jiǎn)單邏輯。
3. 結(jié)果是否有緩存
如果請(qǐng)求結(jié)果緩存這個(gè)特性被啟用，并且緩存命中，則緩存的回應(yīng)會(huì)立即通過(guò)一個(gè)?Observable?對(duì)象的形式返回。
4. 請(qǐng)求線路是否是開(kāi)路
當(dāng)執(zhí)行一個(gè)命令時(shí)，Hystrix 會(huì)先檢查熔斷器狀態(tài)，確定請(qǐng)求線路是否是開(kāi)路
如果請(qǐng)求線路是開(kāi)路，Hystrix 將不會(huì)執(zhí)行這個(gè)命令，而是直接使用『失敗回退邏輯』
5. 線程池/請(qǐng)求隊(duì)列/信號(hào)量占滿時(shí)會(huì)發(fā)生什么
如果和當(dāng)前需要執(zhí)行的命令相關(guān)聯(lián)的線程池和請(qǐng)求隊(duì)列（或者信號(hào)量，如果不使用線程池），Hystrix 將不會(huì)執(zhí)行這個(gè)命令，而是直接使用『失敗回退邏輯』
6. 使用?HystrixObservableCommand.construct()?還是?HystrixCommand.run()
Hystrix 將根據(jù)你使用類的不同，內(nèi)部使用不同的方式來(lái)請(qǐng)求依賴服務(wù)：
- HystrixCommand.run()?—— 返回回應(yīng)或者拋出異常
- HystrixObservableCommand.construct()?—— 返回 Observable 對(duì)象，并在回應(yīng)到達(dá)時(shí)通知 observers，或者回調(diào)?onError?方法通知出現(xiàn)異常
若?run()?或者?construct()?方法耗時(shí)超過(guò)了給命令設(shè)置的超時(shí)閾值，執(zhí)行請(qǐng)求的線程將拋出?TimeoutException（若命令本身并不在其調(diào)用線程內(nèi)執(zhí)行，則單獨(dú)的定時(shí)器線程會(huì)拋出該異常）。在這種情況下，Hystrix 將會(huì)執(zhí)行失敗回退邏輯，并且會(huì)忽略最終（若執(zhí)行命令的線程沒(méi)有被中斷）返回的回應(yīng)。
若命令本身并不拋出異常，并正常返回回應(yīng)，Hystrix 在添加一些日志和監(jiān)控?cái)?shù)據(jù)采集之后，直接返回回應(yīng)。Hystrix 在使用?run()?方法時(shí)，Hystrix 內(nèi)部還是會(huì)生成一個(gè)?Observable?對(duì)象，并返回單個(gè)請(qǐng)求，產(chǎn)生一個(gè)?onCompleted?通知；而在 Hystrix 使用?construct()?時(shí)，會(huì)直接返回由?construct()?產(chǎn)生的?Observable?對(duì)象
7. 計(jì)算線路健康度
Hystrix 會(huì)將請(qǐng)求成功，失敗，被拒絕或超時(shí)信息報(bào)告給熔斷器，熔斷器維護(hù)一些用于統(tǒng)計(jì)數(shù)據(jù)用的計(jì)數(shù)器。
這些計(jì)數(shù)器產(chǎn)生的統(tǒng)計(jì)數(shù)據(jù)使得熔斷器在特定的時(shí)刻，能短路某個(gè)依賴服務(wù)的后續(xù)請(qǐng)求，直到恢復(fù)期結(jié)束，若恢復(fù)期結(jié)束根據(jù)統(tǒng)計(jì)數(shù)據(jù)熔斷器判定線路仍然未恢復(fù)健康，熔斷器會(huì)再次關(guān)閉線路。
8. 失敗回退邏輯
當(dāng)命令執(zhí)行失敗時(shí)，Hystrix 將會(huì)執(zhí)行失敗回退邏輯，失敗原因可能是：
失敗回退邏輯包含了通用的回應(yīng)信息，這些回應(yīng)從內(nèi)存緩存中或者其他固定邏輯中得到，而不應(yīng)有任何的網(wǎng)絡(luò)依賴。如果一定要在失敗回退邏輯中包含網(wǎng)絡(luò)請(qǐng)求，必須將這些網(wǎng)絡(luò)請(qǐng)求包裝在另一個(gè)?HystrixCommand?或?HystrixObservableCommand?中。
當(dāng)使用?HystrixCommand?時(shí)，通過(guò)實(shí)現(xiàn)?HystrixCommand.getFallback()?返回失敗回退時(shí)的回應(yīng)。
當(dāng)使用?HystrixObservableCommand?時(shí)，通過(guò)實(shí)現(xiàn)?HystrixObservableCommand.resumeWithFallback()?返回 Observable 對(duì)象來(lái)通知 observers 失敗回退時(shí)的回應(yīng)。
若失敗回退方法返回回應(yīng)，Hystrix 會(huì)將這個(gè)回應(yīng)返回給命令的調(diào)用者。若 Hystrix 內(nèi)部調(diào)用?HystrixCommand.getFallback()?時(shí)，會(huì)產(chǎn)生一個(gè) Observable 對(duì)象，并包裝用戶實(shí)現(xiàn)的?getFallback()?方法返回的回應(yīng)；若 Hystrix 內(nèi)部調(diào)用?HystrixObservableCommand.resumeWithFallback()?時(shí)，會(huì)將用戶實(shí)現(xiàn)的?resumeWithFallback()?返回的 Observable 對(duì)象直接返回。
若你沒(méi)有實(shí)現(xiàn)失敗回退方法，或者失敗回退方法拋出異常，Hystrix 內(nèi)部還是會(huì)生成一個(gè) Observable 對(duì)象，但它不會(huì)產(chǎn)生任何回應(yīng)，并通過(guò)?onError?通知立即中止請(qǐng)求。Hystrix 默認(rèn)會(huì)通過(guò)?onError通知調(diào)用者發(fā)生了何種異常。你需要盡量避免失敗回退方法執(zhí)行失敗，保持該方法盡可能的簡(jiǎn)單不易出錯(cuò)。
若失敗回退方法執(zhí)行失敗，或者用戶未提供失敗回退方法，Hystrix 會(huì)根據(jù)調(diào)用執(zhí)行命令的方法的不同而產(chǎn)生不同的行為：
- execute()?—— 拋出異常
- queue()?—— 成功返回?Future?對(duì)象，但其?get()?方法被調(diào)用時(shí)，會(huì)拋出異常
- observe()?—— 返回?Observable?對(duì)象，當(dāng)你訂閱它的時(shí)候，會(huì)立即調(diào)用 subscriber 的?onError?方法中止請(qǐng)求
- toObservable()?—— 返回?Observable?對(duì)象，當(dāng)你訂閱它的時(shí)候，會(huì)立即調(diào)用 subscriber 的?onError?方法中止請(qǐng)求
9. 返回正常回應(yīng)
若命令成功被執(zhí)行，Hystrix 將回應(yīng)返回給調(diào)用方，或者通過(guò)?Observable?的形式返回。根據(jù)上述調(diào)用命令方式的不同（如第2條所示），Observable?對(duì)象會(huì)進(jìn)行一些轉(zhuǎn)換：
- execute()?—— 產(chǎn)生一個(gè)?Future?對(duì)象，行為同?.queue()?產(chǎn)生的?Future?對(duì)象一樣，接著調(diào)用其?get()?方法，生成由內(nèi)部產(chǎn)生的?Observable?對(duì)象返回的回應(yīng)
- queue()?—— 將內(nèi)部產(chǎn)生的?Observable?對(duì)象轉(zhuǎn)換（Decorator模式）成?BlockingObservable?對(duì)象，以產(chǎn)生并返回?Future?對(duì)象
- observe()?—— 產(chǎn)生?Observable?對(duì)象后，立即訂閱（ReplaySubject）以使命令得以執(zhí)行（異步），返回該?Observable?對(duì)象，當(dāng)你調(diào)用其?subscribe?方法時(shí)，重放產(chǎn)生的回應(yīng)信息和通知給用戶提供的訂閱者
- toObservable()?—— 返回?Observable?對(duì)象，你必須調(diào)用其?subscribe?方法，以使命令得以執(zhí)行。
熔斷器
下圖展示了?HystrixCommand?或?HystrixObservableCommand?如何與?HystrixCircuitBreaker?進(jìn)行交互，以及?HystrixCircuitBreaker?的決策邏輯流程，包括熔斷器內(nèi)部計(jì)數(shù)器如何工作。
線路的開(kāi)路閉路詳細(xì)邏輯如下：
依賴隔離
Hystrix 通過(guò)使用『艙壁模式』（注：將船的底部劃分成一個(gè)個(gè)的艙室，這樣一個(gè)艙室進(jìn)水不會(huì)導(dǎo)致整艘船沉沒(méi)。將系統(tǒng)所有依賴服務(wù)隔離起來(lái)，一個(gè)依賴延遲升高或者失敗，不會(huì)導(dǎo)致整個(gè)系統(tǒng)失敗）來(lái)隔離依賴服務(wù)，并限制訪問(wèn)這些依賴服務(wù)的并發(fā)度。
線程 & 線程池
通過(guò)將對(duì)依賴服務(wù)的訪問(wèn)執(zhí)行放到單獨(dú)的線程，將其與調(diào)用線程（例如 Tomcat 線程池中的線程）隔離開(kāi)來(lái)，調(diào)用線程能空出來(lái)去做其他的工作而不至于被依賴服務(wù)的訪問(wèn)阻塞過(guò)長(zhǎng)時(shí)間。
Hystrix 使用獨(dú)立的，每個(gè)依賴服務(wù)對(duì)應(yīng)一個(gè)線程池的方式，來(lái)隔離這些依賴服務(wù)，這樣，某個(gè)依賴服務(wù)的高延遲只會(huì)拖慢這個(gè)依賴服務(wù)對(duì)應(yīng)的線程池。
當(dāng)然，也可以不使用線程池來(lái)使你的系統(tǒng)免受依賴服務(wù)失效的影響，這需要你小心的設(shè)置網(wǎng)絡(luò)連接/讀取超時(shí)時(shí)間和重試配置，并保證這些配置能正確正常的運(yùn)作，以使這些依賴服務(wù)在失效時(shí)，能快速返回錯(cuò)誤。
Netflix 在設(shè)計(jì) Hystrix 時(shí)，使用線程/線程池來(lái)實(shí)現(xiàn)隔離，原因如下：
- 多數(shù)系統(tǒng)同時(shí)運(yùn)行了（有時(shí)甚至多達(dá)數(shù)百個(gè)）不同的后端服務(wù)，這些服務(wù)由不同開(kāi)發(fā)組開(kāi)發(fā)。
- 每個(gè)服務(wù)都提供了自己的客戶端庫(kù)
- 客戶端庫(kù)經(jīng)常會(huì)發(fā)生變動(dòng)
- 客戶端庫(kù)可能會(huì)改變邏輯，加入新的網(wǎng)絡(luò)請(qǐng)求
- 客戶端庫(kù)可能會(huì)包含重試邏輯，數(shù)據(jù)解析，緩存（本地緩存或分布式緩存），或者其他類似邏輯
- 客戶端庫(kù)對(duì)于使用者來(lái)說(shuō)，相當(dāng)于『黑盒』，其實(shí)現(xiàn)細(xì)節(jié)，網(wǎng)絡(luò)訪問(wèn)方式，默認(rèn)配置等等均對(duì)使用者透明
- In several real-world production outages the determination was “oh, something changed and properties should be adjusted” or “the client library changed its behavior.”
- 即使客戶端庫(kù)本身未發(fā)生變化，服務(wù)自身發(fā)生變化，也可能會(huì)影響其性能，從而導(dǎo)致客戶端配置不再可靠
- 中間依賴服務(wù)可能包含一些其依賴服務(wù)提供的客戶端庫(kù)，而這些庫(kù)可能不受控且配置不合理
- 絕大多數(shù)網(wǎng)絡(luò)訪問(wèn)都采用同步的方式進(jìn)行
- 客戶端代碼可能也會(huì)有失效或者高延遲，而不僅僅是在網(wǎng)絡(luò)訪問(wèn)時(shí)
線程池的優(yōu)勢(shì)
將依賴服務(wù)請(qǐng)求通過(guò)使用不同的線程池隔離，其優(yōu)勢(shì)如下：
- 系統(tǒng)完全與依賴服務(wù)請(qǐng)求隔離開(kāi)來(lái)，即使依賴服務(wù)對(duì)應(yīng)線程池耗盡，也不會(huì)影響系統(tǒng)其它請(qǐng)求
- 降低了系統(tǒng)接入新的依賴服務(wù)的風(fēng)險(xiǎn)，若新的依賴服務(wù)存在問(wèn)題，也不會(huì)影響系統(tǒng)其它請(qǐng)求
- 當(dāng)依賴服務(wù)失效后又恢復(fù)正常，其對(duì)應(yīng)的線程池會(huì)被清理干凈，相對(duì)于整個(gè) Tomcat 容器的線程池被占滿需要耗費(fèi)更長(zhǎng)時(shí)間以恢復(fù)可用來(lái)說(shuō)，此時(shí)系統(tǒng)可以快速恢復(fù)
- 若依賴服務(wù)的配置有問(wèn)題，線程池能迅速反映出來(lái)（通過(guò)失敗次數(shù)的增加，高延遲，超時(shí)，拒絕訪問(wèn)等等），同時(shí)，你可以在不影響系統(tǒng)現(xiàn)有功能的情況下，處理這些問(wèn)題（通常通過(guò)熱配置等方式）
- 若依賴服務(wù)的實(shí)現(xiàn)發(fā)生變更，性能有了很大的變化（這種情況時(shí)常發(fā)生），需要進(jìn)行配置調(diào)整（例如增加/減小超時(shí)閾值，調(diào)整重試策略等）時(shí)，也可以從線程池的監(jiān)控信息上迅速反映出來(lái)（失敗次數(shù)增加，高延遲，超時(shí)，拒絕訪問(wèn)等等），同時(shí)，你可以在不影響其他依賴服務(wù)，系統(tǒng)請(qǐng)求和用戶的情況下，處理這些問(wèn)題
- 線程池處理能起到隔離的作用以外，還能通過(guò)這種內(nèi)置的并發(fā)特性，在客戶端庫(kù)同步網(wǎng)絡(luò)IO上，建立一個(gè)異步的 Facade（類似 Netflix API 建立在 Hystrix 命令上的 Reactive、全異步化的那一套 Java API）
簡(jiǎn)而言之，通過(guò)線程池提供的依賴服務(wù)隔離，可以使得我們能在不停止服務(wù)的情況下，更加優(yōu)雅地應(yīng)對(duì)客戶端庫(kù)和子系統(tǒng)性能上的變化。
注：盡管線程池能提供隔離性，但你仍然需要對(duì)你的依賴服務(wù)客戶端代碼增加超時(shí)邏輯，并且/或者處理線程中斷異常，以使這些代碼不會(huì)無(wú)故地阻塞或者拖慢 Hystrix 線程池。
線程池的弊端
使用線程池的主要弊端是會(huì)增加系統(tǒng) CPU 的負(fù)載，每個(gè)命令的執(zhí)行，都包含了 CPU 任務(wù)的排隊(duì)，調(diào)度，上下文切換。
Netflix 在設(shè)計(jì) Hystrix 時(shí)，認(rèn)為相對(duì)于其帶來(lái)的好處，其帶來(lái)的負(fù)載的一點(diǎn)點(diǎn)升高對(duì)系統(tǒng)的影響是微乎其微的。
線程池的開(kāi)銷
Hystrix 的開(kāi)發(fā)人員測(cè)試了在子線程中執(zhí)行?construct()?或?run()?方法帶來(lái)的額外時(shí)延，以及在父線程中整個(gè)請(qǐng)求的耗時(shí)，通過(guò)這個(gè)測(cè)試，你能直觀了解 Hystrix 使用線程池帶來(lái)的一點(diǎn)點(diǎn)系統(tǒng)負(fù)載的升高影響（線程，監(jiān)控，日志，熔斷器等）。
Netflix API 使用線程池來(lái)隔離依賴服務(wù)，每天可以處理超過(guò) 100 億的 Hystrix 命令，每個(gè) API 實(shí)例有超過(guò) 40 個(gè)線程池，每個(gè)線程池有 5 到 20 個(gè)工作線程（絕大部分設(shè)置為 10 個(gè)線程）。
下圖展示了一個(gè)?HystrixCommand?以 60QPS 的速度，在一個(gè) API 實(shí)例（每臺(tái)服務(wù)器每秒運(yùn)行的線程數(shù)峰值為 350）上被執(zhí)行的耗時(shí)監(jiān)控：
（注：有 User 的表示使用線程池來(lái)隔離依賴服務(wù)后的耗時(shí)）
中位數(shù)顯示二者（未使用線程池和使用線程池）沒(méi)有差別。
90% 的情況下，使用線程池有 3ms 的延遲
99% 的情況下，使用線程池有 9ms 的延遲，盡管如此，相對(duì)于請(qǐng)求的總時(shí)間（2ms~28ms），延遲（0ms~9ms）基本可以忽略不計(jì)
90% 的情況下，這些延遲和在使用了熔斷器之后更高的延遲，在絕大多數(shù) Netflix 的需求來(lái)看，是微不足道的，更何況其能帶來(lái)系統(tǒng)穩(wěn)定性和魯棒性上的巨大提升。
對(duì)于那些本來(lái)延遲就比較小的請(qǐng)求（例如訪問(wèn)本地緩存成功率很高的請(qǐng)求）來(lái)說(shuō)，線程池帶來(lái)的開(kāi)銷是非常高的，這時(shí)，你可以考慮采用其他方法，例如非阻塞信號(hào)量（不支持超時(shí)），來(lái)實(shí)現(xiàn)依賴服務(wù)的隔離，使用信號(hào)量的開(kāi)銷很小。但絕大多數(shù)情況下，Netflix 更偏向于使用線程池來(lái)隔離依賴服務(wù)，因?yàn)槠鋷?lái)的額外開(kāi)銷可以接受，并且能支持包括超時(shí)在內(nèi)的所有功能。
信號(hào)量
除了線程池，隊(duì)列之外，你可以使用信號(hào)量（或者叫計(jì)數(shù)器）來(lái)限制單個(gè)依賴服務(wù)的并發(fā)度。Hystrix 可以利用信號(hào)量，而不是線程池，來(lái)控制系統(tǒng)負(fù)載，但信號(hào)量不允許我們?cè)O(shè)置超時(shí)和異步化，如果你對(duì)客戶端庫(kù)有足夠的信任（延遲不會(huì)過(guò)高），并且你只需要控制系統(tǒng)負(fù)載，那么你可以使用信號(hào)量。
HystrixCommand?和?HystrixObservableCommand?在兩個(gè)地方支持使用信號(hào)量：
- 失敗回退邏輯：當(dāng) Hystrix 需要執(zhí)行失敗回退邏輯時(shí)，其在調(diào)用線程（Tomcat 線程）中使用信號(hào)量
- 執(zhí)行命令時(shí)：如果設(shè)置了 Hystrix 命令的?execution.isolation.strategy?屬性為?SEMAPHORE，則 Hystrix 會(huì)使用信號(hào)量而不是線程池來(lái)控制調(diào)用線程調(diào)用依賴服務(wù)的并發(fā)度
你可以通過(guò)動(dòng)態(tài)配置（即熱部署）來(lái)決定信號(hào)量的大小，以控制并發(fā)線程的數(shù)量，信號(hào)量大小的估計(jì)和使用線程池進(jìn)行并發(fā)度估計(jì)一樣（僅訪問(wèn)內(nèi)存數(shù)據(jù)的請(qǐng)求，一般能達(dá)到耗時(shí)在 1ms 以內(nèi)，且能達(dá)到 5000rps，這樣的請(qǐng)求對(duì)應(yīng)的信號(hào)量可以設(shè)置為 1 或者 2。默認(rèn)值為 10）。
注意：如果依賴服務(wù)使用信號(hào)量來(lái)進(jìn)行隔離，當(dāng)依賴服務(wù)出現(xiàn)高延遲，其調(diào)用線程也會(huì)被阻塞，直到依賴服務(wù)的網(wǎng)絡(luò)請(qǐng)求超時(shí)。
信號(hào)量在達(dá)到上限時(shí)，會(huì)拒絕后續(xù)請(qǐng)求的訪問(wèn)，同時(shí)，設(shè)置信號(hào)量的線程也無(wú)法異步化（即像線程池那樣，實(shí)現(xiàn)『提交-做其他工作-得到結(jié)果』模式）
請(qǐng)求合并
你可以在?HystrixCommand?之前放置一個(gè)『請(qǐng)求合并器』（HystrixCollapser?為請(qǐng)求合并器的抽象父類），該合并器可以將多個(gè)發(fā)往同一個(gè)后端依賴服務(wù)的請(qǐng)求合并成一個(gè)。
下圖展示了在兩種場(chǎng)景（未增加『請(qǐng)求合并器』和增加『請(qǐng)求合并器』）下，線程和網(wǎng)絡(luò)連接數(shù)量（假設(shè)所有請(qǐng)求在一個(gè)很小的時(shí)間窗口內(nèi)，例如 10ms，是『并發(fā)』的）：
為什么要使用請(qǐng)求合并？
在并發(fā)執(zhí)行?HystrixCommand?時(shí)，利用請(qǐng)求合并能減少線程和網(wǎng)絡(luò)連接數(shù)量。通過(guò)使用?HystrixCollapser，Hystrix 能自動(dòng)完成請(qǐng)求的合并，開(kāi)發(fā)者不需要對(duì)現(xiàn)有代碼做批量化的開(kāi)發(fā)。
全局上下文（適用于所有 Tomcat 線程）
理想情況下，合并過(guò)程應(yīng)該發(fā)生在系統(tǒng)全局層面，這樣用戶發(fā)起的，由 Tomcat 線程執(zhí)行的所有請(qǐng)求都能被執(zhí)行合并操作。
例如，有這樣一個(gè)需求，用戶需要獲取電影評(píng)級(jí)，而這些數(shù)據(jù)需要系統(tǒng)請(qǐng)求依賴服務(wù)來(lái)獲取，對(duì)依賴服務(wù)的請(qǐng)求使用?HystrixCommand?進(jìn)行包裝，并增加了請(qǐng)求合并的配置，這樣，當(dāng)同一個(gè) JVM 中其他線程需要執(zhí)行同樣的請(qǐng)求時(shí)，Hystrix 會(huì)將這個(gè)請(qǐng)求同其他同樣的請(qǐng)求合并，只產(chǎn)生一個(gè)網(wǎng)絡(luò)請(qǐng)求。
注意：合并器會(huì)傳遞一個(gè)?HystrixRequestContext?對(duì)象到合并的網(wǎng)絡(luò)請(qǐng)求中，因此，下游系統(tǒng)需要支持批量化，以使請(qǐng)求合并發(fā)揮其高效的特點(diǎn)。
用戶請(qǐng)求上下文（適用于單個(gè) Tomcat 線程）
如果給?HystrixCommand?只配置成針對(duì)單個(gè)用戶進(jìn)行請(qǐng)求合并，則 Hystrix 只會(huì)在單個(gè) Tomcat 線程（即請(qǐng)求）中進(jìn)行請(qǐng)求合并。
例如，如果用戶想加載 300 個(gè)視頻對(duì)象的書(shū)簽，請(qǐng)求合并后，Hystrix 會(huì)將原本需要發(fā)起的 300 個(gè)網(wǎng)絡(luò)請(qǐng)求合并到一個(gè)。
對(duì)象模型和代碼復(fù)雜度
很多時(shí)候，當(dāng)你創(chuàng)建一個(gè)對(duì)象模型，適用于對(duì)象的消費(fèi)者邏輯，結(jié)果發(fā)現(xiàn)這個(gè)模型會(huì)導(dǎo)致生產(chǎn)者無(wú)法充分利用其擁有的資源。
例如，這里有一個(gè)包含 300 個(gè)視頻對(duì)象的列表，需要遍歷這個(gè)列表，并對(duì)每一個(gè)對(duì)象調(diào)用?getSomeAttribute()?方法，這是一個(gè)顯而易見(jiàn)的對(duì)象模型，但如果簡(jiǎn)單處理的話，可能會(huì)導(dǎo)致 300 次的網(wǎng)絡(luò)請(qǐng)求（假設(shè)?getSomeAttribute()?方法內(nèi)需要發(fā)出網(wǎng)絡(luò)請(qǐng)求），每一個(gè)網(wǎng)絡(luò)請(qǐng)求可能都會(huì)花上幾毫秒（顯然，這種方式非常容易拖慢系統(tǒng)）。
當(dāng)然，你也可以要求用戶在調(diào)用?getSomeAttribute()?之前，先判斷一下哪些視頻對(duì)象真正需要請(qǐng)求其屬性。
或者，你可以將對(duì)象模型進(jìn)行拆分，從一個(gè)地方獲取視頻列表，然后從另一個(gè)地方獲取視頻的屬性。
但這些實(shí)現(xiàn)會(huì)導(dǎo)致 API 非常丑陋，且實(shí)現(xiàn)的對(duì)象模型無(wú)法完全滿足用戶使用模式。 并且在企業(yè)級(jí)開(kāi)發(fā)時(shí)，很容易因?yàn)殚_(kāi)發(fā)者的疏忽導(dǎo)致錯(cuò)誤或者不夠高效，因?yàn)椴煌拈_(kāi)發(fā)者可能有不同的請(qǐng)求方式，這樣一個(gè)地方的優(yōu)化不足以保證在所有地方都會(huì)有優(yōu)化。
通過(guò)將合并邏輯下沉到 Hystrix 層，不管你如何設(shè)計(jì)對(duì)象模型，或者以何種方式去調(diào)用依賴服務(wù)，又或者開(kāi)發(fā)者是否意識(shí)到這些邏輯需要不需要進(jìn)行優(yōu)化，這些都不需要考慮，因?yàn)?Hystrix 能統(tǒng)一處理。
getSomeAttribute()?方法能放在它最適合的位置，并且能以最適合的方式被調(diào)用，Hystrix 的請(qǐng)求合并器會(huì)自動(dòng)將請(qǐng)求合并到合并時(shí)間窗口內(nèi)。
請(qǐng)求合并帶來(lái)的額外開(kāi)銷
請(qǐng)求合并會(huì)導(dǎo)致依賴服務(wù)的請(qǐng)求延遲增高（該延遲為等待請(qǐng)求的延遲），延遲的最大值為合并時(shí)間窗口大小。
若某個(gè)請(qǐng)求耗時(shí)的中位數(shù)是 5ms，合并時(shí)間窗口為 10ms，那么在最壞情況下（注：合并時(shí)間窗口開(kāi)啟時(shí)發(fā)起請(qǐng)求），請(qǐng)求需要消耗 15ms 才能完成。通常情況下，請(qǐng)求不太可能恰好在合并時(shí)間窗口開(kāi)啟時(shí)發(fā)起，因此，請(qǐng)求合并帶來(lái)的額外開(kāi)銷應(yīng)該是合并時(shí)間窗口的一般，在此例中是 5ms。
請(qǐng)求合并帶來(lái)的額外開(kāi)銷是否值得，取決于將要執(zhí)行的命令，高延遲的命令相比較而言不會(huì)有太大的影響。同時(shí)，緩存 Key 的選擇也決定了在一個(gè)合并時(shí)間窗口內(nèi)能『并發(fā)』執(zhí)行的命令數(shù)量：如果一個(gè)合并時(shí)間窗口內(nèi)只有 1~2 個(gè)請(qǐng)求，將請(qǐng)求合并顯然不是明智的選擇。事實(shí)上，如果單線程循環(huán)調(diào)用同一個(gè)依賴服務(wù)的情況下，如果將請(qǐng)求合并，會(huì)導(dǎo)致這個(gè)循環(huán)成為系統(tǒng)性能的瓶頸，因?yàn)槊恳粋€(gè)請(qǐng)求都需要等待 10ms 的合并時(shí)間周期。
然而，如果一個(gè)命令具有高并發(fā)度，并且能批量處理多個(gè)，甚至上百個(gè)的話，請(qǐng)求合并帶來(lái)的性能開(kāi)銷會(huì)因?yàn)橥掏铝康臉O大提升而基本可以忽略，因?yàn)?Hystrix 會(huì)減少這些請(qǐng)求所需的線程和網(wǎng)絡(luò)連接數(shù)量。
請(qǐng)求合并器的執(zhí)行流程
請(qǐng)求緩存
在?HystrixCommand?和?HystrixObservableCommand?的實(shí)現(xiàn)中，你可以定義一個(gè)緩存的 Key，這個(gè) Key 用于在同一個(gè)請(qǐng)求上下文（全局或者用戶級(jí)）中標(biāo)識(shí)緩存的請(qǐng)求結(jié)果，當(dāng)然，該緩存是線程安全的。
下例展示了在一個(gè)完整 HTTP 請(qǐng)求周期內(nèi)，兩個(gè)線程執(zhí)行命令的流程：
請(qǐng)求緩存有如下好處：
-
不同請(qǐng)求路徑上針對(duì)同一個(gè)依賴服務(wù)進(jìn)行的重復(fù)請(qǐng)求（有同一個(gè)緩存 Key），不會(huì)真實(shí)請(qǐng)求多次
這個(gè)特性在企業(yè)級(jí)系統(tǒng)中非常有用，在這些系統(tǒng)中，開(kāi)發(fā)者往往開(kāi)發(fā)的只是系統(tǒng)功能的一部分。（注：這樣，開(kāi)發(fā)者彼此隔離，不太可能使用同樣的方法或者策略去請(qǐng)求同一個(gè)依賴服務(wù)提供的資源）
例如，請(qǐng)求一個(gè)用戶的?Account?的邏輯如下所示，這個(gè)邏輯往往在系統(tǒng)不同地方被用到：
1
2
3
4
5
Account account = new UserGetAccount(accountId).execute();
//or
Observable<Account> accountObservable = new UserGetAccount(accountId).observe();
Hystrix 的?RequestCache?只會(huì)在內(nèi)部執(zhí)行?run()?方法一次，上面兩個(gè)線程在執(zhí)行?HystrixCommand?命令時(shí)，會(huì)得到相同的結(jié)果，即使這兩個(gè)命令是兩個(gè)不同的實(shí)例。
-
數(shù)據(jù)獲取具有一致性
因?yàn)榫彺娴拇嬖?#xff0c;除了第一次請(qǐng)求需要真正訪問(wèn)依賴服務(wù)以外，后續(xù)請(qǐng)求全部從緩存中獲取，可以保證在同一個(gè)用戶請(qǐng)求內(nèi)，不會(huì)出現(xiàn)依賴服務(wù)返回不同的回應(yīng)的情況。
-
避免不必要的線程執(zhí)行
在?construct()?或?run()?方法執(zhí)行之前，會(huì)先從請(qǐng)求緩存中獲取數(shù)據(jù)，因此，Hystrix 能利用這個(gè)特性避免不必要的線程執(zhí)行，減小系統(tǒng)開(kāi)銷。
若 Hystrix 沒(méi)有實(shí)現(xiàn)請(qǐng)求緩存，那么?HystrixCommand?和?HystrixObservableCommand?的實(shí)現(xiàn)者需要自己在?construct()?或?run()?方法中實(shí)現(xiàn)緩存，這種方式無(wú)法避免不必要的線程執(zhí)行開(kāi)銷。
總結(jié)
以上是生活随笔為你收集整理的Hystrix文档-实现原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 中年职场危机，这是我看过最靠谱的建议
- 下一篇： Java 线程池艺术探索