大流量時代，如何規劃系統流量提升可靠性

摘要：本文主要是對《鳳凰架構》的解讀，講述規劃系統流量的幾種方式。本文分享自華為雲社區《大流量時代，如何規劃系統流量提升可靠性》，作者：breakDawn 。透明多級分流系統對系統流量進行規劃，要註意以下2個原則儘可能減少單點部件，或者減少到達單點部件的流量或者作用奧卡姆剃刀原則，確定 ...

摘要：本文主要是對《鳳凰架構》的解讀，講述規劃系統流量的幾種方式。

本文分享自華為雲社區《大流量時代，如何規劃系統流量提升可靠性》，作者：breakDawn 。

透明多級分流系統

對系統流量進行規劃，要註意以下2個原則

儘可能減少單點部件，或者減少到達單點部件的流量或者作用
奧卡姆剃刀原則，確定有再有必要的時候才去使用，避免過度設計

1 客戶端緩存

即對於某些資源，在客戶端就做緩存，客戶端不去重覆請求。

1.1 強制緩存

類似HTTP協議里在header里用到的兩種標簽，且都是服務端強行控制的，基於時間的

Expires
服務端直接返回數據不會變動的截止時間。
缺點：受限於客戶端本地時間、無法表示不緩存除非強制改時間戳、無法表示是否是私有資源（避免私有資源被其他節點緩存）
Cache-Control
這個請求頭使用max-age、private、no-cache等標簽解決了Expires里的3個缺點。

1.2 協商緩存

協商緩存需要考慮是否真的發生變化。協商和強制可以共同存在，即強制失效的時候就可以用上協商。
協商緩存不僅存在於地址輸入、跳轉，也存在F5中（但如果Ctrl+F5強制刷新則會讓緩存失效）

Last-Modified
告訴客戶端資源的最後修改時間，客戶端再次請求時也會對這個時間做修改
如果服務端發現在那個時間之後資源未變動，返回304 Not Modified
如果有變動，就返回OK，並攜帶完整的資源
ETag
需要對資源計算哈希值，客戶端發請求也會帶上自己存的ETag，每次會比對資源的哈希值是否一致，不一致則返回新資源。
Etag是一致性最強的本地緩存機制，但也是性能最差的。

2 傳輸通道優化

本章節大部分以熟知的HTTP協議作為主要傳輸通道協議，講解如何進行優化

2.1 連接數優化

HTTP是基於TCP的，每次都是重新建立一個TCP連接。因此前端開發人員開發了很多小優化，來減少請求次數，例如雪碧圖、分段文檔、合併Ajax請求之類的。

HTTP1.0里的長連接(keep-alive連接復用）為什麼不能解決這個問題？
因為存在隊首阻塞問題，本質上是基於FIFO復用連接， 1個請求卡住了，後面9個請求都阻塞住了，但如果同時支持返回，在順序混亂的情況下無法正常處理

HTTP2.0的多路復用解決了這個問題：

以幀作為最小粒度單位，每個幀都攜帶流ID識別是哪個流
客戶端可以很容易在不同流中重組HTTP請求和響應報文

2.2 傳輸壓縮

HTTP很早就支持GZip壓縮來減少大資源的傳輸量

HTTP1.0中，持久連接和傳輸壓縮無法一起使用，因為壓縮後無法識別資源是否傳輸完畢。

HTTP1.1中引入了“分塊傳輸編碼”，來進行資源結束的判斷。

2.3 用UDP來加快網路傳輸

HTTP/3中，希望能替換掉HTTP on TCP的依賴、
谷歌推出了快速UDP網路連接，即QUIC

QUIC以UDP為基礎，可靠傳輸能力由自己實現
QUIC專門面向移動設備支持，移動設備的ip地址經常會切換，使用ip作為定位不合適，因此提出了連接標識符來保持連接。
對於不支持QUIC的情況，支持回退為TCP連接，實現相容

3 內容分髮網絡CDN

CND可以解決互聯網系統跨運營商、跨地域物理距離所導致的時延問題，為網站流量帶寬起到分流、減負的作用。
主要包含以下4個工作部分

3.1 路由解析

用戶的靜態資源請求訪問CDN是通過DNS解析來完成的，甚至可能一個網站會有各種不同地域的CDN功能變數名稱解析地址返回，通過你的路由配置會自動選擇符合地域的ip地址

3.2 內容分發

如何分發內容有兩種方式：

主動分發，通過CND服務商提供的介面主動推送自己的資源，這樣你需要額外編寫資源推動的代碼。大型活動例如雙11會優先考慮主動分發預先準備資源。
被動回源，由用戶訪問觸發，當發現沒有資源時,CDN會去源站請求並返回，則用你不需要新寫相關代碼，只要在CDN那邊支持回源你的源站即可。小型站點基本都是用這個方法。

如何更新資源有兩種方式：

超時被動失效，CDN的資源都有有效期，超時了就回源獲取
手工主動失效， CDN服務商提供緩存失效介面，主動觸發失效併進行被動回源更新。
現在一般是1和2結合使用，二者不衝突

4 負載均衡

負載均衡有兩種大類

四層負載均衡
指的是電腦七層模型中四層及以下的均衡策略結合
即數據鏈路層 + 網路層均可做均衡
七層負載均衡
指的是在應用層通過實際代碼做均衡

4.1 數據鏈路層負載均衡（四層負載均衡）

通過鏈路層上的均衡器替換MAC地址，進行鏈路層的均衡
各負載節點的IP是一樣的（相同的虛擬IP）
返回時無需經過均衡器，直接返回即可（因為目標ip、源ip基本沒變）

缺點：
必須是同一個子網內，無法跨VLAN，只能作為最接近數據中心的均衡器

4.2 網路層負載均衡（四層負載均衡）

有兩種方式：

IP隧道模式

均衡器在IP報文外麵包了一層新的header，header里指定了目標機器的實際ip或者小網ip。接收機器要支持解header，且同樣要求作為返回的虛擬ip是一致的，也是直接返回無需經過均衡器。
缺點：

用到的伺服器都要支持隧道解包能力（linux系統現在都支持）
虛擬ip仍然有較大限制，需要人工介入管理眾多機器

NAT模式

NAT模式中，就是進行真正的ip轉換，且返回時也要返回給NAT進行ip轉換，這樣只需要針對NAT進行人工管理即可。
缺點在於NAT容易成功性能瓶頸

SNAT會修改源IP改為NAT的ip，可以做到對業務真正透明，但是代價是如果需要對源IP做限制時容易有問題，因為所有的來源ip都是一樣的了。

4.3 應用層負載均衡（七層負載均衡）

也叫做七層代理（應用層代理），因為這個負載均衡屬於反向代理（即部署在服務端的代理，對客戶端不感知）

不適合做下載站、視頻站等流量應用
如果瓶頸在服務計算能力，則可以考慮做應用層均衡
期

七層代理除負載均衡外的其他功能：

支持做CDN類似的緩存能力
施行智能化路由，根據URL或者特定用戶做特殊服務
抵禦安全工具，提前過濾攻擊報文
鏈路治理

4.4 負載均衡策略

輪詢均衡
輪流分配，從1到N再到1
適用於所有伺服器硬體配置完全相同，服務請求需要相對均衡
權重輪詢
根據伺服器權重分配周期內的輪詢次數
隨機均衡
適用於數據量足夠大的相對均衡分佈
權重隨機均衡
提升權重高的隨機率
一致性哈希均衡
適用於伺服器經常可能掉線或者加入，可以避免哈希鍵全部更新的情況
響應速度均衡
定期探測各個伺服器的響應速度，根據速度分配權重
最少連接數均衡
根據連接數分配權重，適用於長時處理服務例如FTP等
軟體均衡器包括基於操作系統內核的LVS、基於應用程式的Nginx、KeepAlive、HAProxy
硬體均衡器包括F5、A10等公司提供的硬體負載均衡產品

5 服務端緩存

引入緩存的理由：

減緩CPU計算壓力
緩存IO壓力
這2個緩解只是能峰值時的壓力緩解，如果普通的響應都很慢，那就算用了緩存也意義不大。

5.1 緩存的幾個屬性

緩存需要選型，選型時需要根據實際場景選擇你匹配的緩存熟悉

吞吐量

JDK8改進後的ConcurrentHashMap是併發場景下吞吐量最高的緩存容器，但除了吞吐量其他的能力就很弱了。

緩存狀態更新思路：

GuavaCache: 同步處理機制，在訪問數據時一併更新，分段加鎖減少競爭
Caffeine：非同步日誌提交機制，參考資料庫日誌，並且還有環形緩衝區容忍有損失的狀態變更，讀性能非常快，使用多讀少寫的情況。

命中率和淘汰策略

基礎的三種淘汰方案：

FIFO：先進先出，簡單實現，但對於高頻訪問的緩存命中率低，越常用到越可能先進入隊列
LRU：優先淘汰最久未被訪問，基於時間，用HashMap+鏈表List實現，但每個緩存都要記錄時間，且可能淘汰短期內正好沒訪問且價值高的數據
LFU：優先淘汰最不頻繁使用，基於使用次數，可以解決LRU的缺點。
自身缺點：

每個緩存專門維護要更新次數的計數器，維護開銷大還有加鎖問題（LRU的更新時間不需要考慮加鎖，直接覆蓋最新即可）
如果某個緩存某時期訪問很高，比其他緩存高了一個數量級，後面不再使用，想淘汰很困難

為瞭解決上面2個缺點，有2個新的策略：

TinyLFU：解決修改計數器的開銷問題，採用Sketch分析訪問數據，用少量數據估計全體數據特征，採用滑動時間窗、熱度衰減等處理
W-Tinfy-LFU：結合了LRU+LFU的特點，考慮熱度和時間。

分散式能力

分散式緩存介紹了複製式緩存JbossCache以及集中式緩存Memcached。

jbosscache的缺點在於寫入性能太差，容易因為網路同步速度跟不上寫入速度，導致記憶體中積累過多待發對象引發omm

memcached是C語言實現的，好處在於讀寫性能高，缺點在於數據結構太過緊密，非常依賴序列化做跨語言傳輸，如果100個欄位中的1個欄位發生更新，要把100個欄位都發出去更新

redis基本打敗了各種分散式緩存，成為首選。

對於redis等分散式緩存，是不會追求一致性C的
如果一定要一致性C，那應該選用zk或者etcd等分散式協調框架（但他們一般就不會拿來做緩存，因為高併發下吞吐量太低，沒有可用性）

進程內緩存和分散式緩存通常結合使用，但容易出現二者數據不一致，寫維護策略導致緩存對開發者而言不透明。
一種設置原則是變更以分散式緩存中的數據為主，訪問以進程內緩存的數據優先。
大致做法是數據發生變動時，在分散式緩存內推送通知，讓一級緩存失效。
訪問緩存時，提供封裝好的一二級聯合查詢介面，讓開發者對一二級緩存不感知。