# 新浪微博高可用架構體系 - 李慶豐

{%hackmd yEJ_rTxzTWa2K450RqmT8w %}

### 前言
2009年 微博成立
技術隨著微博成長

目標：

- 了解億級用戶規模的大型服務典型場景和面臨的挑戰
- 了解社群常用 CAP 解決方案
- 理解大型互聯網服務高可用架構的常用解決方案

### 新浪微博的業務場景和技術挑戰

- 140字的上限
1. 訂閱模式
2. 推送(根據用戶)
3. 熱搜
4.

09年 服務模塊少（發佈，信息流）
now 服務 > 100

16年 月活躍用戶 2.82億 一 4.86 億
日活躍用戶 2.1億
年對年增長 5500 萬
財務營收 29.59 億

無論多小的服務出問題影響層面都是百萬級

用戶規模大，需要海量資訊存儲能力
日常高頻應用，要有容災能力

用戶請求量巨大，性能要求高
難預測流量峰值，突發事件無法預估

突發事件：
- 娛樂事件 志玲姊姊結婚
- 政治事件

微博場景下，高可用架構體系面臨的挑戰
1. 數據存不下了，請求扛不住了 容量問題
2. 服務響應太慢，資源成本太高了 性能問題
3. 服務之間依賴問題 依賴問題
4. 專線、機房故障導致不可用 容災考慮

### 微博高可用架構體系構建
- 容量問題
- 存儲容量 - 監控 海量數據存儲架構
- 請求容量 - 監控 高並發架構
- 性能問題
- 監控，分佈式緩存架構
- 服務依賴問題
- 監控、微服務架構、SLA 體系、服務治理、容器化
- 容災問題
- 監控、多機房架構

海量數據存儲架構
分布式緩存架構
微服務 容器化
多機房架構

**容量規則和成本平衡的技術挑戰 **

1. 讀寫比例的嚴重失調
- 讀寫分離 在不同的服務器分擔
2. 單機容量瓶頸
- 水平拆分
- 垂直拆分(按時間軸拆分)
3. 業務快速增長帶來的容量問題

考慮三個月內，三個月後，一年內的可用性

- 容量規劃
- 儲存容量
- 請求容量
- 切忌拍腦袋

- 成本考慮
- mem or disk
- 成本與擴展能力
- 冗余度

MySQL 內建提供讀寫分離，將資料庫分為供讀取使用與供寫入使用，通常讀取的多

舊資料，較沒人看的遷移到較差的機器，新資料比較熱門的放在比較強的機器
快取緩存也是一樣做區分，並有 master/slave 主備機制，避免掛掉一瞬間大量資料湧入 DB，拖垮 DB

緩存越多，一旦垮掉 DB 死掉的機會越大

故障處理：用備用處理?

解決擴展問題
- 請求量瓶頸
- 拆分
- 帶寬瓶頸
- N 是越大越好嗎？
- 會增加請求次數 影響性能
- 線性擴展架構

各服務分別用 tomcat 容器拆分，但會衍伸各服務溝通調用效率的性能問題
服務間調用問題用 RPC 來解較直接，會比 http 來的快

Docker 解決性能、部署問題

混合雲：一般流量用內部機房，突發狀況流量用公有雲支援

多機房：所有機房都提供完整服務，但會衍生資料同步問題
- CAP（一致性，可用性，錯誤容忍度）

服務最前端都有即時監控體系

### 新業務場景下的挑戰

#### Weibo Mesh 網路

###### tags: `MW19`