最近看了一個技術分享的視頻《百萬級併發商品服務架構解密》, 演講者來自 網易考拉的丁鳴亮, 感受講的還不錯, 根據內容簡單整理以下.redis
針對不一樣平臺數據需求定製不一樣的接口詳情, 減小各大端的彼此互相依賴、影響sql
商品基本數據能夠經過商品服務異構到應用服務, 即便商品服務宕機也不影響基礎的商品訪問, 異構方式可使用 MQ、binlog 等形式進行.緩存
商品動態數據可經過實時查詢 商品服務 返回最新的數據.markdown
商品附屬數據非核心功能, 關鍵時刻可選擇降級數據.網絡
以上咱們經過數據的劃分實現了 動靜分離、核心數據與非核心數據區分, 固然商品基礎數據異構到應用層作緩存的方式是否合理, 好處是響應的提高、容災、減小網絡的消耗, 但換來的是增長了數據的冗餘, 犧牲了服務的邊界劃分. (固然也能夠有選擇性的對熱點商品進行異構緩存).架構
商品詳情三級緩存:併發
借用 cpu 的三級緩存概念, L1對於商品預見性預熱到 local cache, L2 對於真實用戶熱點數據刷到本地. L3 通常爲 redis、memcache 緩存使用.app
服務灰度上線ide
Consumer端:測試
捕獲被調用方異常, 平滑處理錯誤, 防止異常蔓延
設置合理超時時間, 服務降級, 防止服務崩潰異常蔓延
代碼層作非核心服務兼容, 對開關進行測試, 禁止真正發生問題後開關失效.
Provider端:
沒有流控感受就像在裸奔, 由於沒有 流控、降級 致使服務徹底不能用, 最後排查原來是由於某條 sql 沒用到索引, 若是有根據負載狀況流控, 也不會出現這麼大的損失。
減小核心業務的入侵 進行解耦
分清主次
解決循環依賴
舉例: 我服務慢由於的調用了你的服務, 你的服務慢由於調用他的服務, 他的服務慢由於其中有個數據調用了個人服務
明確服務邊界, 保持乾淨.