負載均衡是雲計算的基礎元件，是網絡流量的入口，其重要性不言而喻。
什麼是負載均衡呢?使用者輸入的流量通過負載均衡器按照某種負載均衡算法把流量均勻地分散到後端的多個伺服器上，接收到請求的伺服器可以獨立的響應請求，達到負載分擔的目的。從應用場景上來說，常見的負載均衡模型有全局負載均衡和叢集内負載均衡，從産品形态角度來說，又可以分為硬體負載均衡和軟體負載均衡。
全局負載均衡一般通過DNS實作，通過将一個域名解析到不同VIP，來實作不同的region排程能力;硬體負載均衡器常見的有F5、A10、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 1. 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上，這對使用者場景也做了限制。
2. LVS基于Netfilter架構實作 Netfilter是Linux提供的網絡開放平台，基于平台可以開發自己的業務功能子產品，早期好多安全廠商都是基于Netfilter做一些業務模型實作，這種模型比較靈活，但通用模型裡更多的是相容性考慮，路徑會非常長;而且通用模型中沒辦法發揮多核特性，目前CPU的發展更多是向橫向擴充，我們經常見到多路伺服器，每路上有多少核，早期通用模型對多核支援并不是特别友善，在多核設計上有些欠缺，導緻我們在通用模型上做一些應用開發時的擴充性是有限的，随着核的數量越來越多，性能不增反降。
3. 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的轉發規則、HTTP2、Websocket等功能;目前，我們7層單VIP可以支撐10W規格的HTTPS QPS。
高可用 1. Group 高可用是整個産品很重要的一部分，圖為叢集内的高可用架構圖，可以看到，在網絡路徑上是全備援無單點的。具體情況如下：
雙路伺服器，每節點雙網口上聯不同交換機，增加帶寬，避免跨節點收包
VIP路由兩邊發不同的優先級，不同的VIP，高優先級路由在不同的交換機上
單機160G轉發能力，單VIP 80G帶寬，單流 40G帶寬
網卡故障不影響轉發，上下遊路由自動切換
ECMP，VIP路由發兩邊，通過優先級控制從入口
叢集640G轉發能力，單vip 320G帶寬
會話同步，多點傳播、包觸發同步、定時同步
單機故障不影響轉發
交換機故障不影響轉發，路由秒級切換
使用者無感覺的更新變更，部分未及時同步的連接配接重連即可
2. AZ 每個機房連接配接兩個不同路由器，當一個AZ出現故障之後，我們可以無縫切換到另外一個機房，具體情況如下：
VIP在不同的AZ發不同優先級的路由(秒級切換、自動切換)
VIP區分主備AZ，不同的VIP主備AZ不同
多個AZ的負載通過控制系統配置設定
預設提供VIP多AZ的容災能力
不支援跨AZ的session同步，跨AZ切換後，所有連接配接都需要重連
3. Region 當使用者通路域名時，通過DNS解析，可以設定DNS解析到多個regionVIP位址，下沉到某一個Region來看，如果一個機房出現故障，流量可以切換到另一個可用區繼續轉發，如果流量進到機房發現一台LVS轉發裝置出現故障後，我們可以切換到另外一台LVS作處理，如果LVS後面挂載的RS出現問題，通過健康檢查也可以快速摘掉裝置，将流量轉換到健康的裝置上去。我們從多個次元實作高可用，較大限度地滿足使用者的需求。
總結目前，高性能負載均衡應用主要在幾個方面：
作為公有雲基礎元件，為公有雲網站、遊戲客戶、APP提供負載均衡功能，也針對政府、金融等安全性高的客戶提供專有雲支援;
為阿裡雲内部雲産品RDS、OSS、高防等提供了負載均衡的功能;
負載均衡作為電商平台入口，向淘寶、天貓、1688提供VIP統一接入功能;
交易平台的流量入口也在負載均衡裝置上，如支付寶、網上銀行。
未來，我們希望有更好的彈性擴充能力，更高的單機處理能力，我們希望VIP主動探測使用者，以及網絡全鍊路監控。
歡迎工作一到五年的Java工程師朋友們加入Java填坑之路：860113481
群内提供免費的Java架構學習資料（裡面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！