一、前言

在網際網路廠商業務不斷擴充套件之後，多種服務的入口會導致接入流量的劇增，所以多數基於IPVS或者Nginx等初級負載均衡技術的早期方案都會面臨故障或者失效，所以就像google開發meglev一樣，許多網際網路服務提供商也都紛紛開發自己的分散式軟體負載均衡系統作為對外服務的接入口。

美團點評在它的技術部落格上表明它也面臨這樣的接入流量爆炸問題，並且基於繼續對IPVS的效能瓶頸的分析，開發了它們自己的四層分散式軟體負載均衡系統，參見美團點評的技術部落格《MGW——美團點評高效能四層負載均衡》。

轉載自https://blog.csdn.net/cloudvtech

二、美團點評傳統四層負載均衡技術面臨的問題和解決方案

根據美團點評的運維經驗總結，傳統IPVS面臨如下一些效能瓶頸：

• 中斷爆炸
• 核心協議棧冗餘處理
• 核心鎖
• 上下文切換
• 連線一致性

2.1 中斷爆炸

在大併發高速接入系統中，每個網絡卡可能都要以接近於線速的處理能力工作，這時候，每秒產生的中斷響應次數是百萬級別的,每一箇中斷都會搶佔正在進行負載均衡後續處理的邏輯，造成大量的切換和cache miss，影響效能。所以在大併發的系統中，需要使用基於輪詢模式的硬體請求處理模式。

2.2 核心協議棧的冗餘處理

IPVS藉助於netfilter進行資料包的處理，所以在到達IPVS的處理邏輯之前，需要經過很長的一條核心處理鏈，造成了IPVS整體處理能力的下降。需要使用核心bypass的技術縮小IPVS應用邏輯和網絡卡驅動的距離。

而DPDK提供的使用者態PMD驅動可以解決2.1和2.2這兩個問題。藉助於Linux UIO技術，在使用者態通過poll的形式直接處理網絡卡驅動的事件，批量的處理資料包，有很好的效能提升。同時由於DPDK針對Intel處理器架構下面的記憶體、NUMA等基礎計算資源所做的優化，以及豐富的開發庫的支援，所以使用DPDK作為基礎開發框架。

2.3 核心鎖

由於MGW使用FULLNAT作為轉發方案，所以需要維護一個session表來追蹤資料包源IP和NAT之後IP的對應關係；而在啟動RSS的網絡卡中，同一個源IP的資料包可能會被分發到不同的CPU處理，所以可能存在請求和響應同時在系統中不同的CPU上處理，從而會對同一個session表同時進行讀寫，所以需要對session表的訪問加鎖，造成效能下降。

MGW使用CPU與local IP繫結的方式，保證同一個FULLNAT流程中的資料包能序列的在用一個CPU上處理，去掉了鎖結構。

2.4 上下文切換

在傳統Linux系統中，控制面和資料面是共享CPU的，在大量資料包需要處理的時候，會不斷在控制面和資料面的處理邏輯間進行上下文切換，巨大的切換開銷和cache miss會降低系統處理能力。

藉助DPDK和UIO技術，在使用者態繫結CPU到不同的執行緒進行轉發邏輯處理，將合適資料的CPU留給控制面以及核心使用，這樣資料面處理過程不再有切換開銷，可以顯著提升效能。

2.5 連線一致性

在分散式負載均衡系統中，需要保證同一個TCP連線上的資料包能夠為同一個後端伺服器所處理，所以分散式負載均衡系統需要一個狀態同步方案能夠保證不同負載均衡節點狀態的一致性。

在Meglev中使用google開發的Meglev consistent hashing演算法，來保證一定程度的一致性和出錯狀態較低的連線失敗率；而在MGW中，使用了跨節點狀態同步的方法來保證負載均衡叢集中各個節點FULLNAT session狀態的強一致性，保證路由器ECMP轉發資料包到任何一個負載均衡節點都能被快速處理，這種強一致性可能會導致一定的控制面效能損失和更長的節點上線時間進行一個session同步的預熱過程。同時在後端伺服器選擇中，使用了Meglev consistent hashing演算法來保證出錯時候的最小影響範圍。

2.6 故障切換

MGW前端的交換機使用物理介面連線MGW的負載均衡伺服器的NIC，負載均衡伺服器上健康監測程式以500ms間隔監測本伺服器的狀態，發現異常，快速關閉網絡卡；在這種情況下，交換機會馬上感知埠斷電狀態並且瞬間關閉到該埠的轉發，幾乎無延時的且走流量。

MGW宣稱可以做到升級操作0丟包，主程式故障0丟包，其他異常（網線等）會有一個最長500ms的丟包(對應於狀態監測程式500ms的監測間隔)：

轉載自https://blog.csdn.net/cloudvtech

三、總結

美團點評的基於DPDK開發的FULLNAT模式MGW在實踐中在傳統網路環境和overlay大二層環境下都有很好的效能和穩定性，使用在網站資料庫、千萬級長連線、以及web服務等業務中。

轉載自https://blog.csdn.net/cloudvtech