如何打造應對超大流量的高性能負載均衡？

負載均衡

負載均衡是雲計算的基礎組件，是網絡流量的入口，其重要性不言而喻。

什麼是負載均衡呢？用戶輸入的流量經過負載均衡器按照某種負載均衡算法把流量均勻地分散到後端的多個服務器上，接收到請求的服務器能夠獨立的響應請求，達到負載分擔的目的。從應用場景上來講，常見的負載均衡模型有全局負載均衡和集羣內負載均衡，從產品形態角度來講，又能夠分爲硬件負載均衡和軟件負載均衡。

全局負載均衡通常經過DNS實現，經過將一個域名解析到不一樣VIP，來實現不一樣的region調度能力；硬件負載均衡器常見的有F五、A十、Array，它們的優缺點都比較明顯，優勢是功能強大，有專門的售後服務團隊，性能比較好，缺點是缺乏定製的靈活性，維護成本較高；如今的互聯網更多的思路是經過軟件負載均衡來實現，這樣能夠知足各類定製化需求，常見的軟件負載均衡有LVS、Nginx、Haproxy。

咱們的高性能負載均衡使用LVS和Tengine，在一個region區分不一樣的機房，每一個機房都有LVS集羣和Tengine集羣，對於用戶配置的四層監聽，LVS後面會直接掛載用戶ECS，七層用戶監聽ECS則掛載在Tengine上，四層監聽的流量直接由LVS轉發到ECS，而7層監聽的流量會通過LVS到Tenigine再到用戶ECS。每個region裏都會有多個可用區，達到主備容災目的，每個集羣裏都有多臺設備，第一是爲了提高性能，第二也是基於容災考慮。

上圖爲高性能負載均衡控制管理概要圖，SLB產品也有SDN概念，轉發和控制是分離的，用戶全部配置經過控制檯先到控制器，經過集中控制器轉換將用戶配置推送到不一樣設備上，每臺設備上都有Agent接收控制器下發的需求，經過本地轉換成LVS和Tengine可以識別的配置，這個過程支持熱配置，不影響用戶轉發，不須要reload才能使新配置生效。

LVS

一、LVS支持的三種模式

早期LVS支持三種模式，DR模式、TUN模式和NAT模式。

DR模式通過LVS以後，LVS會將MAC地址更改、封裝MAC頭，內層IP報文不動，報文通過LVS負載均衡查找到RS以後，將源MAC頭改爲本身的，目的MAC改爲RS地址，MAC尋址是在二層網絡裏，對網絡部署有必定的限定，在大規模分佈式集羣部署裏，這種模式的靈活性沒有辦法知足需求；

TUN模式走在LVS以後，LVS會在原有報文基礎上封裝IP頭，到了後端RS以後，RS須要解開IP報文封裝，才能拿到原始報文，不論是DR模式仍是TUN模式，後端RS均可以看到真實客戶源IP，目的IP是本身的VIP，VIP在RS設備上須要配置，這樣能夠直接繞過LVS返回給用戶，TUN模式問題在於須要在後端ECS上配置解封裝模塊，在Linux上已經支持這種模塊，可是windows上尚未提供支持，因此會對用戶系統鏡像選擇有限定。

NAT模式用戶訪問的是VIP，LVS查找完後會將目的IP作DNAT轉換，選擇出RS地址，由於客戶端的IP沒變，在回包的時候直接向公網真實客戶端IP去路由，NAT的約束是由於LVS作了DNAT轉換，因此回包須要走LVS，把報文頭轉換回去，因爲ECS看到的是客戶端真實的源地址，咱們須要在用戶ECS上配置路由，將到ECS的默認路由指向LVS上，這對用戶場景也作了限制。

二、LVS基於Netfilter框架實現

Netfilter是Linux提供的網絡開放平臺，基於平臺能夠開發本身的業務功能模塊，早期好多安全廠商都是基於Netfilter作一些業務模型實現，這種模型比較靈活，但通用模型裏更多的是兼容性考慮，路徑會很是長；並且通用模型中沒辦法發揮多核特性，目前CPU的發展更可能是向橫向擴展，咱們常常見到多路服務器，每路上有多少核，早期通用模型對多核支持並非特別友善，在多核設計上有些欠缺，致使咱們在通用模型上作一些應用開發時的擴展性是有限的，隨着核的數量愈來愈多，性能不增反降。

三、LVS的改進

早期模式的各類限制制約了咱們的發展，因此咱們首先作了FullNAT，相比原來的NAT方式，FullNAT多了SNAT屬性，將客戶端的原IP地址做了轉換；

其次，咱們在並行化上作了處理，充分利用多核實現性能線性提高；

而後是快速路徑，咱們在作網絡轉發模型時很容易想到設計快速路徑和慢速路徑，慢速路徑更可能是解決首包如何經過設備問題，可能須要查ACL或路由，須要判斷許多和策略相關的東西，後面全部報文均可以經過快速路徑轉發出去；

還有指令相關優化，利用因特爾特殊指令提高性能；

另外針對多核架構，NUMA多節點內存訪問，經過訪問Local節點內存可能得到更好的延遲表現。

客戶端進來IP首先訪問LVS的VIP，原IP是客戶端的，目的IP是LVS的VIP，通過FullNAT轉換後，原IP變成LVS的Local地址，目的地址是LVS選擇出來的RS地址，這樣在RS回包時比較容易，只要路由可達，報文必定會交到LVS上，不須要在RS上作特殊的配置。右面就是DNAT+SNAT轉換，報文就能夠經過LVS轉發回客戶端，這種方式主要帶來應用場景部署靈活性選擇。

經過並行化實現對LVS性能的改善，性能沒有辦法獲得線性提高更多的是由於每條路徑都須要訪問全局資源，就會不可避免引入鎖的開箱，另外，同一條連接上的報文可能分散在不一樣的核上，你們去訪問全局資源時也會致使cache的丟失。

因此咱們經過RSS技術把同一個五源組報文扔到同一個CPU上處理，保證入方向的全部相同鏈接上的報文都能交給相同CPU處理，每一個核在轉發出去時都用當前CPU上的Local地址，經過設置一些fdir規則，報文回來時後端RS訪問的目的地址就是對應CPU上的local地址，能夠交到指定的CPU上去處理，這樣一條鏈接上左右方向報文均可以交給同一個CPU處理，將流在不一樣的CPU隔離開。

另外，咱們把全部配置資源包括動態緩存資源在每一個CPU上做了拷貝， 將資源局部化，這使整個流從進入LVS到轉發出去訪問的資源都是固定在一個核上的本地資源，使性能達到較大化，實現線性提高。

通過咱們改進以後，LVS的具體表現以下：

出於對容災和性能提高的考慮，咱們作了集羣化部署，每一個region有不一樣機房，每一個機房有多個調度單元，每一個單元有多臺LVS設備；

每臺LVS通過優化後，都能達到更高性能，大容量，單臺LVS能夠達到4000W PPS，600W CPS、單個group能夠到達1億併發；

支持region、IDC、集羣和應用級的高可用；

實現了防×××功能，並在原版LVS上提供了更豐富的功能，能夠基於各個維度作管理控制，較精確的統計，流量的分析等。

Tengine

Tengine在應用過程當中也遇到了各類問題，最嚴重的就是性能問題，咱們發現隨着CPU數量愈來愈多，QPS值並無線性提高；Nginx自己是多worker模型，每一個worker是單進程模式，多worker架構作CPU親和，內部基於事件驅動的模型，其自己已經提供了很高的性能，單核Nginx能夠跑到1W5～2W QPS。Nginx往下第一層是socket API，socket 往下有一層VFS，再往下是TCP、IP，socket層比較薄，通過量化的分析和評估，性能開銷較大的是TCP協議棧和VFS部分，由於同步開銷大，咱們發現橫向擴展不行，對此，咱們作了一些優化。

七層反向代理的路徑更長，處理更復雜，因此它的性能比LVS低不少，咱們比較關注單機和集羣的性能，集羣性能能夠靠堆設備去解決，單機若是不提高，成本會一直增長，從性能角度來看，有如下的優化思路和方向：

基於Kernel作開發，好比優化協議棧；

基於Aliscoket的優化，Alisocket是阿里研發的高性能TCP協議棧平臺，底層是DPDK，它將資源作了局部化處理，報文分發不一樣核處理，性能很是出色；

HTTPS業務愈來愈多，流量逐步遞增，咱們採用硬件加速卡方式作一些加解密的性能提高，還有HTTPS的會話複用；

基於Web傳輸層的性能優化。

從彈性角度看，好比一些公司的應用和用戶熱點有關，當發生一個社會網絡熱點後，訪問量會急劇變高，咱們固有的基於物理機器實現的負載均衡模型在彈性擴展方面是有限制的，對此，咱們可使用VM去作，把反向代理功能放在VM去跑，咱們會監控實例負載狀況，根據實時需求作彈性擴容縮容；

除了VM，還有調度單元，咱們能夠在不一樣調度單元作平滑切換，根據不一樣的水位狀況，經過切換能夠把負載均衡實例調度到不一樣的單元中去，改善使容量上管理。Tengine自己也作了集羣化部署，咱們在一個region裏有不一樣的機房，不一樣的調度單元，每一個調度單元有多組設備；LVS到Tengine也有健康檢查，若是一臺Tengine有問題，能夠經過健康檢查方式摘除，不會影響用戶轉發能力；

Tengine具有靈活的調度能力，能夠幫助咱們應對更多的複雜狀況；另外，Tengine也有不少高級的特性，好比基於cookie的會話保持、基於域名/URL的轉發規則、HTTP二、Websocket等功能；目前，咱們7層單VIP能夠支撐10W規格的HTTPS QPS。

高可用

一、Group

高可用是整個產品很重要的一部分，圖爲集羣內的高可用架構圖，能夠看到，在網絡路徑上是全冗餘無單點的。具體狀況以下：

雙路服務器，每節點雙網口上聯不一樣交換機，增長帶寬，避免跨節點收包

VIP路由兩邊發不一樣的優先級，不一樣的VIP，高優先級路由在不一樣的交換機上

單機160G轉發能力，單VIP 80G帶寬，單流 40G帶寬

網卡故障不影響轉發，上下游路由自動切換

ECMP，VIP路由發兩邊，經過優先級控制從入口

集羣640G轉發能力，單vip 320G帶寬

會話同步，多播、包觸發同步、定時同步

單機故障不影響轉發

交換機故障不影響轉發，路由秒級切換

用戶無感知的升級變動，部分未及時同步的鏈接重連便可

二、AZ

每一個機房鏈接兩個不一樣路由器，當一個AZ出現故障以後，咱們能夠無縫切換到另一個機房，具體狀況以下：

VIP在不一樣的AZ發不一樣優先級的路由（秒級切換、自動切換）

VIP區分主備AZ，不一樣的VIP主備AZ不一樣

多個AZ的負載經過控制系統分配

缺省提供VIP多AZ的容災能力

不支持跨AZ的session同步，跨AZ切換後，全部鏈接都須要重連

三、Region

當用戶訪問域名時，經過DNS解析，能夠設定DNS解析到多個regionVIP地址，下沉到某一個Region來看，若是一個機房出現故障，流量能夠切換到另外一個可用區繼續轉發，若是流量進到機房發現一臺LVS轉發設備出現故障後，咱們能夠切換到另一臺LVS做處理，若是LVS後面掛載的RS出現問題，經過健康檢查也能夠快速摘掉設備，將流量轉換到健康的設備上去。咱們從多個維度實現高可用，較大限度地知足用戶的需求。

總結

目前，高性能負載均衡應用主要在幾個方面：

做爲公有云基礎組件，爲公有云網站、遊戲客戶、APP提供負載均衡功能，也針對政府、金融等安全性高的客戶提供專有云支持；

爲阿里雲內部雲產品RDS、OSS、高防等提供了負載均衡的功能；

負載均衡做爲電商平臺入口，向淘寶、天貓、1688提供VIP統一接入功能；

交易平臺的流量入口也在負載均衡設備上，如支付寶、網上銀行。

將來，咱們但願有更好的彈性擴展能力，更高的單機處理能力，咱們但願VIP主動探測用戶，以及網絡全鏈路監控。