golang熔斷,golang 中斷

本文目錄一覽：

• 1、b站用的什麼典型資料庫
• 2、降級與熔斷
• 3、go-zero高可用-自適應熔斷器
• 4、電腦開機顯示器黑屏，出現POWER SAVING MODE

b站用的什麼典型資料庫

Mysql。

B站後台應該也是golang和java混搭的，目前B站不是在逐漸去除java嘛，還有就是B站後台穩不穩定跟用什麼搭建沒有呀直接關係，與一個系統的架構設計，熔斷降級等配置有關係，是否有完善的監控系統，有強大的運維團隊，有高質量的代碼等因素有關係。從之前B站泄露出來的代碼看，目前B站後台的核心技術棧是Go語言。至於為什麼用Go語言後面會說到，事實上B站流量在行業內並不是頂尖，就算是用Go語言作為核心技術棧的網站中，B站也不是技術難度最高的。不過同樣值得關注的是，B站對於UP主的保護是全行業最佳，剛剛B站也簽下了馮提莫，不斷大動作的B站未來發展可期。隨著行業的不斷發展，各種新興語言不斷出現，一個項目中多種語言並存、互補的現象是必然的，也許幾十年後你還會發現用Go寫的後台被其他語言改寫了，或者某種你以為已經成為歷史的語言捲土重來也不是沒有可能。

降級與熔斷

降級與熔斷

1.1、降級

降級也就是服務降級，當我們的伺服器壓力劇增，為了保證核心功能的可用性，可以選擇性的降低一些功能的可用性，或者直接關閉該功能。典型的棄車保帥！ 就比如貼吧類型的網站，當伺服器吃不消的時候，可以選擇把發帖功能關閉，註冊功能關閉，改密碼，改頭像這些都關了，為了確保登錄和瀏覽帖子這種核心的功能。

1.2、熔斷

降級一般而言是我們自身的系統出現了故障而降級。而熔斷一般是指依賴的外部介面出現故障，斷絕和外部介面之間的關聯。

例如你的A服務裡面的一個功能依賴B服務，這時候B服務出問題了，返回的很慢。這種情況可能會因為這麼一個功能而拖慢了A服務裡面的所有功能，因此我們這時候就需要熔斷！即當發現A要調用這B時就直接返回錯誤(或者返回其他默認值啊啥的)，就不去請求B了。

1.3、熔斷狀態機

三種狀態：

Close 關閉狀態，熔斷器的初始化狀態，允許請求通過

Open 開放狀態，即熔斷狀態，不允許請求通過

HalfOpen 半開放狀態，允許部分請求通過

1.4、hystrix包詳解

hystrix是Netflix的開源庫，go版本是hystrix-go。

主要以下幾個模塊：setting，hystrix，circuit，metrics，pool和eventstream。

1.4.1、settings

setting 用來管理熔斷器的配置，包括存儲，新增和讀取。

map+讀寫鎖實現多個circuit的配置。

Timeout: 執行command的超時時間。默認時間是1000毫秒

MaxConcurrentRequests：command的最大並發量 默認值是10

SleepWindow：當熔斷器被打開後，SleepWindow的時間就是控制過多久後去嘗試服務是否可用了。默認值是5000毫秒

RequestVolumeThreshold： 一個統計窗口10秒內請求數量。達到這個請求數量後才去判斷是否要開啟熔斷。默認值是20

ErrorPercentThreshold：錯誤百分比，請求數量大於等於RequestVolumeThreshold並且錯誤率到達這個百分比後就會啟動熔斷 默認值是50

1.4.2、circuit 

circuit 用來管理熔斷器的狀態變更。

除此之外，circuit還上報事件給統計器

創建circuit的時候，會根據配置創建相應的metric和exePool

1.4.3、metrics

 metrics用來統計和計算請求的響應情況。

每一個Command都會有一個默認統計控制器，當然也可以添加多個自定義的控制器。 默認的統計控制器DefaultMetricCollector保存著熔斷器的所有狀態，調用次數，失敗次數，被拒絕次數等等。

在執行newMetricExchange的時候會啟動一個協程 go m.Monitor()去監控Updates的數據，然後上報給metricCollectors 保存執行的信息數據比如前面提到的調用次數，失敗次數，被拒絕次數等等。

1.4.3、pool

pool 用來管理請求池，控制請求池最大數目以及請求ticket的發放和回收。

1.4.4、hystrix 

hystrix 是熔斷器的主要部分，對外提供同步和非同步的方法，對內上報請求事件以及fallback降級處理。

func GoC(ctx context.Context, name string, run runFuncC, fallback fallbackFuncC) chan error

參考：

go-zero高可用-自適應熔斷器

微服務集群中，每個應用基本都會依賴一定數量的外部服務。有可能隨時都會遇到網路連接緩慢，超時，依賴服務過載，服務不可用的情況,在高並發場景下如果此時調用方不做任何處理，繼續持續請求故障服務的話很容易引起整個微服務集群雪崩。

比如高並發場景的用戶訂單服務，一般需要依賴一下服務：

假如此時 賬戶服務 過載，訂單服務持續請求賬戶服務只能被動的等待賬戶服務報錯或者請求超時，進而導致訂單請求被大量堆積，這些無效請求依然會佔用系統資源：cpu，內存，數據連接…導致訂單服務整體不可用。即使賬戶服務恢復了訂單服務也無法自我恢復。

這時如果有一個主動保護機制應對這種場景的話訂單服務至少可以保證自身的運行狀態,等待賬戶服務恢復時訂單服務也同步自我恢復，這種自我保護機制在服務治理中叫熔斷機制。

熔斷是調用方自我保護的機制（客觀上也能保護被調用方），熔斷對象是外部服務。

降級是被調用方（服務提供者）的防止因自身資源不足導致過載的自我保護機制，降級對象是自身。

熔斷這一詞來源時我們日常生活電路裡面的熔斷器，當負載過高時（電流過大）保險絲會自行熔斷防止電路被燒壞，很多技術都是來自生活場景的提煉。

熔斷器一般具有三個狀態：

使用較多的熔斷組件：

基於上面提到的熔斷器原理，項目中我們要使用好熔斷器通常需要準備以下參數：

實際上可選的配置參數還有非常非常多，參考

對於經驗不夠豐富的開發人員而言，這些參數設置多少合適心裡其實並沒有底。

那麼有沒有一種自適應的熔斷演算法能讓我們不關注參數，只要簡單配置就能滿足大部分場景？

其實是有的， google sre 提供了一種自適應熔斷演算法來計算丟棄請求的概率：

演算法參數：

演算法解釋：

接下來思考一個熔斷器如何實現。

初步思路是：

下面來逐步分析 go-zero 的源碼實現：

core/breaker/breaker.go

兵馬未動，糧草先行，明確了需求後就可以開始規劃定義介面了，介面是我們編碼思維抽象的第一步也是最重要的一步。

核心定義包含兩種類型的方法：

Allow()：需要手動回調請求結果至熔斷器，相當於手動擋。

DoXXX()：自動回調請求結果至熔斷器，相當於自動擋，實際上 DoXXX() 類型方法最後都是調用

DoWithFallbackAcceptable(req func() error, fallback func(err error) error, acceptable Acceptable) error

circuitBreaker 繼承 throttle，實際上這裡相當於靜態代理，代理模式可以在不改變原有對象的基礎上增強功能，後面我們會看到 go-zero 這樣做的原因是為了收集熔斷器錯誤數據，也就是為了實現可觀測性。

熔斷器實現採用靜態代理模式，看起來稍微有點繞腦。

throttle 介面實現類：

loggedThrottle 增加了為了收集錯誤日誌的滾動窗口，目的是為了收集當請求失敗時的錯誤日誌。

errorWindow 是一個環形數組，新數據不斷滾動覆蓋最舊的數據，通過取余實現。

看到這裡我們還沒看到實際的熔斷器實現，實際上真正的熔斷操作被代理給了 internalThrottle 對象。

可以看到熔斷器屬性其實非常簡單，數據統計採用的是滑動時間窗口來實現。

滑動窗口屬於比較通用的數據結構，常用於最近一段時間內的行為數據統計。

它的實現非常有意思，尤其是如何模擬窗口滑動過程。

先來看滑動窗口的結構體定義：

window 是數據的實際存儲位置，其實就是一個數組，提供向指定 offset 添加數據與清除操作。

數組裡面按照 internal 時間間隔分隔成多個 bucket。

window 添加數據：

window 統計數據：

熔斷器對外暴露兩種類型的方法

func (b *googleBreaker) allow() (internalPromise, error)

func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error

Acceptable 參數目的是自定義判斷請求是否成功。

微軟 azure 關於熔斷器設計模式

索尼參考微軟的文檔開源的熔斷器實現

go-zero 自適應熔斷器文檔

電腦開機顯示器黑屏，出現POWER SAVING MODE

顯示器顯示：Enter power saving mode 的意思是顯示器進入省電模式。

如果接好了線，但顯示器沒有反映，表示顯示器沒有接收到主機顯卡的顯示信號。

1，檢查顯示器和顯卡的連接（特別是有獨顯和集顯的，不要接到集顯上）是否正確，接觸是否良好。

2，檢查顯卡和主板是否接觸良好，顯卡是否正常工作，清潔顯卡的金手指，重新插拔試試。

3，檢查主機是因內存接觸不良等問題沒有正常開機（硬碟燈沒有跳動，沒有進入系統的聲音[有音箱的話]）。

4，將主機接別的顯示器試下，如果也不亮證明是主機問題，用替換法檢查顯卡，內存，主板找出損壞的硬體。

5，如果接別的顯示器能顯示，換回原來的顯示器還是一樣，顯示器損壞，需要維修。