容量越大越不壞？24萬塊硬盤故障率報告公布 這些產品零故障
8月5日消息，云存儲服務商Backblaze發布了最新的硬盤故障率報告，年故障率有所上升。Backblaze發布的硬盤季度統計數據，其中包括故障率等重要方面。這些結
微服務領域里有個詞叫服務熔斷，你知道這是啥不？
故事要從我讀大學那會說起。
因為功率問題，很多寢室都是不讓用吹風筒和熱水壺的。
但我那時候頭鐵，不僅用，而且還同時開了兩個熱水壺和一個吹風筒。直接給寢室電路來了個壓測。
不出意外的出了意外，寢室直接停電。
一時間，隔壁寢室燈火通明，我們寢室一片漆黑。
作為本科專業電氣工程的靚仔，我們意識到，這妥妥是電路過載導致斷路器跳閘了。
于是我們趁社管阿姨不注意，偷偷摸進配電房，手動將斷路器開關復位，寢室就來電了。
是真的有驚無險。
如果沒有這個斷路器，寢室總電路怕是得因為過載全部燒掉，我們幾個妥妥會提前進入社會大學。
我能畢業，全靠這個斷路器！
看到這里，我們知道了斷路器的作用，就是在電路出問題的時候及時斷開電路，避免過載，從而保護電路。
在微服務領域，我們也可以借鑒斷路器的思路，引入了服務熔斷的概念。
服務熔斷，也就是 Circuit Breaker，本質上是一種軟件設計模式，用于在分布式系統中處理服務調用失敗的情況。
假設有個 A 服務調用 B 服務的場景，如果 B 服務已經出現頻繁失敗的情況，A 繼續調用只會加劇 B 服務的負擔，嚴重的時候，有可能導致 B 服務崩潰，甚至出現 B 服務重啟后立馬被打崩的情況。因此，最好的做法是，在一段時間內先不要再頻繁調用 B 服務。
為了實現這個保護效果，我們可以在 A 和 B 之間加一個熔斷器。當 B 服務頻繁失敗時，熔斷器可以防止 A 繼續頻繁調用 B 服務，相當于阻斷服務間的請求，并且還能在 B 服務恢復正常之后，恢復 A 對 B 的調用。
熔斷器的作用
工作原理也和上文提到的宿舍電路里的斷路器類似。當服務調用失敗的次數超過某個閾值時，熔斷器會自動“打開”（Open），阻止進一步的服務調用，防止不斷報錯重試導致壓垮被調用服務。
然后在在一段時間之后，熔斷器開始嘗試允許少量的請求通過，以檢查服務是否已經恢復，也就是所謂的“半打開”（HalfOpen）。
如果這些請求成功，熔斷器會“關閉”(Close)，系統恢復正常的服務調用；但如果調用還是失敗，那熔斷器會繼續再次回到“打開”（Open）狀態。
上面提到的三個狀態Open，HalfOpen和Close是服務熔斷中非常重要的三個狀態。
熔斷器關閉
熔斷器半打開
熔斷器打開
它們的狀態流轉關系就像下圖這樣。
熔斷狀態機
可以看出，熔斷器的邏輯其實很簡單，而且這么通用的功能，必然有現成的庫可以直接拿來用。
比如阿里開源的sentinel-golang。
使用也比較簡單。只需要三步。
"github.com/alibaba/sentinel-golang/core/circuitbreaker"通過circuitbreaker.LoadRules加載對應的熔斷規則。
_, err = circuitbreaker.LoadRules([]*circuitbreaker.Rule{ // Statistic time span=5s, recoveryTimeout=3s, maxErrorRatio=40% { Resource: "api_url", Strategy: circuitbreaker.ErrorRatio, RetryTimeoutMs: 3000, MinRequestAmount: 10, StatIntervalMs: 5000, StatSlidingWindowBucketCount: 10, Threshold: 0.4, }, })這里面有幾個需要注意的地方：
在需要進行熔斷保護的地方，加入下面的代碼：
e, b := sentinel.Entry("api_url") if b == nil { // 通過檢測，不需要熔斷，直接執行api調用 err := api_call() if err != nil { sentinel.TraceError(e, err) } // 保證執行完之后退出資源 e.Exit() }上面的 sentinel.Entry()方法內部會自動檢測"api_url"這個資源是否需要打開熔斷器，如果 api 調用報錯了，可以通過 sentinel.TraceError 記錄下來，sentinel 內部會根據報錯去計算報錯率，自動判斷要不要熔斷。
到這里，就算使用上熔斷器的能力啦。
本文鏈接：http://www.www897cc.com/showinfo-26-77684-0.html服務熔斷是指什么？你知道嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： GaussDB WDR分析之集群報告篇
下一篇： 歷史上那些臭名昭著的編程錯誤
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號