應用程序的可用性從未像今天這樣受到重視,因為我們使用應用程序不僅僅是為了個人或專業的交流,而且應用程序就是業務。
不能持續在線或不穩定的應用程序會失去用戶和相關性,最終變得過時。 事情發生在一瞬間。 由於互聯網永不休眠,每週 24 天、每天 7 小時運行,因此同樣的理念也適用於應用程序。
可擴展性對於做到這一點並確保應用程序可用性至關重要。 負載平衡是確保可用性的最重要組件之一。 許多人仍然認為負載平衡可以通過簡單的腳本來完成。
然而,這種情況並非如此。 僅憑它就可以隨時隨地通過任何設備訪問世界各地的程序。
在這篇文章中,我們將深入研究負載平衡、其算法以及它與微服務的關係等。 讓我們開始!
什麼是負載均衡?
隨著網站或業務應用程序需求的增長,單個服務器很快將無法處理整個負載。 組織將工作負載分配到眾多服務器上以滿足需求。 這種方法稱為“負載平衡”,可防止單個服務器過載,過載可能導致其速度減慢、丟棄請求,甚至崩潰。
負載均衡平均分配網絡流量,避免因資源過載而導致故障。 使用此方法,應用程序、網站、數據庫和其他計算機資源性能更好並且更可用。 它還有助於正確及時地處理用戶請求。
從用戶的角度來看,負載平衡充當客戶端和服務器集合之間看不見的中介,確保連接請求不會被丟棄。 如果在沒有負載平衡的情況下需求變得太大,應用程序、網站、數據庫和在線服務很可能會崩潰。
數十萬個用戶請求可以同時發送到單個高流量網站。 需要多個服務器才能使用所請求的內容(例如文本、圖像、視頻和音頻流)正確填充網頁。 負載平衡通常用於高流量網站服務器場以及 DNS 服務器、數據庫和文件傳輸協議 (FTP) 站點。
如果單個服務器負擔過重,則可能會運行不良甚至崩潰。 負載均衡器通過在一組服務器之間均勻分配用戶請求來減少停機的可能性。 如果組中的一台服務器發生故障,流量將重新路由到組中的其他服務器。 當新服務器添加到服務器池時,負載均衡器會在流量分配過程中自動添加新服務器。
負載均衡如何工作?
它的工作原理如下:
- 當客戶端收到請求(例如通過瀏覽器或應用程序)時,它會嘗試與服務器連接。
- 當負載均衡器收到請求時,它會根據算法(或場)建立的模式將其路由到服務器組中的其中一台服務器。
- 服務器接收連接請求並通過負載均衡器應答客戶端。
- 當負載均衡器收到響應時,它將客戶端的 IP 地址與所選服務器的 IP 地址進行匹配。 隨後,答案隨數據包一起傳輸。
- SSL 卸載是使用安全套接字層加密協議解密數據的過程,因此服務器無需這樣做。
- 重複該過程直到會話結束。
負載均衡方法
為了選擇服務器場中的哪台服務器接收下一個請求,每種負載平衡技術都使用一組標準。 負載均衡有五種典型的方法:
- 循環賽:這是默認方法,它的工作原理就像聽起來一樣。 負載均衡器以輪流模式分發請求,從組中的第一台服務器開始,一直向下到底部,等待再次被調用。 此方法可確保每個服務器處理大致相同數量的連接。
- 加權循環:這種方法為每個服務器分配一個權重(或偏好),該權重通常與其容量成正比。 服務器收到的請求越多,權重就越高。 例如,權重值為 XNUMX 的服務器收到的請求數是權重值為 XNUMX 的服務器接收的請求數的兩倍。
- 粘性會話:這種方法也稱為會話持久性,在會話期間連接某些客戶端和服務器。 為了建立鏈接,負載均衡器使用 cookie 或用戶的 IP 地址來識別用戶屬性。 一旦建立連接,用戶的請求將被定向到同一服務器,直到會話結束。 這優化了網絡資源,同時也改善了用戶體驗。
- 最少連接數:此策略假設所有請求都會導致相同的服務器負擔。 結果,請求數最少的服務器接收下一個請求。
- IP哈希值:該算法根據客戶端和服務器的源和目標 IP 地址生成唯一的哈希密鑰。 該密鑰用於路由請求並允許恢復與同一服務器丟失的連接。
硬件對比軟件負載均衡器
硬件負載均衡器
物理硬件(例如設備)構成硬件負載平衡器。 它們根據現有連接數量、處理器使用情況和服務器性能等因素將流量路由到服務器。 硬件負載平衡器具有專有固件,當新版本和安全修復程序可用時,必須維護和更新該固件。
硬件負載均衡器通常提供更高的性能和控制,以及更廣泛的功能,例如 Kerberos 身份驗證和 SSL 硬件加速,但它們需要一定程度的管理和維護專業知識。 由於硬件負載均衡器的靈活性和可擴展性不如軟件負載均衡器,因此存在過度配置硬件負載均衡器的傾向。
軟件負載均衡器
軟件負載平衡器通常比硬件負載平衡器更容易設置。 它們還更具成本效益和適應性,並且可以很好地與軟件開發環境配合使用。 該軟件方法允許您根據環境的確切要求自定義負載平衡器。 靈活性的提高可能會以花費額外的時間來設置負載均衡器為代價。
與硬件平衡器相比,軟件平衡器為您提供更大的修改和更新靈活性,硬件平衡器採用更封閉的方法。 預打包的虛擬機可用作軟件負載平衡器 (VM)。 虛擬機將為您節省一些設置時間,但它們可能不具備其硬件對應項中可用的所有功能。
簡單的負載均衡實施
我們將使用 Spring Cloud 庫來 構建應用程序 以負載平衡的方式連接到其他應用程序。 在處理遠程服務請求時,我們可以使用任何我們喜歡的技術輕鬆構建負載平衡。 以以下代碼為例。 我們將從基本的服務器應用程序開始。
服務器將只有一個 HTTP 端點,並且將在多個實例中運行。 然後,我們將構建一個使用負載均衡器在多個服務器實例之間分發請求的客戶端應用程序。
服務器
我們從一個基本的開始 春季靴 我們的示例服務器的應用程序:
首先,我們注入一個名為instance_ID的可定制變量。 這有助於我們區分正在運行的眾多實例。 接下來,我們創建一個返回消息和實例 ID 的 HTTP GET 端點。
ID 為 1 的默認實例將在端口 8080 上運行。我們只需添加一些程序參數即可啟動第二個實例:
客戶端
現在讓我們看一下客戶端代碼。 這就是負載均衡器的用武之地,所以讓我們首先將其合併到我們的應用程序中:
接下來,我們開發 ServiceInstanceListSupplier 的實現。 這是負載均衡器中最重要的接口之一。 它指定了我們如何定位可訪問的服務實例。
我們將在示例應用程序中對示例服務器的兩個單獨實例進行硬編碼。 它們在同一系統上運行,但使用不同的端口:
現在創建一個 LoadBalancerConfiguration 類:
此類只有一個用途:它創建一個負載平衡的 WebClient 構建器來發出遠程請求。 我們的註釋使用了該服務的虛構名稱。
這是因為我們很可能無法提前知道運行實例的精確主機名和端口。 因此,我們使用虛構的名稱作為佔位符,框架在選擇正在運行的實例時將替換實際信息。
接下來,讓我們創建一個配置類,用於實例化我們的服務實例供應。 請注意,我們使用與之前相同的別名:
我們現在可以構建真正的客戶端應用程序。 讓我們使用之前的 WebClient bean 向示例服務器發送 10 個查詢:
從輸出中我們可以看到我們正在兩個單獨的實例之間進行負載平衡:
微服務中的負載均衡
Netflix 和 Amazon 等多家公司正在使用微服務架構來將業務應用程序開發為一組鬆散連接的服務。 複雜應用程序的超大規模和持續交付只是轉向這種分佈式、鬆散連接架構的兩個原因。
這些企業的團隊實施了敏捷和 DevOps 策略,以便比傳統方法更快地生產應用程序並降低失敗率。 但是,您必須在分佈式架構的複雜性與應用程序的需求、規模要求和上市時間限制之間取得平衡。
多年來,應用程序交付控制器 (ADC) 對於滿足本地或云中託管的企業應用程序的服務級別要求至關重要。 使用基於微服務的應用程序的客戶端不需要了解提供該應用程序的實例即可獨立地擴展客戶端和微服務。
這正是反向代理或負載均衡器提供的解耦。 同樣,負載均衡是確保微服務能夠處理需求、安全性和可用性的解決方案。
當您將客戶端和基於微服務的應用程序之間的傳統南北負載平衡與東西向部署相結合以實現水平可擴展性時,您將獲得巨大的提升。 目標是維護 IT 所需的安全且受監管的環境,而不犧牲開發敏捷性或 DevOps 自動化 要求。
優點
負載平衡通過提高高流量網站和應用程序以及進行大量查詢的數據庫的資源利用率、數據交付和響應時間來提供各種好處。 負載均衡可確保在高流量場景下快速、正確地滿足用戶請求。
它們使用戶免於處理緩慢的程序和資源。 負載平衡還有助於避免停機並簡化安全性,從而降低公司生產力和收入損失的風險。
- 除了管理流量以實現最佳效率之外,負載平衡還可以根據需要靈活地添加和刪除服務器。 由於維護時流量會被引流到其他服務器,因此在不影響用戶的情況下進行服務器維護也是可行的。
- 負載平衡通過在一組服務器之間分配流量來提供內置冗餘。 如果一台服務器出現故障,您可以立即將負載轉移到其他服務器,從而最大程度地減少對用戶的影響。
- 如果應用程序或網站的使用量增加,如果不進行有效處理,增加的流量可能會降低其性能。 通過負載平衡,您可以添加真實或虛擬服務器來滿足需求,而不會中斷服務。 負載均衡器會在新服務器上線時識別它們,並輕鬆地將它們納入操作中。 這種方法比將網站從負擔過重的服務器遷移到新服務器更可取,後者經常會導致一些停機時間。
結論
負載平衡是當代容錯系統的關鍵組成部分。 我們可以簡單地構建使用各種負載平衡方法將請求分發到多個服務實例的應用程序。 企業必須支持複雜的 IT 系統才能安全地提供應用程序。
跨域微服務配置、部署和維護可能容易出錯、成本高昂且耗時。 IT 應使用與其敏捷和 DevOps 流程兼容的自動化、可見性、分析和編排最佳實踐和技術,以使這些微服務的設置和維護變得更加容易。
發表評論