在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 層（Layer 4）網絡均衡器，并在相同的虛擬 IP（VIP）地址提供服務。它們可以是硬件設備，或者像 HAProxy 這樣的軟件均衡器。這意味著 DNS 記錄僅僅指向虛擬 IP 而不再做負載均衡。

4 層均衡器將來自因特網的流量均衡地引導至后端服務器。這通常是基于每個 IP 包的 5 元組的哈希（一個數學函數）完成的：源 IP 地址和目標 IP 地址，以及端口加上協議（如 TCP 或 UDP）。這種方式快速、高效（并且仍然維持了 TCP 的基本屬性），并且不需要均衡器維護每個連接的狀態。
4 層均衡器可以進行健康檢查，并僅僅向那些通過檢查的 web 服務器發送流量。與 DNS 均衡不同的是，如果一個 web 服務器崩潰，將流量重定向到另一個 web 服務器上的延遲很小，盡管現有連接將被重置。
4 層均衡器可以做加權平均，處理不同容量的后端，它為運維人員提供了強大的能力和靈活性，同時在計算能力方面相對便宜。