負載均衡在APP開發中的運用的重要性
在APP開發項目中,服務器架構是關系到整個系統的性能的關鍵因素。無論是自己買的服務器,還是用云服務器,負載均衡都是提高系統性能的主要方式。
如果你是早期的云計算服務提供商,你可以使用一個單獨的客戶 web 服務器,為它分配一個 IP 地址,并配置一個 DNS(域名系統)記錄來將它與一個易讀的名字關聯起來,之后通過 BGP(邊界網關協議)來傳播 IP 地址,這是種在網絡間交換路由信息的標準方式。
在冗余的網絡路徑上分發流量,在不可用的基礎設施周圍進行路由來提高可用性(會導致不對稱路由等現象),這些從本質上講并不是負載均衡。
隨著客戶服務流量的增長,業務方希望獲得更高的可用性。你添加了另一個具有公網 IP 地址的 web 服務器,并更新了 DNS 記錄來將用戶引導到這兩個 web 服務器(希望稍微公平一些)。直到某一個 web 服務器意外宕機前,這種方法都是可行的。假設你快速檢測到故障,可以通過更新 DNS 配置(手動方式或使用軟件)來停止引用損壞的服務器。
遺憾的是,由于 DNS 記錄是有緩存的,這些緩存記錄可能會在客戶端或者 DNS 層次結構中的其他名稱服務器中,在它們過期之前,大約有 50% 的請求仍然可能失敗。DNS 記錄的 TTL(time to live,生存時間)通常為幾分鐘或更長,因此這會對系統的可用性造成重大影響。
更糟糕的是一些客戶端完全忽略了 TTL,所以一些請求將在一段時間內被定向到已經宕機的 web 服務器上。設置非常短的 DNS TTL 也不是什么好主意;這意味著 DNS 服務的負載增加,延遲增加,因為客戶端不得不更加頻繁地執行 DNS 查找。如果你的 DNS 服務不可用,那么使用更短的 TTL 訪問服務將更快地降級,因為緩存服務 IP 地址的客戶端更少。
4 層均衡器將來自因特網的流量均衡地引導至后端服務器。這通常是基于每個 IP 包的 5 元組的哈希(一個數學函數)完成的:源 IP 地址和目標 IP 地址,以及端口加上協議(如 TCP 或 UDP)。這種方式快速、高效(并且仍然維持了 TCP 的基本屬性),并且不需要均衡器維護每個連接的狀態。
4 層均衡器可以進行健康檢查,并僅僅向那些通過檢查的 web 服務器發送流量。與 DNS 均衡不同的是,如果一個 web 服務器崩潰,將流量重定向到另一個 web 服務器上的延遲很小,盡管現有連接將被重置。
推薦文章
2025-01-18
2024-11-28
2024-11-09
2024-10-25
2024-06-25
2024-01-04
2023-11-06
2023-10-30
2023-10-13
2023-10-10
穩定
產品高可用性高并發貼心
項目群及時溝通專業
產品經理1v1支持快速
MVP模式小步快跑承諾
我們選擇聲譽堅持
10年專注高端品質開發