給高并發降溫，美團高性能、高可靠四層負載均衡MGW優化實踐
原創【51CTO.com原創稿件】負載均衡是實現網絡就近接入的核心技術之一，它的作用是把海量涌入的流量相對均勻的調配到N個可完成相同任務的網絡節點或服務器，來規避載壓不均的狀況。負載均衡作為應用流量的入口，直接影響應用的性能和可靠性。
近日，51CTO 以“Tech Neo”為主題的第十五期技術沙龍在北京舉行，本次沙龍邀請了來自美團云負載均衡網關MGW產品研發負責人王偉。他擁有多年負載均衡系統的一線實施經驗，主導并推進MGW（美團四層負載均衡）的技術選型以及性能優化工作。本文中，我們可以了解到承載美團點評數十 Gbps的流量、上千萬的并發連接的MGW、如何實現高性能、高可靠的詳盡優化過程等。
負載均衡的作用及分類
互聯網初期階段，業務邏輯簡單、流量不大，單臺服務器就可滿足日常需求。隨著互聯網的發展，業務不僅會流量爆發、邏輯越來越復雜且對可靠性的需求也逐步遞增。這時，就需要多臺服務器來應對單臺服務器在性能、單點等方面凸顯出來的問題，進行性能的水平擴展和災備。但客戶端的流量要如何順利訪問到這么多不同的服務器是個問題。
對于這個問題，可選擇使用DNS做負載，對客戶端不同IP地址進行解析，使得流量直接到達不同的應用服務器。但這個調度策略相對簡單卻不能很好的滿足業務需求，當改變調度策劃后，DNS各級節點的緩存不能及時在客戶端生效，會導致很嚴重的延時性問題。這時可選擇使用負載均衡，如下圖：
如圖所示，客戶端的流量先到達負載均衡服務器，再由負載均衡服務器采用一些調度算法，把流量分發到不同的應用服務器。與此同時，負載均衡服務器對應用服務器進行周期性健康檢查，一旦查出故障節點，直接剔除，進而保證應用的高可用。
負載均衡分為四層和七層兩種，如下圖：
四層負載均衡的核心是轉發，收到客戶端流量，對數據包地址信息進行修改后，轉發到應用服務器，整個過程均在OSI模型的傳輸層完成。
七層復雜均衡的核心是代理，當接收到客戶端的流量后，通過完整的TCP/IP協議棧對應用層流量進行解析。之后，基于調度算法選擇合適的應用服務器，并與應用服務器建立連接將請求發送，整個過程在OSI模型的應用層完成。
四層負載均衡的轉發模式
轉發是四層負載均衡的主要工作，目前主要有四種轉發模式：DR模式、NAT模式、TUNNEL模式和FULLNAT模式。如下是四種轉發模式的優缺點對比圖表：
從圖中可以直觀的看到四種轉發模式的優缺點，DR模式（三角傳輸）的實現方式是修改數據包的目的MAC地址；NAT模式的實現方式是修改數據包的目的IP地址；TUNNEL模式的實現方式和DR相同，但要求應用服務器必須支持TUNNEL功能。
美團點評最終選擇FULLNAT作為MGW的轉發模式，它是在NAT模式的基礎上做一次源地址轉換（即SNAT）。此模式的優勢在于可使應答流量經過正常三層路由回歸負載均衡，負載均衡就不需以網管的形式存在于網絡中，進而降低了對網絡環境的要求。不足之處在于做SNAT，應用服務器會出現丟失客戶端的真實IP地址的情況。
如下圖，是FULLNAT轉發模式的具體實現流程：
如圖在負載均衡上布設localip池，做SNAT的過程中，源IP取自其中。當客戶端流量到達負載均衡設備，負載均衡依據調度策略在應用服務器池中選擇一個應用服務器，將數據包的目的IP改為應用服務器IP。同時從localip池中選擇一個localip將數據包的源IP改為localip，這樣應用服務器在應答時，目的IP是localip，而localip是真實存在于負載均衡上的IP地址，因此可以經過正常的三層路由到達負載均衡。
與NAT模式相比，FULLNAT模式會多做一次SNAT，過程中還有選端口的操作，在性能方面要稍弱于NAT模式，但FULLNAT模式在網絡適應性方面要占優勢。
采用高性能、高可靠四層負載均衡的原因
為什么美團點評會選擇自研的四層負載均衡呢？主要有兩個原因：
- 業務流量遞增，LVS出現性能瓶頸及運維成本的上升。
- 采用硬件負載均衡，成本是門檻。
LVS方面，美團點評最初的方式是使用LVS做四層負載均衡、Nginx做七層負載均衡。如上圖所示，流量高速增長，LVS在性能上出現瓶頸，故障率增加。
在硬件負載均衡方面，凸顯出來的問題有三方面：異常高的硬件成本、人力成本和時間成本。
綜合這兩個原因，美團點評決定自研四層負載均衡MGW來替換LVS，MGW需要滿足高性能、高可靠兩個特性。那么如何實現高性能、高可靠呢？
MGW實現高性能的四大問題和解決方法
對比LVS的一些性能瓶頸，我們可以直觀了解MGW實現高性能的解決方法。這里主要涉及LVS遇到的中斷、過長的協議棧路徑、鎖和上下文切換這四大問題，MGW應對這些問題的解決辦法分別是PMD驅動、Kernelbypass、無鎖的設計和CPU綁定、隔離。
中斷
LVS是做在內核中的，而內核在設計時要兼顧通用性，所以采用中斷的方式感知流量的接收。中斷對LVS性能的影響非常大，如果每秒處理500萬數據包，每5個數據包產生一個硬件中斷，那么一秒會產生100萬個硬件中斷，每一次產生的硬件中斷都會打斷正在進行密集計算的負載均衡程序，中間產生大量的cache miss，這對性能的影響非常大。
過長協議棧路徑
因為LVS是基于內核netfilter開發的應用程序，而netfilter是運行在內核協議棧的一個鉤子框架。當數據包到達LVS時，要經過一段很長的協議棧處理。實際情況是負載均衡在接到流量以后，只需對MAC、IP、端口進行修改發出即可，并不需要這段處理來增加額外的消耗。
針對中斷和過長協議棧路徑這兩個問題的解決方法是采用由DPDK提供的用戶態PMD驅動以及做Kernelbypass。DPDK在設計過程中，使用了大量硬件特性，如numa、 memory channel、 DDIO等對性能提升很大。同時提供網絡方面的庫，進而減小開發難度，提升開發效率。這些都是美團點評選擇DPDK作為MGW的開發框架的因素。
鎖
內核是較通用的應用程序，為了兼顧不同硬件，在設計過程中會加一些鎖。而自主研發只需對某些特定場景進行定制設計，不用兼顧很多硬件，進而通過一些方法去掉鎖，實現完全無鎖的狀態，方便后續擴展。
先來看看什么情況需要進行鎖的設計。首先介紹一下RSS（Receive Side Scaling），RSS是一個通過數據包的元組信息將數據包散列到不同網卡隊列的功能，這時不同CPU再去對應的網卡隊列讀取數據進行處理，就可充分利用CPU資源。
MGW使用的是FULLNAT模式，會將數據包的元組信息全部改變。這樣同一個連接，請求和應答方向的數據包有可能會被RSS散列到不同的網卡隊列中，在不同的網卡隊列也就意味著在被不同的CPU進行處理，這時在訪問session結構就需要對這個結構進行加鎖保護。
解決這個問題，一般情況下有如下兩種方案：
- 在做SNAT選端口時，通過選擇一個端口lport0讓RSS(cip0, cport0, vip0, vport0) = RSS(dip0, dport0, lip0, lport0)相等。
- 為每個CPU分配一個localip，做SNAT選IP時，不同CPU選擇自有的localip，當應答回來后，再通過lip和CPU的映射關系，將指定目的IP的數據包送到指定隊列上。
由于第二種方法恰好可被網卡的flow director特性支持，因此MCW選擇第二種方法來去掉session結構的鎖。
flow director可依據一定策略將指定的數據包送到指定網卡隊列，其在網卡中的優先級要比RSS高，因此在做初始化的時候就為每個CPU分配一個localip：
- 如為cpu0分配lip0，為cpu1分配lip1，為cpu2分配lip2，為cpu3分配lip3。 當一個請求包（cip0, cport0, vip0, vport0）到達負載均衡后，被RSS散列到了隊列0上，這時這個包被cpu0處理。
- cpu0在對其做fullnat時，選擇cpu0自己的localip lip0，然后將數據包（lip0, lport0, dip0, dport0）發到應用服務器，在應用服務器應答后，應答數據包（dip0, dport0, lip0,lport0）被發到負載均衡服務器。
這樣就可以在flow director下一條將目的IP為lip0的數據包發送到隊列0的規則，這樣應答數據包就會被送到隊列0讓cpu0處理。這時CPU在對同一個連接兩個方向的數據包進行處理的時候就是完全串行的一個操作，也就不需再對session結構進行加鎖保護。
上下文切換
針對上下文切換的問題，MGW設計有對CPU進行分組，實現控制平面與數據平面完全分離的狀態，可以很好的避免數據平面做處理時被打斷的現象，如下圖所示：
同時，對數據平面CPU進行隔離，實現控制平面進程不會調度數據平面這組CPU；對數據平面線程進行CPU綁定，實現每個數據線程獨占一個CPU。控制平面的程序均跑在控制平面的CPU上，如Linux kernel、 SSH等。
MGW實現高可靠的解決方法
這里主要介紹在MGW集群、MGW單機及應用服務器這三層實現高可靠的方法。
MGW集群
集群的高可靠主要涉及三部分：session同步、故障切換、故障恢復與擴容。如下圖所示，MGW采用ECMP+OSPF的模式組成集群：
ECMP的作用是將數據包散列到集群中各個節點，再通過OSPF保證單臺機器故障以后將這臺機器的路由動態的剔除出去，這樣ECMP就不會再給這臺機器分發流量，也就做到了動態的failover。
session同步
傳統ECMP在算法方面存在一個嚴重問題，當復雜均衡集群中節點數量發生變化時，會導致大部分流量的路徑發生改變，發生改變的流量到達其他MGW節點上，找不到自身的session結構，就會導致大量的連接出現異常，對業務影響很大，且當在對集群做升級操作時會將每個節點都進行一次下線操作，這樣就加重了這個問題的影響。
傳統的解決方式是使用支持一致性hash的交換機，如下圖所示。
傳統的解決方式是使用支持一致性hash的交換機，當節點發生變化的時候，只對發生變化的節點上面的連接會有影響，其他連接都會保持正常，但是支持這種算法的交換機比較少，并且也沒有完全實現高可用，因此需要做集群間的session同步功能，如下圖所示：
集群中每個節點都會全量的將自身session進行同步，使集群中每個節點都維護一份全局session表。這樣一來，當節點發生變化，流量路徑無論發生任何形式的改變，流量都可以找到自身的session結構。
下面，故障切換與故障恢復及擴容是在做集群間的session同步功能的整個過程中首要考慮的兩大問題。
故障切換
針對故障切換問題，當機器發生故障后，交換機可立刻將流量切到其他機器，避免大量丟包的情況。經過調研測試，MGW采用如下圖所示的操作方法，可做到升級操作0丟包，主程序故障0丟包，其他異常（網線等）會有一個最長500ms的丟包，因為這種異常需要靠自檢程序去檢測，而自檢程序的周期是500ms。
具體包括如下四方面內容：
交換機側不使用虛擬接口。全部使用物理接口且服務器側對接口進行斷電時，交換機會瞬間將流量切換到其他機器。通過100ms發兩個包的測試（客戶端和服務端各發一個），表明這種操作方法可實現0丟包。
半秒一次機器健康自檢。故障切換主要依賴于交換機的感知，當服務器上出現異常，交換機感知不到時，交換機就無法進行故障切換操作，因此需要一個健康自檢程序，每半秒進行一次健康自檢，當發現服務器存在異常時就對服務器執行網口斷電操作，從而將流量立刻切走。
檢測到故障自動給網口斷電。故障切換主要依賴于網口斷電操作且網卡驅動是跑在主程序里面的，當主程序掛掉以后，就無法再對網口執行斷電操作。
主進程會捕獲異常信號。針對主程序掛掉后，就無法再對網口執行斷電操作的現象，主進程會捕獲異常信號，當發現異常時就對網卡進行斷電操作，在斷電操作結束后再繼續將信號發給系統進行處理。
故障恢復與擴容
系統進行故障恢復、擴容操作時，會使得集群節點數量發生變化，進一步導致流量路徑發生變化。
因為已經發生變化的流量到達集群中原有節點時，原有節點都維護一個全局session表，所以這些流量是可以被正常轉發的；但當流量到達一個新機器，這臺新機器由于沒有全局session表，這部分流量會全部被丟棄。
針對這個問題，MGW在上線后會經歷預上線的中間狀態，此狀態下，MGW不會讓交換機感知到自己上線，所以交換機也就不會把流量切過來。
實現流程是首先MGW會對集群中其他節點發送批量同步的請求，其他節點收到請求以后會將自己的session全量同步到新上線的節點，新上線節點在收到全部session以后才會讓交換機感知到自己上線，這時交換機再將流量切入，就可正常被轉發。
這里需要提醒兩點：
其一：由于集群中并沒有一個主控節點來維護一個全局的狀態，如果request報數據丟失或者session同步的數據丟失的話，那么新上線節點就沒辦法維護一個全局的session狀態。但考慮到所有節點都維護著一個全局的session表，因此所有節點擁有的session數量都是相同的，那么就可以在所有節點每次做完批量同步以后發送一個finish消息，finish消息中帶著自己擁有的session數量。當新上線節點收到finish消息以后，便會以自己的session數量與finish中的數量做對比。當達到數量要求以后，新上線節點就控制自己進行上線操作。否則在等待一定的超時時間以后，重新進行一次批量同步操作，直到達到要求為止。
其二：在進行批量同步操作時，如果出現新建連接，那么新建連接就不會通過批量同步同步到新上線的機器上。如果新建連接特別多，就會導致新上線機器一直達不到要求。因此，需要保證處于預上線狀態的機器能接收到增量同步數據，因為新建連接可以通過增量同步同步出來。通過增量同步和批量同步就可以保證新上線機器可以最終獲得一個全局的session表。
MGW單機
自動化測試平臺
單機高可靠方面，MGW研發自動化測試平臺，通過連通性和配置的正確性來判斷一個測試用例是否執行成功，失敗的測試用例平臺可以通過郵件通知測試人員。在每次新功能迭代結束以后，都會將新功能的測試用例加到自動化平臺里面，這樣在每次上線之前都進行一次自動化測試，可以大大避免改動引發的問題。
在這之前，每次上線之前都需要進行一次手動的回歸測試，回歸測試非常耗時并且很容易遺漏用例，但是為了避免改動引發新問題又不得不做，有了自動化測試平臺以后，可提升回歸測試的效率和可靠性。
應用服務器
在應用服務器靠性方面，MGW布設節點平滑下線和一致性源IP Hash調度器兩大功能。
節點平滑下線
節點平滑下線功能主要是為了解決當用戶需要對RS進行升級操作時，如果直接將需要升級的RS下線，那這個RS上存在的所有連接都會失敗，影響到業務。此時如果調用MGW的平滑下線功能，MGW就可以保證此RS已有連接正常工作，但不會往上面調度新的連接。
當所有已有連接結束以后，MGW會上報一個結束的狀態，用戶就可以根據這個結束的狀態對RS進行升級操作，升級后再調用上線接口讓這個RS器進行正常的服務。如果用戶平臺支持自動化應用部署，那就可以通過接入云平臺使用平滑下線功能，實現完全自動化且對業務無影響的升級操作。
一致性源IP Hash調度器
源IP Hash調度器主要是保證相同的客戶端的連接被調度到相同應用服務器上，也就是說建立一個客戶端與應用服務器一對一的映射關系。普通源IP Hash調度器在應用服務器發生變化以后會導致映射關系發生改變，會對業務造成影響。
一致性源IP Hash調度器，保證在應用服務器集群發生變化時，只有發生變化的應用服務器與客戶端的映射關系發生改變，其他保持不變。
為了保證流量的均衡，首先在hash環上分配固定數量的虛擬節點，然后將虛擬機節點均衡的重分布到物理節點上，重分布算法需要保證：
- 在物理節點發生變化時，只有少數虛擬節點映射關系發生變化，也就是要保證一致性Hash的基本原則。
- 因為MGW是以集群的形式存在的，當多個應用服務器發生上線、下線操作時，反饋到不同的MGW節點上就有可能會出現順序不一致的問題，因此無論不同的MGW節點產生何種應用服務器上下線順序，都需要保證最終的映射關系一致，因為如果不一致就導致相同客戶端的連接會被不同的MGW節點調度到不同的應用服務器上，也就違背源IP Hash調度器的原則。
技術展望
未來，美團點評將主要在這三方面發力：升級自動化、集中式配置管理和降低運維成本。
升級自動化。最初自研MGW是為解決LVS的性能問題，在這些問題被解決之后，隨著業務的快速發展，IDC不斷增長，負載集群越來越多，像某個新IDC上線，一般都要上線兩套集群，分別用于IDC入口和內部業務。
這樣的情況下，又涌現出更大的問題，如一個新功能發布時， 周期會非常長，所以需要實現自動化升級。當然，在完善監控措施方面也要同步，對異常進行監控。
集中式配置管理。目前業務配置已經實現集中式配置，未來希望機器的配置也能實現。
更低的運維成本。實現自動化升級，集中式配置最根本的目的就是降低運維成本。
【嘉賓介紹】
王偉，美團云技術專家。2015年加入美團云，現任美團云負載均衡網關MGW產品研發負責人，擁有多年負載均衡系統的一線實施經驗，主導并推進了MGW的技術選型以及性能優化工作。
沙龍其他文章
10 月 28 日 / 北京，第十六期“Tech Neo”沙龍，主題：“自動化運維與 DevOps”，點擊圖片，立即報名。
【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】
