F5煉魔葵花寶典---開篇

Hello哇，歡迎大家來到全新的欄目，《F5煉魔葵花寶典》。

《葵花寶典》，欲練此功，必先自宮！！

當(dāng)然，開個玩笑，對于這個欄目，我是希望自己能夠把自己當(dāng)成小白，重新學(xué)習(xí)。

以前其實也動過想要寫類似總結(jié)的念頭，但是總覺得自己好像這些知識都了解掌握了，沒有什么好寫的，也就失去了堅持下去的動力。

至于是魔是仙，全在你的一念之間了。

我從2018年開始工作便開始接觸F5；從剛開始根本不知道什么是F5，什么是負(fù)載均衡的小白，一直到現(xiàn)在，也算是對于F5有一定沉淀的一位中生代工程師；想想也是挺感激現(xiàn)在的老板的，在當(dāng)初能夠給我這個機會接觸到這個行業(yè)，進入這個行業(yè)。

我也是想借這個機會，對自己的知識體系做一個梳理，也希望對后面進入這個行業(yè)，接觸這個產(chǎn)品的朋友們一點借鑒。

Annyway，我們開始今天的話題；

那作為開篇，我們還是先來講講一些負(fù)載均衡的基本知識。

負(fù)載均衡概述

負(fù)載均衡，聽起來好像很陌生，其實在我們的生活中是隨處可見的，舉幾個簡單的例子；

大家應(yīng)該都有過銀行或者營業(yè)廳辦理業(yè)務(wù)的經(jīng)驗，營業(yè)廳一般都會有很多的窗口，可能有的營業(yè)廳會幾個窗口辦理相同的一類業(yè)務(wù)，那么在我們要去哪個窗口辦理業(yè)務(wù)呢？這個時候我們一般會根據(jù)自己想要辦理的業(yè)務(wù)類型，來取號，取完號以后，等待叫號機分配我們?nèi)サ侥膫€窗口就好了。

那其實這就是一種負(fù)載均衡，就是對于大量的請求，根據(jù)一定的規(guī)則，將這些請求分發(fā)到對應(yīng)的一組后端去。

那在網(wǎng)絡(luò)的世界中呢，主要有這些概念：

• 節(jié)點---營業(yè)廳的窗口，這些窗口提供特定的服務(wù)；

• 資源池---一組提供相同服務(wù)的窗口，這些窗口提供相同的服務(wù)，去到哪個窗口都能夠獲得一樣的服務(wù)；

• 負(fù)載均衡器---取號機+叫號器，他可以判斷什么時候輪到你去辦理業(yè)務(wù)，你要去哪個窗口辦理業(yè)務(wù)，你要辦理的業(yè)務(wù)能不能在這個營業(yè)廳辦理；

• 請求---需要辦理業(yè)務(wù)的人。

通過上面的舉例，相信大家對于負(fù)載均衡的工作場景和原理應(yīng)該有一些大概的概念了，那么接下來，我們就進入網(wǎng)絡(luò)的世界，來學(xué)習(xí)一下什么是負(fù)載均衡。

在現(xiàn)實的網(wǎng)絡(luò)中，上了規(guī)模的企業(yè)網(wǎng)、銀行、互聯(lián)網(wǎng)等等，提供服務(wù)的后端都不會是一臺，他們往往都是多臺集群化部署的，一方面是為了冗余備份，不至于一臺出現(xiàn)故障，整個業(yè)務(wù)垮掉；另一方面是為了方便性能的擴展，如果是單臺設(shè)備網(wǎng)上堆性能，很容易達到單臺設(shè)備的性能瓶頸，而橫向擴展往往是最方便和最經(jīng)濟的一種做法。

但是對于服務(wù)的前端，我不可能把所有的后端服務(wù)端口都暴露給用戶，讓用戶自己去選擇入口，或者是運維人員手動給用戶分配入口，因為這樣會大大降低靈活度、時效性并增大運維人員的運維工作量。

那有沒有一種技術(shù)，能夠當(dāng)作服務(wù)和用戶之間的橋梁，我只需要暴露一個端口，由這個技術(shù)幫我接收用戶的請求，并由他來判斷用戶的請求應(yīng)該分發(fā)給哪個后端呢？

負(fù)載均衡器就由此誕生了。

他的工作模式就如下圖所示：

這里大家就可以看出來，在這個架構(gòu)中，負(fù)載均衡器就成為了很重要的核心組件了，那么衡量這個核心組件的關(guān)鍵指標(biāo)都有哪些呢：

• 吞吐---Throughput

吞吐方面還分為四層吞吐和七層吞吐，那么什么是吞吐呢？

吞吐是指這個負(fù)載均衡器每秒鐘能夠處理的數(shù)據(jù)流量是多少，這個流量分為四層流量和七層流量。

四層流量是指TCP類型的請求流量，而七層流量一般是指HTTP類型的流量以及基于HTTP衍生的各種流量類型，如API、WS等

• 新建連接數(shù)---New Connections

新建鏈接數(shù)指每秒鐘可以建立的鏈接數(shù)

• 并發(fā)連接數(shù)---Concurrent Connections

是指負(fù)載均衡器能夠維持的連接數(shù)

• SSL加解密性能

隨著現(xiàn)在HTTPS的應(yīng)用越來越廣泛，對于負(fù)載均衡器的SSL加解密的性能要求也越來越高，因為如果要做基于七層的復(fù)雜的負(fù)載，負(fù)載均衡器對于HTTPS的流量就必須先做解密，解密完成后才能夠了解和判斷HTTP請求的內(nèi)容和特征，才能夠做下一步的怕判斷和分發(fā)。這就要求負(fù)載均衡器要由很強的SSL加解密性能，才能夠支撐更加龐大的業(yè)務(wù)體量。

負(fù)載均衡器的分類

現(xiàn)在市面上主流的分類大體上分為三類：

• 物理硬件
• 軟件
• 公有云

物理硬件主要有：

國外廠商：

• F5，產(chǎn)品系列有LTM\AWAF\DNS\SSLO\APM等，產(chǎn)品覆蓋面廣，更偏向應(yīng)用交付，有強大的iRule，能夠靈活定義流量分發(fā)機制等，支持的協(xié)議也是最廣泛的
• Citrix（現(xiàn)為 Cloud Software Group），產(chǎn)品系列有NetScaler（原 Citrix ADC），其深入集成VDI，現(xiàn)在已退出中國
• A10 Networks，產(chǎn)品系列有Thunder Series（如 Thunder ADC），特點是支持AI/ML進行智能流量分析，現(xiàn)在在國內(nèi)市場保有量較低
• Radware，產(chǎn)品系列有Alteon，特點是有基于AI的智能流量管理，現(xiàn)在中國區(qū)的支持人員不足，保有量也比較低
• Kemp Technologies（現(xiàn)為 Progress），產(chǎn)品系列有LoadMaster，比較小眾的品牌，能夠提供自動伸縮和GEO負(fù)載均衡

國產(chǎn)廠商：

• 深信服，產(chǎn)品系列有深信服應(yīng)用交付 AD（Application Delivery），一般應(yīng)用在教育、醫(yī)療行業(yè)較多；
• 迪普科技，產(chǎn)品系列有DPtech ADC，能夠完全符合國家XC要求的產(chǎn)品；
• 山石網(wǎng)科，產(chǎn)品系列有Hillstone Load Balancer，也是能夠完全符合國家XC要求的產(chǎn)品；
• 神州云科通明湖，產(chǎn)品系列有YK-ADC系列，與F5深度合作，完全符合國家XC標(biāo)準(zhǔn)，從F5技術(shù)脫胎而來，在使用習(xí)慣、使用邏輯等更加貼合F5；

軟件負(fù)載產(chǎn)品主要有：

• Nginx，可以說是世界知名的軟件負(fù)載產(chǎn)品，具備輕量化、高性能的特點，現(xiàn)在被F5.Inc收購，分為開源和商業(yè)兩個版本，開源版的使用范圍最廣，一方面能夠作為Web Server，另一方面也能夠作為LB來使用
• HAProxy，與Nginx類似，性能高，一般適用于大型API服務(wù)器、數(shù)據(jù)庫前端代理
• LVS，與Nginx、HAProxy為排名前三的軟負(fù)載產(chǎn)品
• Envoy，一般更多應(yīng)用在微服務(wù)、Service Mesh的場景中

公有云的負(fù)載產(chǎn)品就取決于各家的公有云廠商了：

• AWS的ELB
• Google的GCLB
• Azure的ALB
• 阿里云的SLB
• 騰訊云的CLB
• 華為云的ELB
• 金山云的KLB
• 百度云的BCLB
• 京東云的JDCloud LB
• 火山云的TLB

大家都大差不差，很多都是基于Nginx去進行開發(fā)和包裝的，所以在軟負(fù)載這塊兒感覺Nginx才是王道哇。

在硬件廠商里面可以說F5是絕對的領(lǐng)導(dǎo)者，常年處在Gartner象限的領(lǐng)導(dǎo)者地位，F(xiàn)5.Inc收購Nginx可以說是強強聯(lián)合，但是很可惜，目前Nginx在商業(yè)化這塊還沒有摸清楚應(yīng)該要如何去走，這都是后話了。

負(fù)載均衡的算法

負(fù)載均衡有很多的算法，比如常用的有輪詢、比率、最小鏈接、IP哈希、等等，那目前負(fù)載均衡方式支持的最多最靈活的應(yīng)該就是F5了，這個后面會有章節(jié)專門介紹負(fù)載均衡的算法。

當(dāng)然，還有很多的名詞以及場景，這些后面的章節(jié)中將會逐一講解。今天暫且到這里吧。

下一章將介紹負(fù)載均衡的分類以及F5中一些名詞的介紹和解釋，還請持續(xù)關(guān)注喲~

如有錯誤，也還請大家糾正~

歡迎大家關(guān)注我的公眾號，方便大家手機觀看，如有更新也會第一時間推送給大家~

See yo！

Motto: Actions speak louder than words.