在公共包go-common中封裝乙個方法，在etcd中設定限流/熔斷開啟/關閉的開關，將父類context傳遞進去，讀取環境變數，開關開啟則進行限流和熔斷（限流/熔斷閾值寫死，從環境變數中讀取）
優點：目標明確，工作量、技術實現可預知
缺點：需要人為開啟/關閉限流、熔斷開關，限流/熔斷閾值固定，必須達到該閾值才會出發，不夠靈活
當olap對同乙個（模型/報表）請求多次返回查詢超時或者報錯時，這種返回異常超過設定的閾值，自動開啟熔斷，即在短時間內再次請求（該模型/報表）時，啟明星不再向olap查詢，而是直接報提示資訊：olap查詢資源緊張/異常，等一定時間後（etcd配置）再查詢的提示資訊。
優點：視實時請求量、olap返回情況進行自動限流/熔斷，不需要人為介入，比較靈活；
缺點：需要事先對各個介面打點，工作量大，情景複雜，實現難度高。
在微服務架構中，由於系統和服務的細分，導致系統結構變得非常複雜， 為了跨平台，為了統一集中管理api，同時為了不暴露後置服務。甚至有時候需要對請求進行一些安全、負載均衡、限流、熔斷、灰度等中間操作，基於此類種種的客觀需求乙個類似綜合前置的系統就產生了，這就是api閘道器（api gateway）。api閘道器作為分散在各個業務系統微服務的api聚合點和統一接入點，外部請求通過訪問這個接入點，即可訪問內部所有的rest api服務。目前常用的微服務閘道器有kong、zuul、gateway。
優點：可以利用現有框架進行功能擴充套件
缺點：需要接入grpc服務，前期工作量大
（1）grpc服務接入
golang專案通過sidecar部署grpc-proxy和grpcserver（詳見：grpc-proxy(bridge)），實現grpc服務接入網關。
（2）grpc-proxy服務包括bridge服務以及proxy服務，其中bridge包括了服務註冊以及http請求橋接為grpc請求，proxy包括了服務發現功能。
（3）golang可使用grpcx建立以及啟動服務，使用原生的grpc服務，需實現diagnose服務
第一階段（年前）：可以先實現方案1.1
第二階段（年後）：等打點、快取都加過之後，可以優化到方案1.2
第二階段（年後）：go專案接入kong閘道器後，可以逐步優化到方案1.3
限流器，從字面上理解就是用來限制流量，有時候流量突增(可預期的比如「雙11」，不可預期的微博的熱門話題等)，會將後端服務壓垮，甚至直接宕機，使用限流器能限制訪問後端的流量，起到乙個保護作用，被限制的流量，可以根據具體的業務邏輯去處理，直接返回錯誤或者返回預設值等等。
乙個存放固定容量令牌的桶，按照固定速率往桶中新增令牌，請求是否被處理需要看桶中令牌是否足夠，當令牌數為0時，則拒絕新的請求。
令牌桶演算法限制的是平均流入速率，並允許一定程度的突發流量。
乙個固定容量的漏桶，按照固定速率流出請求，流入請求速率任意，當流入的請求數累積到漏桶容量時，則新的請求被拒絕。
漏桶演算法限制的是平均流入速率，主要目的是平滑突發流入速率。
基於令牌桶演算法和漏桶演算法來實現的限速限流，golang實現：
分布式限流最關鍵的是將限流服務做成原子化，如可以使用redis + lua或ngnix + lua的方式實現這兩種技術可以實現高併發和高效能。
接入層通常指請求流量的入口，主要的目的有：負載均衡、非法請求過濾、請求聚合、快取、降級、限流、a/b測試、服務質量監控等。
有時想要在特定的時間視窗內對重複的相同事件最多隻處理一次，或者想要限制多個連續的相同事件最小執行時間間隔，那麼可以使用節流（throttle）是心啊，其防止多個相同事件連續重複執行。
在開發高併發系統時，可以通過使用快取、限流、降級等方式保護系統，維護服務的穩定性和可用性。
當訪問量劇增、服務異常（如響應時間過長或者不響應）、非核心服務影響到核心系統的效能時，仍然需要保證關鍵服務是可用的，這是就需要使用服務降級方案。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。
服務降級的目的是保證核心服務可用，即使是有損的。
1.按照是否自動化分為：自動降級、人工開關降級
2.按照功能分類：介面降級、服務降級
和限流器對依賴服務的保護機制不一樣，熔斷器是當依賴的服務已經出現故障時，為了保證自身服務的正常執行不再訪問依賴的服務，防止雪崩效應。
熔斷器有三種狀態：
（1）首先建立乙個熔斷器：
使用hystrix-go建立熔斷器：
// 熔斷器
hystrix.configurecommand(
"addservice", // 熔斷器名字，可以用服務名稱命名，乙個名字對應乙個熔斷器，對應乙份熔斷策略
hystrix.commandconfig,
)
熔斷的阻塞方式:
err := hystrix.do("addservice", func() error , func(err error) error
return nil
})
熔斷的非阻塞方式：
err1 := hystrix.go("addservice", func() error {}
}return err
}, nil)
// 有 fallback 處理
err2 := hystrix.go("addservice", func() error {}
}return err
}, func(err error) error
success <- struct{}{}
return nil})
for i := 0; i < 2; i++
}
當程式進行遠端呼叫時，通常使用熔斷器（機制）/斷路器circuit breaker。遠端呼叫通常會在超時之前掛起一段時間。如果應用程式發出大量這些請求，許多資源可能會被擁堵在一起，等待這些超時發生。熔斷器通過包裝這些遠端呼叫，並在發生定義數量的故障或超時後跳閘。當熔斷器被絆倒時，任何之後的呼叫都將避免進行遠端呼叫並將錯誤返回給呼叫者。同時，熔斷器將定期允許再次嘗試某些呼叫請求，如果這些呼叫成功，將關閉訪問鏈路。
微服務元件之限流器與熔斷器：
golang實現請求限流的幾種辦法：
測試**:
circuit breaker pattern:
hystrix-go:
限流:漏桶演算法和令牌桶演算法：
維基百科:token_bucket：
維基百科:leaky_bucket：
介面限流實踐：
流量調整和限流技術：
微服務最強開源流量閘道器kong：
mysql限流熔斷 熔斷，限流，降級
1 寫在前面 1.1 名詞解釋 consumer表示服務呼叫方 provider標示服務提供方，dubbo裡面一般就這麼講。下面的a呼叫b服務，一般是泛指呼叫b服務裡面的乙個介面。1.2 拓撲圖 大寫字母表示不同的服務，後面的序號表示同乙個服務部署在不同機器的例項。2 從微觀角度思考 2.1 超時 ...
dubbo熔斷限流
常見的限流演算法有 令牌桶 漏桶。計數器也可以進行粗暴限流實現。dubbo呼叫模型 連線呼叫圖 呼叫時關鍵引數影響 引數名 作用範圍 預設值說明 備註actives consumer 0每服務消費者每服務每方法最大併發呼叫數 0表示不限制 connections consumer 對每個提供者的最大...
dubbo 熔斷，限流，降級
1 寫在前面 1.1 名詞解釋 consumer表示服務呼叫方 provider標示服務提供方，dubbo裡面一般就這麼講。下面的a呼叫b服務，一般是泛指呼叫b服務裡面的乙個介面。1.2 拓撲圖 大寫字母表示不同的服務，後面的序號表示同乙個服務部署在不同機器的例項。2 從微觀角度思考 2.1 超時 ...