《百萬級併發商品服務架構解密》讀後總結

開篇

最近看了一個技術分享的視頻《百萬級併發商品服務架構解密》, 演講者來自 網易考拉的丁鳴亮, 感受講的還不錯, 根據內容簡單整理以下.

業務概念劃分

1. 商品詳情模塊

• app 商品詳情
• pc 商品詳情
• wap 商品詳情

針對不一樣平臺數據需求定製不一樣的接口詳情, 減小各大端的彼此互相依賴、影響

2. 商品通用模塊

• sku
• 品牌
• 分類
• 當前售價
• 庫存

3. 商品附屬模塊

• 活動標籤
• 利益標籤

數據概念劃分

1. 商品基本數據

• property
• sku
• goods

商品基本數據能夠經過商品服務異構到應用服務, 即便商品服務宕機也不影響基礎的商品訪問, 異構方式可使用 MQ、binlog 等形式進行.

2. 商品拓展數據

• 品牌
• 分類
• 所在倉庫

3. 商品動態數據

• 當前價格
• 庫存
• 滿減|折扣

商品動態數據可經過實時查詢 商品服務 返回最新的數據.

4. 商品附屬數據

• 標籤

商品附屬數據非核心功能, 關鍵時刻可選擇降級數據.

以上咱們經過數據的劃分實現了 動靜分離、核心數據與非核心數據區分, 固然商品基礎數據異構到應用層作緩存的方式是否合理, 好處是響應的提高、容災、減小網絡的消耗, 但換來的是增長了數據的冗餘, 犧牲了服務的邊界劃分. (固然也能夠有選擇性的對熱點商品進行異構緩存).

三級緩存的預案

商品詳情三級緩存:

1. L1緩存: 主動刷新熱點商品 (local cache) 失效 5 min
2. L2緩存: 被動刷新被訪問的商品 (local cache) 失效 1min
3. L3緩存: 全量的商品 失效7天

借用 cpu 的三級緩存概念, L1對於商品預見性預熱到 local cache, L2 對於真實用戶熱點數據刷到本地. L3 通常爲 redis、memcache 緩存使用.

服務穩定性提高:

服務灰度上線

Consumer端:

• 服務調用的二次封裝

捕獲被調用方異常, 平滑處理錯誤, 防止異常蔓延

• 服務調用的超時時間

設置合理超時時間, 服務降級, 防止服務崩潰異常蔓延

• 服務關停演練

代碼層作非核心服務兼容, 對開關進行測試, 禁止真正發生問題後開關失效.

Provider端:

• 接口設置流控(限流,防止某服務調用異常影響其它Consumer)
• 按客戶端設置流控
• 動靜分離

沒有流控感受就像在裸奔, 由於沒有 流控、降級 致使服務徹底不能用, 最後排查原來是由於某條 sql 沒用到索引, 若是有根據負載狀況流控, 也不會出現這麼大的損失。

減小核心業務的入侵 進行解耦

分清主次

解決循環依賴

舉例: 我服務慢由於的調用了你的服務, 你的服務慢由於調用他的服務， 他的服務慢由於其中有個數據調用了個人服務

結語

明確服務邊界, 保持乾淨.