负载均衡再学习
?
下文，以軟負載均衡（反向代理）方案為背景，討論負載均衡。
負載均衡特點：
負載均衡：暴露給用戶的IP只有一個，如果后端機器故障，進行下線修復后再上線這一過程，前端用戶感覺不到，并且可以根據后端機器的性能差異，調整流量分配權重，科學的分配訪問量。
負載均衡的以上特點，大大提高了應用程序容錯能力。
開源負載均衡nginx、HAProxy 等方案，最大連接數一般有數萬。需要技術人員預估資源，在業務旺季，進行擴容，保證可用性。
開源方案的靈活性同時也帶來了復雜性，這些方案不像專業云平臺有統一標準，需要技術人員首先搭建一個基本可用的系統，然后監視業務運行狀態，自己總結實踐經驗，自己優化改進。
開源方案，需要技術人員自己搭建安全防護方案，這需要學習安全防御技術。成熟的云平臺阿里云、騰訊云都已提供可靠的安全防護服務。
?
負載均衡的層次，TCP 協議和 UDP 協議；HTTP 協議和 HTTPS協議；
負載均衡監聽器，可以監聽負載均衡實例上的四層請求（即OSI網絡協議模型第四層傳輸層），并將這些請求分發至后端服務器進行處理。四層轉發能力需要在具體軟件的配置文件，進行配置。
?
負載均衡端口：負載均衡器對外或對內提供服務時，接收請求的前端端口。用戶可以為下列 TCP 端口執行負載均衡：21（FTP）、25（SMTP）、80（Http）、443（Https），以及 1024-65535等端口。
后端服務器端口：后端服務器接受負載均衡分發流量的端口。在同一個負載均衡中，一個負載均衡端口可以對應多個后端服務器端口。
?
負載均衡運行監管，需要自己實現健康檢查，實時識別后端服務器的運行狀況，自動隔離異常的服務器，保證應用程序的可用性。
騰訊云的四層轉發的健康檢查機制是，由負載均衡器向配置中指定的服務器端口發起訪問請求，如果端口訪問正常則視為后端服務器運行正常，否則視為后端服務器運行異常。對于TCP的業務，使用SYN包進行探測。對于UDP業務，使用ping進行檢查。技術人員自己實現的方案，可以參考騰訊云的思想。
- 響應超時時間： 2-60 秒
- 檢查間隔： 5-300 秒
- 不健康閥值：2-10 次 （健康后端服務器出現此指定次數響應超時后，視為不健康）
- 健康閥值：2-10 次（不健康后端服務器出現此指定次數響應超時后，視為健康）
可參照騰訊云的健康閥值設置，實現自己的負載均衡檢查。
?
負載流量分配
騰訊云四層轉發能力，使用加權輪詢的分流方式，流量經負載均衡器后按權重比例分配到不同后端服務器上。后端服務器的權重默認為10，可設置0-100范圍內的整數。自建負載均衡，也可以參照該實現方法的思想，自己實現負載分配方案。
注意下流量分配的細節
- 當后端服務器權重配置為0時，負載均衡實例將不再往該服務器轉發流量
- 負載均衡實例向后端服務器轉發的流量，將按實際配置的權重比例計算。例如：一個負載均衡實例綁定了2臺后端服務器，若A服務器配置權重為40，B服務器配置權重為60，則兩臺服務器的流量接收比例為2：3
- 當所有后端服務器權重設置值相同時（如默認值10），流量將均勻地轉發至所有后端服務器。例如：一個負載均衡實例綁定了2臺后端服務器，權重均為默認值10，則流量將按50：50的比例進行轉發；若該負載均衡實例新增加了一臺權重設置為默認值10的后端服務器，則流量將按33：33：33的比例進行轉發；若該實例又新增加了一臺權重設置為默認值10的后端服務器則流量將按25：25：25：25的比例進行轉發
- 啟用了會話保持功能后，流量則不會完全按照權重比例轉發
?
-------------------------------------------------------------------------------
轉載自網絡，作者：溫昂展
負載均衡算法
目前，負載均衡算法不管是在學術研究還是在工程實現上都已比較成熟，算法大體可分以下幾種：
- 隨機（random）算法
- 輪詢（round-robin）算法
- 哈希（hash）算法
- 一致性哈希算法
- 靜態權重調度算法
- 動態權重、自適應算法
非自適應類算法不要求從服務節點實時獲得負載的更新，而自適應算法通常需要負載均衡器能感知節點的負載變化動態調整分發策略，提高負載平衡的效果。也因此，兩類算法在實現上架構設計也有較大的差別。
那么節點的負載如何衡量呢? 根據不同類型的系統應用，通常會定義不同的度量方式，如：CPU資源、內存資源、當前進程數、吞吐量、成功率、響應時間等指標都可以作為負載度量的指標，各個指標的重要程度根據實際情況有所不同。
?
負載均衡架構
這里探討的是軟負載均衡技術，一些基于硬負載均衡的架構設計不做具體涉及。軟負載均衡架構大體可以分為：
- 基于客戶端
- 基于DNS
- 基于反向代理
- 基于第三方應用或系統，如：哈雷、TGW、LVS
除了基于客戶端方式，其他架構上實際上都是引入一個均衡服務器做控制或代理，或是返回請求的調度結果，亦或是直接對請求做轉發。結合TAF的設計理念和架構做思考，負載均衡器其實可以放到主控側來實現，但是我認為由于負載均衡策略的復雜性，單是對調度決策數據分析已經非常繁重，因此負載均衡通常還是單獨引入一個接入層（統一接入網關）來實現，比如目前在使用的 TGW、哈雷接入、LVS（四層）、GSLB/LB（七層）、L5、CMLB 等都是此類接入層系統的實現方案。
負載均衡器周期性計算出每個被調機器的權重，再使用高效的配額算法分配各個主調機器的訪問路由，主調機器上的業務進程通過API來取得這些路由，調用結束時通過API來反饋路由的好與壞。
而TAF的實現，我們把重點放在客戶端。
?
內容引用說明
原文章標題：TAF 必修課（七）：負載均衡
原文章地址：https://cloud.tencent.com/developer/article/1005900
?
轉載于:https://www.cnblogs.com/Tpf386/p/8108726.html
總結
- 上一篇： F. 更改apache端口号
- 下一篇： cocos cteator中tiled模