後端工程師面試考什麼 — Load Balancer vs. Reverse Proxy vs. API Gateway vs. HAProxy

Posted on Sep 11, 2024 in 後端面試準備 by Amo Chen ‐ 5 min read

覺得我們的內容實用嗎？ MyApollo 電子報讀者募集中！歡迎訂閱電子報!

後端工程師在日常工作或面試中，常常會遇到以下幾種技術與工具：

Load Balancer
Reverse Proxy
API Gateway
HAProxy

這些技術的共通點是它們都處於承載流量的第一線，但在用途上卻各有不同，因此容易產生混淆。

本文將釐清這些技術與工具的差異，以理解它們各自的功能與應用場景，避免常見的誤解。

Load Balancer / 負載平衡器

Load Balancer 如其名，它負責分配來自網路的 requests，將這些 requests 分配到多個伺服器(servers)，除了可以有效分散處理 requests 的壓力，避免單一伺服器負載(load)過高，還能讓後端伺服器群具備彈性擴充能力，提升系統的可擴充性。

Load Balancer 的功能可以由硬體設備提供，稱為 Hardware Load Balancer Device (HLD)，也可以由軟體提供（例如 Nginx ）。

常見的 load balancer 運作原理是 request 會首先發送給 load balancer，然後由 load balancer 將 request 轉發給後端伺服器並接收伺服器的 response，最後 load balancer 再將 response 傳給使用者。由於使用者始終與 load balancer 互動，因此我們可以靈活地擴充後端伺服器的數量，只需調整 load balancer 的設定，即可提升系統處理 request 的能力。

有人可能會疑問「在此架構下，如果 load balancer 被大量 requests, responses 阻塞的話，不就會對系統的可用性與穩定性造成影響？」。

沒有錯，所以 load balancer 還有 1 種稱為 Direct Routing (DR) 的技術，也稱為 Direct Server Return，可以讓後端伺服器直接回應使用者。其原理是 load balancer 透過修改網路封包，將 request 直接轉給後端伺服器，讓後端伺服器能夠直接回應使用者。這種模式相當適合用於影音資料傳輸的情況，但網路設定上也比較複雜一些。

除了前述運作原理之外，也有使用不同運作原理的 load balancer:

DNS (Domain Name System) based load balancing，主要在 DNS 解析域名的階段回應不同 IP 給使用者以進行負載平衡，缺點是 DNS 更新需要較長時間，對於擴充彈性帶來很大的不方便
HTTP redirects，使用 HTTP 重新導向(redirection)進行分配的 load balancer，缺點是使用者端會發出 2 次 request，第 1 次會得到需要重新導向的 response，第 2 次才能取得真正的 response，整體而言回應速度較慢

而談到 Load Balancer 時也多半會需要對分配策略有所了解，常見的分配策略有：

輪詢(Round Robin)，輪流分配 request 給每個伺服器
最少連線數(Least Connection)，將 request 分配給目前連線數最少的伺服器
最快回應時間(Least Response Time)，將 request 分配給回應速度最快的伺服器
IP 雜湊(Hash)，將 IP 位址進行雜湊後分配給特定伺服器，同 IP 會由同 1 個伺服器提供服務
隨機(random)

ref: DesignGurus

不同的分配策略有各自的優缺點與適用的場景，更完整詳細的解說可以參考 Load Balancing Algorithms 1 文。

Load Balancer 設定範例

以下是使用 Nginx 作為 HTTP load balancer 的設定，使用最少連線數分配策略：

http {
    upstream backend {
        least_conn;
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        location / {
            proxy_pass http://backend;
        }
    }
}

從上述設定應該更能明顯體會 load balancer 的運作。

Reverse Proxy / 反向代理伺服器

容易與 load balancer 混淆的大概是 reverse proxy。

原因是 reverse proxy 通常也會同時扮演 load balancer 的角色，例如 Nginx 就同時提供 reverse proxy 與 load balancer 2 種功能可以使用，而且它們在後端系統架構的位置也很相似。

不過 load balancer 專注於分配 requests 給多個伺服器；而 reverse proxy 專注於接收 requests，並根據 requests 的不同（例如根據 HTTP request 的 path），轉給不同的伺服器處理，從以下 Nginx 設定可以感受到其差異，例如 load balancer 並不管 location 的差異：

http {
    upstream backendv1 {
        least_conn;
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        location /api/v1/ {
            proxy_pass http://backendv1;
        }

        location /api/v2/ {
            proxy_pass http://backend3.example.com:8000;
        }
    }
}

畫成圖表示的話：

而且 reverse proxy 還有個特點是能夠進行快取，將特定的 response 快取起來，減少後端伺服器的負擔，並提升 response 的速度，例如下列 Nginx 設定：

http {
    proxy_cache_path  /var/www/cache levels=1:2 keys_zone=one:10m;
    proxy_temp_path /var/www/cache/tmp;

    upstream backendv1 {
        least_conn;
        server backend1.example.com;
        server backend2.example.com;
    }

    server {
        location /api/v1/ {
            proxy_pass http://backendv1;
        }

        location /api/v2/ {
            proxy_pass http://backend3.example.com:8000;
        }

        location /static/ {
           proxy_pass http://static.example.com;
           proxy_cache one;
           proxy_cache_valid  200 302  10m;
           proxy_cache_valid  404      1m;
        }
    }
}

常見問題：正向代理 vs. 反向代理

正向代理伺服器(Forward Proxy)是使用者能夠設定使用的代理伺服器，通常靠近使用者端；而反向代理伺服器(Reverse Proxy)是使用者不能設定使用的，屬於服務後端系統中的一部分。

從使用者的角度來看，使用者是對反向代理伺服器發出 request，然後反向代理伺服器又將 request 轉發給後端伺服器，並接收後端伺服器的 response 之後，再回傳給使用者。

詳見 What is a reverse proxy? | Proxy servers explained。

API Gateway

API Gateway 與 load balancer, reverse proxy 相似，都位於流量第一線。

不過 API Gateway 主要應用於接受各種 API requests，並根據預先定義的規則將請求轉發至指定的伺服器進行處理。API Gateway 通常應用於微服務(microservices)架構，在微服務架構下，會由多個服務(services)協同提供 API 服務，而 API Gateway 則扮演對外的統一窗口，此種架構同樣可以為後端系統帶來彈性。

下圖將 API Gateway 表達很好，可以清楚理解它的作用：