摘要：本文主要是對《鳳凰架構》的解讀，講述規劃系統流量的幾種方式。 本文分享自華為雲社區《大流量時代，如何規劃系統流量提升可靠性》，作者：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等分散式協調框架（但他們一般就不會拿來做緩存，因為高併發下吞吐量太低，沒有可用性）
進程內緩存和分散式緩存通常結合使用，但容易出現二者數據不一致，寫維護策略導致緩存對開發者而言不透明。
一種設置原則是 變更以分散式緩存中的數據為主，訪問以進程內緩存的數據優先。
大致做法是數據發生變動時， 在分散式緩存內推送通知， 讓一級緩存失效。
訪問緩存時，提供封裝好的一二級聯合查詢介面， 讓開發者對一二級緩存不感知。
5.2 緩存風險
緩存穿透
大量不存在的緩存打進來
要麼是支持對不存在的數據緩存空值
要麼是引入布隆過濾器
緩存擊穿
同一時間瞬間涌現很多請求，訪問資料庫有但是緩存里沒有的數據，此時可能直接打穿資料庫（緩存生效是有延遲的）
可以是用鎖、隊列來完成同步
對於熱點緩存，提前預處理或者配置策略
