阿里slb做為k8s的負(fù)載均衡的限制

如果在本地搭建，我們可以使用haproxy+keepalived方式輕松實(shí)現(xiàn)k8s中的負(fù)載均衡，但是阿里的ecs不能使用keepalived,所以我們被迫只能使用阿里的 slb了。

成都創(chuàng)新互聯(lián)專業(yè)提供成都主機(jī)托管四川主機(jī)托管成都服務(wù)器托管四川服務(wù)器托管，支持按月付款！我們的承諾：貴族品質(zhì)、平民價(jià)格，機(jī)房位于中國電信/網(wǎng)通/移動(dòng)機(jī)房，成都服務(wù)器托管服務(wù)有保障！

既然keepalived的方式不能使用，那我們就使用阿里的slb進(jìn)行負(fù)載均衡唄，由于該負(fù)載均衡不需要被外部訪問，只提供對(duì)k8s集群節(jié)點(diǎn)之間的訪問,所以我們就使用私網(wǎng)的slb。

[圖片上傳失敗...(image-b02d7-1604545387128)]

我們保證該slb和k8s集群節(jié)點(diǎn)的node屬于同一個(gè)局域網(wǎng)內(nèi)，具體配置如下

第一步就是監(jiān)聽該slb的6443端口，該端口后端的服務(wù)器組分別是3臺(tái)ecs的6443端口(apiserver服務(wù))。接著我們可以 在master1節(jié)點(diǎn) 上執(zhí)行如下命令

由于后端服務(wù)器組的 apiserver 都尚未運(yùn)行，預(yù)期會(huì)出現(xiàn)一個(gè)連接拒絕錯(cuò)誤。然而超時(shí)意味著負(fù)載均衡器不能和控制平面節(jié)點(diǎn)通信。 如果發(fā)生超時(shí)，請(qǐng)重新配置負(fù)載均衡器與控制平面節(jié)點(diǎn)進(jìn)行通信。

我們?cè)趍aster1節(jié)點(diǎn)上創(chuàng)建kubeadm-config.yaml文件，用于初始化控制平面節(jié)點(diǎn)，如下。

接著我們?cè)趍aster1節(jié)點(diǎn)上執(zhí)行如下命令初始化

最后結(jié)果如下

看上面的日志好像是kubelet的問題。我們先確認(rèn)kubelet是否運(yùn)行,發(fā)現(xiàn)處于running狀態(tài)。

接著查看kubelet的日志

發(fā)現(xiàn)一個(gè)奇怪的問題，提示timeout。

接著我們?cè)趍aster1節(jié)點(diǎn)上首先測(cè)試本地的6443端口是否已經(jīng)啟用

看到master1節(jié)點(diǎn)的6443端口已經(jīng)被占用，接著我們?cè)?master1 節(jié)點(diǎn)測(cè)試slb的6443端口服務(wù)，按理說master1節(jié)點(diǎn)的6443服務(wù)已經(jīng)啟用，那么slb的6443服務(wù)也應(yīng)該是可用可連通的。

遺憾的是slb的6443端口并沒有連通，我們?cè)趍aster2,master3節(jié)點(diǎn)上分別連接slb的6443端口，發(fā)現(xiàn)都timeout。 我們又找了同一局域網(wǎng)內(nèi)的另一臺(tái)ecs，該ecs不屬于slb的后端服務(wù)器，在該ecs上卻能連接slb的6443端口 ，現(xiàn)在問題找到了：

帶著這個(gè)疑問我們提了阿里工單，客服最后給出結(jié)論。

私網(wǎng)的slb是不可以使用了，我們換成公網(wǎng)slb之后重新按照上述流傳執(zhí)行一遍，最后初始化控制平面節(jié)點(diǎn)成功。

初始化之前slb的6443端口負(fù)載的后端服務(wù)器組的6443服務(wù)肯定都沒有啟動(dòng)。

初始化開始后先在本地拉取相關(guān)鏡像，隨后apiserver等服務(wù)啟動(dòng)起來，也就是本地的6443服務(wù)已經(jīng)啟動(dòng)。

接著驗(yàn)證slb的6443的連通性，由于master1節(jié)點(diǎn)的6443服務(wù)已經(jīng)啟動(dòng)，那么slb的后端組在健康檢查中就會(huì)發(fā)現(xiàn)有master1節(jié)點(diǎn)6443端口一起啟動(dòng)，所以slb的6443端口服務(wù)也就正常啟動(dòng)了。

通過上面的描述，在 控制平面節(jié)點(diǎn) 上大致需要滿足以下倆點(diǎn)才能初始化成功

優(yōu)點(diǎn)：可以將kubeconfig文件復(fù)制到你筆記本電腦上，進(jìn)而可以在你本地訪問集群，也正是由于這種方式可能造成安全泄漏的問題。

缺點(diǎn)：apiserver暴露的ip是公網(wǎng)ip，一是各個(gè)節(jié)點(diǎn)之間溝通的效率變低，二是具有安全性問題。

如果公司非得使用私網(wǎng)的話，我們可以采取這種方式，大概拓?fù)鋱D如下

最上層是一個(gè)私網(wǎng)的slb,該slb的后端服務(wù)器組為倆個(gè)haproxy,使用倆臺(tái)haproxy可以避免haproxy的單點(diǎn)故障，haproxy的后端服務(wù)器為3臺(tái)k8s的master節(jié)點(diǎn)。

估計(jì)看到這里有人會(huì)有疑問，上面介紹的私網(wǎng)slb方式會(huì)導(dǎo)致四層監(jiān)聽的后端服務(wù)器無法訪問私網(wǎng)SLB問題，那么該種方式就不會(huì)有這個(gè)問題嗎？我們帶著疑問進(jìn)行測(cè)試。

我們準(zhǔn)備6臺(tái)ecs,配置如下

slb監(jiān)聽6443端口，該端口的后端服務(wù)器組為倆臺(tái)haproxy并監(jiān)聽8888端口。

haproxy監(jiān)聽8888端口，該端口的后端服務(wù)器組為3臺(tái)控制平面節(jié)點(diǎn)并監(jiān)聽6443端口,haproxy.cfg文件如下。

我們使用haproxy:1.7鏡像，在倆臺(tái)haproxy所在節(jié)點(diǎn)分別執(zhí)行如下操作：

kubeadm-config文件中controlPlaneEndpoint參數(shù)應(yīng)為私網(wǎng)slb+6443端口，配置文件如下

執(zhí)行初始化，發(fā)現(xiàn)可以初始化成功

以下所有測(cè)試在 master1 節(jié)點(diǎn)上測(cè)試

我們首先測(cè)試master1節(jié)點(diǎn)的apserver服務(wù)，6443端口是否已經(jīng)被占用

master1節(jié)點(diǎn)的6443端口顯示已經(jīng)被占用，接著我們測(cè)試haproxy節(jié)點(diǎn)的8888端口是否連通

顯示haproxy的8888端口已經(jīng)連通，接著測(cè)試slb的6443端口是否被占用,發(fā)現(xiàn)可以連通

到此說明我們的3層架構(gòu)都已經(jīng)連通,說明此方案是可以執(zhí)行的。

之前提的那個(gè)疑問我們現(xiàn)在得到了答案。 但有一點(diǎn)是需要特別注意的

優(yōu)點(diǎn)：由于中間多了一層haproxy，所以巧妙的解決了私網(wǎng)slb四層監(jiān)聽的后端服務(wù)器無法訪問私網(wǎng)SLB問題。

缺點(diǎn)：很顯而易見了，中間多了一層haproxy的轉(zhuǎn)發(fā)代理，而且也增加了成本。

現(xiàn)在大概有倆中方式可以實(shí)現(xiàn)k8s的高可用，一種是使用公網(wǎng)slb的方式，另一種是使用私網(wǎng)+haproxy+node的方式，這倆中方式各有優(yōu)缺點(diǎn)，結(jié)合自己的實(shí)際情況選擇適合的方案。

常見的負(fù)載均衡技術(shù)

四層負(fù)責(zé)均衡：主要是指通過判斷報(bào)文的IP地址和端口并通過一定的負(fù)載均衡算法來決定轉(zhuǎn)發(fā)到哪個(gè)指定目標(biāo)，主要工作在OSI模型的第四層。四層負(fù)載均衡對(duì)數(shù)據(jù)包只是起一個(gè)數(shù)據(jù)轉(zhuǎn)發(fā)的作用，并不會(huì)干預(yù)客戶端與服務(wù)器之間應(yīng)用層的通信（如：三次握手等）。所以能對(duì)數(shù)據(jù)所進(jìn)行的操作也就很少，但相對(duì)于七層負(fù)載均衡來講效率會(huì)高上很多

七層負(fù)載均衡：也被稱為“內(nèi)容交換”，指的是負(fù)載均衡設(shè)備通過報(bào)文中的應(yīng)用層信息(URL、HTTP頭部等信息)和負(fù)載均衡算法，選擇到達(dá)目的的內(nèi)部服務(wù)器。七層負(fù)載均衡可以“智能化”地篩選報(bào)文中 應(yīng)用層信息，然后根據(jù)不同的信息進(jìn)行特定的負(fù)載均衡調(diào)度。這種方式提升了應(yīng)用系統(tǒng)在網(wǎng)絡(luò)層上的靈活性，另外也在一定程度上提升了后端系統(tǒng)的安全性。因?yàn)橄窬W(wǎng)絡(luò)常見的DoS攻擊，這些攻擊在七層負(fù)載均衡的環(huán)境下通常都在負(fù)載均衡設(shè)備上就截止了，不會(huì)影響到后臺(tái)服務(wù)器的正常運(yùn)行。

前網(wǎng)絡(luò)中常見的負(fù)載均衡主要分為硬件負(fù)載均衡和軟件負(fù)載均衡。硬件負(fù)載均衡比較知名的產(chǎn)品有F5 Big-IP、Cirtix Netscaler等等。而軟件負(fù)載均衡就有著眾多的開源項(xiàng)目，常見的有Haproxy、nginx、lvs等。

Haproxy：

lvs:

nginx:

Haproxy可以做代理服務(wù)相對(duì)于nginx而言有很多相同之處，統(tǒng)一可以基于mode tcp進(jìn)行四層代理也可以基于mode http進(jìn)行七層代理，但不同的是其無法使用location和if等進(jìn)行匹配判斷。突出優(yōu)勢(shì)在于有會(huì)話綁定，web管理界面，狀態(tài)統(tǒng)計(jì)非常詳細(xì)。官方推薦只啟用一個(gè)進(jìn)程，相對(duì)于nginx多進(jìn)程架構(gòu)工作并不理想，更多的線程可能會(huì)受到系統(tǒng)內(nèi)存的一些限制。

程序環(huán)境：

主程序：/usr/sbin/haproxy

主配置文件：/etc/haproxy/haproxy.cfg

Unit file：/usr/lib/systemd/system/haproxy.service

查看配置文件

重要的幾個(gè)參數(shù)，及性能調(diào)優(yōu)，多數(shù)無需修改

發(fā)現(xiàn)日志發(fā)送給本機(jī)rsyslog的local2的facility，而本機(jī)的rsyslog里并沒有定義，需要我們自己去配置

所以vim /etc/rsyslog.conf添加一段將local2的所有信息記錄在對(duì)應(yīng)日志文件中

由于HAProxy可以工作在七層模型下，因此，要實(shí)現(xiàn)HAProxy的強(qiáng)大功能，一定要使用強(qiáng)大靈活的ACL規(guī)則，通過ACL規(guī)則可以實(shí)現(xiàn)基于HAProxy的智能負(fù)載均衡系統(tǒng)。HAProxy通過ACL規(guī)則完成兩種主要的功能，分別是：

1）通過設(shè)置的ACL規(guī)則檢查客戶端請(qǐng)求是否合法。如果符合ACL規(guī)則要求，那么將放行；如果不符合規(guī)則，則直接中斷請(qǐng)求。

2）符合ACL規(guī)則要求的請(qǐng)求將被提交到后端的backend服務(wù)器集群，進(jìn)而實(shí)現(xiàn)基于ACL規(guī)則的負(fù)載均衡。HAProxy中的ACL規(guī)則經(jīng)常使用在frontend段中，使用方法如下：

acl 自定義的acl 名稱 acl 方法 -i [ 匹配的路徑或文件] 其中：

·acl：是一個(gè)關(guān)鍵字，表示定義ACL規(guī)則的開始。后面需要跟上自定義的ACL名稱。

·acl方法：這個(gè)字段用來定義實(shí)現(xiàn)ACL的方法，HAProxy定義了很多ACL方法，經(jīng)常使用的方法有hdr_reg（host）、hdr_dom（host）、hdr_beg（host）、url_sub、url_dir、path_beg、path_end等。

·-i：表示不區(qū)分大小寫，后面需要跟上匹配的路徑或文件或正則表達(dá)式。與ACL規(guī)則一起使用的HAProxy參數(shù)還有use_backend，use_backend后面需要跟上一個(gè)backend實(shí)例名，表示在滿足ACL規(guī)則后去請(qǐng)求哪個(gè)backend實(shí)例，與use_backend對(duì)應(yīng)的還有default_backend參數(shù)，它表示在沒有滿足ACL條件的時(shí)候默認(rèn)使用哪個(gè)后端

這些例子定義了www_policy、bbs_policy、url_policy三個(gè)ACL規(guī)則，第一條規(guī)則表示如果客戶端以 或 z點(diǎn)吸煙 開頭的域名發(fā)送請(qǐng)求時(shí)，則此規(guī)則返回true，同理第二條規(guī)則表示如果客戶端通過 bbs.z點(diǎn)吸煙 域名發(fā)送請(qǐng)求時(shí)，則此規(guī)則返回true，而第三條規(guī)則表示如果客戶端在請(qǐng)求的URL中包含“buy_sid=”字符串時(shí)，則此規(guī)則返回true。

第四、第五、第六條規(guī)則定義了當(dāng)www_policy、bbs_policy、url_policy三個(gè)ACL規(guī)則返回true時(shí)要調(diào)度到哪個(gè)后端backend，例如，當(dāng)用戶的請(qǐng)求滿足www_policy規(guī)則時(shí)，那么HAProxy會(huì)將用戶的請(qǐng)求直接發(fā)往名為server_www的后端backend，其他以此類推。而當(dāng)用戶的請(qǐng)求不滿足任何一個(gè)ACL規(guī)則時(shí)，HAProxy就會(huì)把請(qǐng)求發(fā)往由default_backend選項(xiàng)指定的server_cache這個(gè)后端backend。

與上面的例子類似，本例中也定義了url_static、host_www和host_static三個(gè)ACL規(guī)則，其中，第一條規(guī)則通過path_end參數(shù)定義了如果客戶端在請(qǐng)求的URL中以.gif、.png、.jpg、.css或.js結(jié)尾時(shí)返回true，第二條規(guī)則通過hdr_beg（host）參數(shù)定義了如果客戶端以www開頭的域名發(fā)送請(qǐng)求時(shí)則返回true，同理，第三條規(guī)則也是通過hdr_beg（host）參數(shù)定義了如果客戶端以img.、video.、download.或ftp.開頭的域名發(fā)送請(qǐng)求時(shí)則返回true。

第四、第五條規(guī)則定義了當(dāng)滿足ACL規(guī)則后要調(diào)度到哪個(gè)后端backend，例如，當(dāng)用戶的請(qǐng)求同時(shí)滿足host_static規(guī)則與url_static規(guī)則，或同時(shí)滿足host_www和url_static規(guī)則時(shí)，那么會(huì)將用戶請(qǐng)求直接發(fā)往名為static的后端backend，如果用戶請(qǐng)求滿足host_www規(guī)則，那么請(qǐng)求將被調(diào)度到名為www的后端backend，如果不滿足所有規(guī)則，那么將用戶請(qǐng)求默認(rèn)調(diào)度到名為server_cache的這個(gè)后端backend。

log：全局的日志配置，local0是日志設(shè)備，info表示日志級(jí)別。其中日志級(jí)別有err、warning、info、debug4種可選。這個(gè)配置表示使用127.0.0.1上的rsyslog服務(wù)中的local0日志設(shè)備，記錄日志等級(jí)為info。

maxconn：設(shè)定每個(gè)HAProxy進(jìn)程可接受的最大并發(fā)連接數(shù)，此選項(xiàng)等同于Linux命令行選項(xiàng)“ulimit -n”。

user/group：設(shè)置運(yùn)行HAProxy進(jìn)程的用戶和組，也可使用用戶和組的uid和gid值來替代。

daemon：設(shè)置HAProxy進(jìn)程進(jìn)入后臺(tái)運(yùn)行。這是推薦的運(yùn)行模式。

nbproc：設(shè)置HAProxy啟動(dòng)時(shí)可創(chuàng)建的進(jìn)程數(shù)，此參數(shù)要求將HAProxy運(yùn)行模式設(shè)置為daemon，默認(rèn)只啟動(dòng)一個(gè)進(jìn)程。該值的設(shè)置應(yīng)該小于服務(wù)器的CPU核數(shù)。創(chuàng)建多個(gè)進(jìn)程，能夠減少每個(gè)進(jìn)程的任務(wù)隊(duì)列，但是過多的進(jìn)程可能會(huì)導(dǎo)致進(jìn)程崩潰。

pidfile：指定HAProxy進(jìn)程的pid文件。啟動(dòng)進(jìn)程的用戶必須有訪問此文件的權(quán)限。

mode：設(shè)置HAProxy實(shí)例默認(rèn)的運(yùn)行模式，有tcp、http、health三個(gè)可選值。

retries：設(shè)置連接后端服務(wù)器的失敗重試次數(shù)，如果連接失敗的次數(shù)超過這里設(shè)置的值，HAProxy會(huì)將對(duì)應(yīng)的后端服務(wù)器標(biāo)記為不可用。此參數(shù)也可在后面部分進(jìn)行設(shè)置。

timeout connect：設(shè)置成功連接到一臺(tái)服務(wù)器的最長等待時(shí)間，默認(rèn)單位是毫秒，但也可以使用其他的時(shí)間單位后綴。

timeout client：設(shè)置連接客戶端發(fā)送數(shù)據(jù)時(shí)最長等待時(shí)間，默認(rèn)單位是毫秒，也可以使用其他的時(shí)間單位后綴。

timeout server：設(shè)置服務(wù)器端回應(yīng)客戶端數(shù)據(jù)發(fā)送的最長等待時(shí)間，默認(rèn)單位是毫秒，也可以使用其他的時(shí)間單位后綴。

timeout check：設(shè)置對(duì)后端服務(wù)器的檢測(cè)超時(shí)時(shí)間，默認(rèn)單位是毫秒，也可以使用其他的時(shí)間單位后綴。

bind：此選項(xiàng)只能在frontend和listen部分進(jìn)行定義，用于定義一個(gè)或幾個(gè)監(jiān)聽的套接字。bind的使用格式為： bind [address:port_range] interface interface其可以為主機(jī)名或IP地址，如果將其設(shè)置為“*”或“0.0.0.0”，將監(jiān)聽當(dāng)前系統(tǒng)的所有IPv4地址。port_range可以是一個(gè)特定的TCP端口，也可是一個(gè)端口范圍，小于1024的端口需要有特定權(quán)限的用戶才能使用。interface為可選選項(xiàng)，用來指定網(wǎng)絡(luò)接口的名稱，只能在Linux系統(tǒng)上使用。

option httplog：在默認(rèn)情況下，HAProxy日志是不記錄HTTP請(qǐng)求的，這樣很不方便HAProxy問題的排查與監(jiān)控。通過此選項(xiàng)可以啟用日志記錄HTTP請(qǐng)求。

option forwardfor：如果后端服務(wù)器需要獲得客戶端的真實(shí)IP，就需要配置此參數(shù)。由于HAProxy工作于反向代理模式，因此發(fā)往后端真實(shí)服務(wù)器的請(qǐng)求中的客戶端IP均為HAProxy主機(jī)的IP，而非真正訪問客戶端的地址，這就導(dǎo)致真實(shí)服務(wù)器端無法記錄客戶端真正請(qǐng)求來源的IP，而X-Forwarded-For則可用于解決此問題。通過使用forwardfor選項(xiàng)，HAProxy就可以向每個(gè)發(fā)往后端真實(shí)服務(wù)器的請(qǐng)求添加X-Forwarded-For記錄，這樣后端真實(shí)服務(wù)器日志可以通過“X-Forwarded-For”信息來記錄客戶端來源IP。

option httpclose：此選項(xiàng)表示在客戶端和服務(wù)器端完成一次連接請(qǐng)求后，HAProxy將主動(dòng)關(guān)閉此TCP連接。這是對(duì)性能非常有幫助的一個(gè)參數(shù)。

log global：表示使用全局的日志配置，這里的global表示引用在HAProxy配置文件global部分中定義的log選項(xiàng)配置格式。

default_backend：指定默認(rèn)的后端服務(wù)器池，也就是指定一組后端真實(shí)服務(wù)器，而這些真實(shí)服務(wù)器組將在backend段進(jìn)行定義。這里的htmpool就是一個(gè)后端服務(wù)器組。

option redispatch：此參數(shù)用于cookie保持的環(huán)境中。在默認(rèn)情況下，HAProxy會(huì)將其請(qǐng)求的后端服務(wù)器的serverID插入cookie中，以保證會(huì)話的session持久性。而如果后端的服務(wù)器出現(xiàn)故障，客戶端的cookie是不會(huì)刷新的，這就會(huì)出現(xiàn)問題。此時(shí)，如果設(shè)置此參數(shù)，就會(huì)將客戶的請(qǐng)求強(qiáng)制定向到另外一臺(tái)健康的后端服務(wù)器上，以保證服務(wù)正常。

option abortonclose：如果設(shè)置了此參數(shù)，可以在服務(wù)器負(fù)載很高的情況下，自動(dòng)結(jié)束當(dāng)前隊(duì)列中處理時(shí)間比較長的連接。

-balance：此關(guān)鍵字用來定義負(fù)載均衡算法。目前HAProxy支持多種負(fù)載均衡算法，常用的有如下幾種：

cookie：表示允許向cookie插入SERVERID，每臺(tái)服務(wù)器的SERVERID可在下面的server關(guān)鍵字中使用cookie關(guān)鍵字定義。

option httpchk：此選項(xiàng)表示啟用HTTP的服務(wù)狀態(tài)檢測(cè)功能。HAProxy作為一個(gè)專業(yè)的負(fù)載均衡器，它支持對(duì)backend部分指定的后端服務(wù)節(jié)點(diǎn)的健康檢查，以保證在后端backend中某個(gè)節(jié)點(diǎn)不能服務(wù)時(shí)，把從frotend端進(jìn)來的客戶端請(qǐng)求分配至backend中其他健康節(jié)點(diǎn)上，從而保證整體服務(wù)的可用性。

option httpchk的用法如下： option httpchk method uri version 其中，各個(gè)參數(shù)的含義如下：

check：表示啟用對(duì)此后端服務(wù)器執(zhí)行健康狀態(tài)檢查。

inter：設(shè)置健康狀態(tài)檢查的時(shí)間間隔，單位為毫秒。

rise：設(shè)置從故障狀態(tài)轉(zhuǎn)換至正常狀態(tài)需要成功檢查的次數(shù)，例如，“rise 2”表示2次檢查正確就認(rèn)為此服務(wù)器可用。

fall：設(shè)置后端服務(wù)器從正常狀態(tài)轉(zhuǎn)換為不可用狀態(tài)需要檢查的次數(shù)，例如，“fall 3”表示3次檢查失敗就認(rèn)為此服務(wù)器不可用。

cookie：為指定的后端服務(wù)器設(shè)定cookie值，此處指定的值將在請(qǐng)求入站時(shí)被檢查，第一次為此值挑選的后端服務(wù)器將在后續(xù)的請(qǐng)求中一直被選中，其目的在于實(shí)現(xiàn)持久連接的功能。上面的“cookie server1”表示web1的serverid為server1。同理，“cookie server2”表示web2的serverid為server2。

weight：設(shè)置后端真實(shí)服務(wù)器的權(quán)重，默認(rèn)為1，最大值為256。設(shè)置為0表示不參與負(fù)載均衡。

backup：設(shè)置后端真實(shí)服務(wù)器的備份服務(wù)器，僅僅在后端所有真實(shí)服務(wù)器均不可用的情況下才啟用。

用nginx反代后端的兩臺(tái)tomcat主機(jī)，做動(dòng)靜分離，如果是jsp結(jié)尾的就發(fā)往后端，否則就交給nginx處理。

在兩臺(tái)tomcat主機(jī)上創(chuàng)建應(yīng)用

nginx配置

則動(dòng)靜分離就實(shí)現(xiàn)了，并且我們還基于uri實(shí)現(xiàn)了會(huì)話粘性

服務(wù)器負(fù)載均衡的作用

隨著網(wǎng)站、應(yīng)用訪問量的增加，一臺(tái)服務(wù)器租用已經(jīng)不能滿足應(yīng)用的需求，而需要多臺(tái)服務(wù)器集群，這時(shí)就會(huì)用到負(fù)載均衡，那么負(fù)載均衡優(yōu)點(diǎn)是什么呢呢，今天南昌壹基比小小喻下面為大家講解一下：

服務(wù)器負(fù)載均衡有哪些優(yōu)點(diǎn)：

? 負(fù)載均衡優(yōu)化了訪問請(qǐng)求在服務(wù)器組之間的分配，消除了服務(wù)器之間的負(fù)載不平衡，從而提高了系統(tǒng)的反應(yīng)速度與總體性能；

? 負(fù)載均衡可以對(duì)服務(wù)器的運(yùn)行狀況進(jìn)行監(jiān)控，及時(shí)發(fā)現(xiàn)運(yùn)行異常的服務(wù)器，并將訪問請(qǐng)求轉(zhuǎn)移到其它可以正常工作的服務(wù)器上，從而提高服務(wù)器組的可靠性采用了負(fù)均衡器器以后，可以根據(jù)業(yè)務(wù)量的發(fā)展情況靈活增加服務(wù)器，系統(tǒng)的擴(kuò)展能力得到提高，同時(shí)簡化了管理。

負(fù)載均衡器有多種多樣的形式，除了作為獨(dú)立意義上的負(fù)載均衡器外，有些負(fù)載均衡器集成在交換設(shè)備中，置于服務(wù)器與Internet鏈接之間，有些則以兩塊網(wǎng)絡(luò)適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到后端服務(wù)器群的內(nèi)部網(wǎng)絡(luò)上。

一般而言，硬件負(fù)載均衡在功能、性能上優(yōu)于軟件方式，不過成本昂貴。當(dāng)Web服務(wù)器為圖像服務(wù)、SSL（安全套接層）會(huì)話或數(shù)據(jù)庫事務(wù)而進(jìn)行優(yōu)化時(shí)，負(fù)載均衡器可以體現(xiàn)特別的價(jià)值。

當(dāng)需要進(jìn)行服務(wù)器升級(jí)或系統(tǒng)維護(hù)時(shí)，保證穩(wěn)定的服務(wù)器退出服務(wù)以避免服務(wù)中斷。當(dāng)選定某臺(tái)服務(wù)器要退出服務(wù)后，將不會(huì)將任何新的用戶分配到該服務(wù)器。但是，它可以要該服務(wù)器完成對(duì)當(dāng)前用戶的服務(wù)。從而保證了無中斷的優(yōu)質(zhì)服務(wù)，并且簡化了服務(wù)器群的管理。

智能的服務(wù)器服務(wù)恢復(fù)：

將重新啟動(dòng)的服務(wù)器應(yīng)用到服務(wù)中時(shí)，避免新服務(wù)器因突然出現(xiàn)的流量沖擊導(dǎo)致系統(tǒng)故障是非常重要的。所以，在將新服務(wù)器引入服務(wù)器群時(shí)，將逐漸地增加分配到該服務(wù)器的流量，直至達(dá)到其完全的處理能力。從而不僅保證用戶在服務(wù)器退出服務(wù)時(shí)，同時(shí)還保證服務(wù)器在啟動(dòng)期間以及應(yīng)用程序開始時(shí)，均能獲得不間斷服務(wù)。