|
新聞中心
當(dāng)前位置：網(wǎng)站首頁 > 新聞中心
使用負載均衡的常見誤區(qū)及建議
1、優(yōu)先使用無狀態(tài)服務(wù)
有狀態(tài)服務(wù)和無狀態(tài)服務(wù)，原本是各有優(yōu)勢，并沒有明顯的優(yōu)劣之分，但是在大集群、服務(wù)化的場景下，無狀態(tài)服務(wù)則更有優(yōu)勢。
因為有狀態(tài)服務(wù)在服務(wù)架構(gòu)較為簡單時雖然有易開發(fā)，高并發(fā)等優(yōu)勢，但隨著業(yè)務(wù)規(guī)模的擴大，也會造成異?；謴?fù)困難、難以并行擴展等問題。而在這種場景下，無狀態(tài)服務(wù)在服務(wù)管理、并行擴展方面有著先天的優(yōu)勢。
一般來講，使用負載均衡，大多是服務(wù)規(guī)模較大，業(yè)務(wù)負載的場景，因此更推薦使用無狀態(tài)化的服務(wù)。
2、忽視健康檢查配置！
健康檢查是負載均衡服務(wù)的重要功能之一，也是服務(wù)判斷后端節(jié)點是否存活的重要標準（很多場景下甚至是唯一標準）。不僅僅會影響到顯示的狀態(tài)，還會影響到用戶的服務(wù)質(zhì)量，甚至造成整個服務(wù)異常。下面舉兩個例子：
誤區(qū)1：健康檢查判斷異常參數(shù)過于敏感，在系統(tǒng)壓力較大時錯誤判斷而移除正常的節(jié)點，導(dǎo)致剩下節(jié)點壓力增大，從而繼續(xù)發(fā)出移除操作，直到全部節(jié)點移除，系統(tǒng)雪崩。
應(yīng)對之策：在線上壓力較大，偶現(xiàn)超時的場景下，建議采用快速拉起，緩慢宕機的策略。通過適當(dāng)拉長節(jié)點異常宕機時周期，減少錯誤判斷的概率，而在服務(wù)正常時快速接入服務(wù)，緩解負載。
誤區(qū)2：健康檢查宕機參數(shù)設(shè)置時間過長，結(jié)果在節(jié)點宕機時無法快速拉起，在異常時影響到了用戶訪問。
應(yīng)對之策：在線上壓力較小、健康檢查接口響應(yīng)正常的情況下，可以考慮縮短宕機時間，這樣在異常時可以快速移除異常節(jié)點，減少對用戶的影響。
因此，健康檢查參數(shù)并沒有一個固定的原則，關(guān)鍵還是要看業(yè)務(wù)本身的特點，以及對業(yè)務(wù)來說，最重要的是什么：是業(yè)務(wù)穩(wěn)定，還是用戶體驗？
3、接入負載均衡無法保障高可用
有一個常見誤區(qū)就是認為服務(wù)接入負載均衡就算高可用了。而事實上實際服務(wù)的高可用性是需要通盤考慮的事情，比如全鏈路移除單點，服務(wù)本身對于異常的處理等。
因此說，接入負載均衡僅僅是保證了接入點的高可用（如果掛單點那接入都不是高可用的），真正要實現(xiàn)高可用還需要全局保證，負載均衡只是構(gòu)筑服務(wù)高可用的一個工具，而不是全部。
4、接入負載均衡后并不會實現(xiàn)業(yè)務(wù)加速
負載均衡是一個高性能的轉(zhuǎn)發(fā)服務(wù)，但是對于單次請求來說，無法做到性能加速。
如果你本來的請求要 100ms返回，使用負載均衡之后也不會把你的請求縮短到 10ms。
而且從理論上說，無論任何形式的負載均衡，都只會增長調(diào)用鏈而不是縮短（一些軟負載均衡，如 DNS，Service的 Iptables不會增加調(diào)用鏈本身，但是也會加入額外操作）。因此，對于單個請求，結(jié)果往往是變慢而不是加速（一般負載均衡服務(wù)增加的成本是微乎其微的 ms以內(nèi)，應(yīng)用完全感知不到）。
負載均衡對性能的提升，是通過分擔(dān)負載帶來的并行擴展能力從而提升服務(wù)的穩(wěn)定性。而由于業(yè)務(wù)并行擴展，造成單臺壓力變小，從而提升服務(wù)的整體性能。
另外，由于負載均衡服務(wù)往往有更可靠的接入端（BGP網(wǎng)絡(luò)），更高效的轉(zhuǎn)發(fā)設(shè)施（專用轉(zhuǎn)發(fā)設(shè)備和鏈路），更好的優(yōu)化，一般性能還是遠遠優(yōu)于自己搭建的轉(zhuǎn)發(fā)服務(wù)。因此很多場景是會有更好的性能表現(xiàn)。
|
