Go 進階訓練營（二）（完整版）

Go 進階訓練營（二）

Go 架構實踐 - 微服務(微服務可用性設計)

點點我download：Go 進階訓練營 提取馬：d17c

目錄

隔離 超時控制 過載保護 限流 降級 重試 負載均衡 最佳實踐 References

隔離

隔離，本質上是對系統或資源進行分割，從而實現當系統發生故障時能限定傳播範圍和影響範圍，即發生故障後只有出問題的服務不可用，保證其餘服務仍然可用。 服務隔離：動靜分離、讀寫分離 輕重隔離：核心、快慢、熱點 物理隔離：線程、進程、集羣、機房

隔離 - 服務隔離

動靜隔離: 小到 CPU 的 cacheline false sharing、數據庫 mysql 表設計中避免 bufferpool 頻繁過時，隔離動靜表，大到架構設計V（cmL46679910）中的圖片、靜態資源等緩存加速。本質上都體現的同樣的思路，即加速/緩存訪問變換頻次小的。好比 CDN 場景中，將靜態資源和動態 API 分離，也是體現了隔離的思路: 1）下降應用服務器負載，靜態文件訪問負載所有經過CDN。 2）對象存儲存儲費用最低。 3）海量存儲空間，無需考慮存儲架構升級。 4）靜態CDN帶寬加速，延遲低。

archive: 稿件表，存儲稿件的名稱、做者、分類、tag、狀態等信息，表示稿件的基本信息。 在一個投稿流程中，一旦稿件建立改動的頻率比較低。 archive_stat: 稿件統計表，表示稿件的播放、點贊、收藏、投幣數量，比較高頻的更新。 隨着稿件獲取流量，稿件被用戶V（cmL46679910）所消費，各種計數信息更新比較頻繁。 MySQL BufferPool 是用於緩存 DataPage 的，DataPage 能夠理解爲緩存了表的行，那麼若是頻繁更新 DataPage 不斷會置換，會致使命中率降低的問題，因此咱們在表設計中，仍然能夠沿用相似的思路，其主表基本更新，在上游 Cache 未命中，透穿到 MySQL，仍然有 BufferPool 的緩存。

讀寫分離：主從、Replicaset、CQRS。

隔離 - 輕重隔離

一、核心隔離 業務按照 Level 進行資源池劃分(L0/L1/L2)。 1)核心/非核心的故障域的差別隔離(機器資源、依賴資源)。 2)多集羣，經過冗餘資源來提高吞吐和容災能力。

二、快慢隔離 咱們能夠把服務的吞吐想象爲一個池，當忽然洪流進來時，池子須要必定時間才能排放完，這時候其餘支流在池子裏待的時間取決於前面的排放能力，耗時就會增高，對小請求產生影響。 日誌傳輸體系的架構設計中，整個流都會投放到一個 kafka topic 中(早期設計目的: 更好的順序IO)，流內會區分不一樣的 logidV（cmL46679910），logid 會有不一樣的 sink 端，它們以前會出現差速，好比 HDFS 抖動吞吐降低，ES 正常水位，全局數據就會總體反壓。

按照各類緯度隔離：sink、部門、業務、logid、重要性(S/A/B/C)。 業務日誌也屬於某個 logid，日誌等級就能夠做爲隔離通道。 三、熱點隔離 何爲熱點？熱點即常常訪問的數據。不少時候咱們但願統計某個熱點數據中訪問頻次最高的 Top K 數據，並對其訪問進行緩存。好比： 小表廣播: 從 remotecache 提高爲 localcache，app 定時更新，甚至可讓運營平臺支持廣播刷新 localcache。atomic.Value

主動預熱: 好比直播房間頁高在線狀況下bypass 監控主動防護。

隔離 - 物理隔離

線程隔離 主要經過線程池進行隔離，也是實現服務隔離的基礎。把業務進行分類並交給不一樣的線程池進行處理，當某個線程池處理一種業務請求發生問題時，V（cmL46679910）不會講故障擴散和影響到其餘線程池，保證服務可用。 對於 Go 來講，全部 IO 都是 Nonblocking，且託管給了 Runtime，只會阻塞Goroutine，不阻塞 M，咱們只須要考慮 Goroutine 總量的控制，不須要線程模型語言的線程隔離。