Load Balancer 的主要作用是為多個后端服務提供負載均衡功能，依據不同的負載均衡算法讓這些服務可以分攤流量。Load Balancer 的歷史非常悠久，從演進路徑上看大致可以分為以下這幾個階段：

• 第一階段：這一階段的 Load Balancer 通常由硬件設備組成，具有高性能、高可靠性的特點，但靈活性較差，價格昂貴。比較典型的是 F5 這種基于硬件的 Load Balancer 。
• 第二階段：Load Balancer 開始以軟件形式實現，使其更加靈活和可擴展，通常以軟件分發的形式出現，因此價格也比較低廉，比如 LVS 就屬于這一類。
• 第三階段：隨著云計算技術的興起，Load Balancer 也開始有了云版本，這個版本的 Load Balancer 其中一個好處是可以幫助企業以更低的成本獲得高性能的負載均衡服務，另一個好處是它能夠利用云計算的可擴展性和彈性的特點來提高整體可用性。例如 AWS 的 Classic Load Balancer、Application Load Balancer、Network Load Balancer 等。

Load Balancer 除了用于分攤流量、提高網絡的伸縮性外，還可以用于提升網絡安全。比如可以將內網服務器與外網進行隔離，防止互聯網的惡意攻擊和訪問。一個簡單的使用場景就是，一個包含敏感信息的內部服務器，Load Balancer 可以把內部服務器隔離在內網中，這樣就能有效保護內部服務器的安全。

二、什么是 API Gateway?

API Gateway 簡單來說是一種主要工作在七層，專門用于 API 的管理和流量轉發的基礎設施，并在此基礎上擁有 Load Balancer 所不具備的強大的擴展性，比如：認證、可觀測性、自定義插件等等。簡單來說，包括但不限于以下這些特點：

• 豐富的路由策略：API Gateway 工作在七層，所以它可以解析到 HTTP/HTTPS 層的數據。因此它可以根據請求的 Path 或 Domain 甚至是 Header 作為條件，將請求轉發到不同的上游服務器。
• 認證：可以在API層面支持多種多樣的認證方式來避免非法請求，比如 OAuth2、JWT 等等，直接將認證這部分服務獨立出來，不侵入或者少侵入業務代碼。
• 限流：支持對不同程度的路由進行細粒度的限流，防止惡意攻擊，防止后端服務雪崩。
• 可觀測性：可觀察性是指從系統外部觀察系統內部程序的運行狀態和資源使用情況的能力。 API Gateway 支持將日志對接到 Kafka、 Google Cloud Logging Service、Elasticsearch 等，支持將相關 metrics 接入到 prometheus、datadog 等。
• 擴展：因為 API Gateway 自身是網關身份，這就注定對它要求是能適配各家公司不同應用場景，比如不同的鑒權、灰度、安全策略、日志收集等，必須允許用戶自由選擇所需擴展或者自定義開發，因此擴展性很強，允許選擇的擴展種類也十分豐富。以 Apache APISIX 舉例，光是認證的擴展就有 13 款，幾乎涵蓋了市面上常見的認證需求。

目前市面上有許多 API Gateway，比如 Apache APISIX、Kong、Tyk、Zuul 等，開發者可以根據自己的需求選擇合適的 API Gateway。

三、API Gateway 與 Load Balancer 主要區別?

首先，他們主要工作的側重點不同。雖然說 API Gateway 和 Load Balancer 都支持四層和七層的代理。但是，API Gateway 主要側重于七層，而 Load Balancer 主要側重于四層。

工作在四層的 Load Balancer 擁有許多有利的特點，首先是它相比于 API Gateway 減少了協議解析的損耗，具有更強的吞吐能力。其次就是它支持透傳客戶端 IP 地址，而 API Gateway，一般是通過 HTTP 頭方式傳遞客戶端 IP 地址。

其次就是功能的豐富程度不同。Load Balancer 的 HTTP 七層處理能力比較弱，往往不包含認證、授權、鑒權、復雜路由邏輯、日志收集等功能。API Gateway 則具有相當強大的七層協議處理能力，可以在此基礎上，附加各種各樣的功能擴展，比如權限控制、日志、API 管理、Serverless 等等。

現如今，科技公司的產品需求變幻莫測，對于很多公司來說支持自定義開發是剛需。API Gateway 支持各式的自定義開發，比如支持豐富的編程語言，支持在流量轉發的不同階段注入自定義的處理邏輯，而 Load Balancer 基本不支持任何自定義功能開發。

還有一點就是 Load Balancer 通常采用流量直接分發的形式做負載均衡，它通過算法將流量數據直接發向某個后端服務器節點。這意味著后端等待接收流量的每一個服務實例行為都必須是一致的，這減少了一定的靈活性。而 API Gateway 則是以 URL Path 、Domain、Header 等維度進行流量分發，后端等待接收流量的服務實例可以多種多樣，可以是某個 Private API，也可以是某個 gRPC 的 API。這就使流量分發變得十分地靈活。

四、使用場景?

微服務場景?

API Gateway 對于微服務架構的系統是剛需。首先它可以方便地管理和路由多種不同的后端服務，其次可以提供許多高級功能，比如身份驗證、授權、限流、轉發、日志記錄等功能。這樣不同的微服務之間無需重復實現限流、認證等功能，讓微服務的每個服務的功能實現更加純粹，減少研發成本。

由于微服務的特點是服務種類多，工作在四層的 Load Balancer 不太適合對種類繁多后端服務做負載均衡，它更適合用于單體后端服務。即使是工作在七層的 Load Balancer，因為一般不能提供較為豐富的高級功能，相比于 API Gateway 在微服務上優勢也不明顯。

API 管理與發布?

在需要對大量的 API 進行管理和發布的場景，API Gateway 也非常適用，因為它具有強大的 API 管理功能，可以讓你隨時隨地讓某個 API 上線或者下線，快速地修改 API 轉發的配置，快速地為某個 API 添加限流、認證、日志等等功能而無需重新啟動 API Gateway。

以 Apache APISIX 為例，Apache APISIX 是 Apache 基金會旗下的頂級開源項目，也是當前最活躍的開源網關項目。作為一個動態、實時、高性能的開源 API 網關，Apache APISIX 提供了負載均衡、動態上游、灰度發布、服務熔斷、身份認證、可觀測性等豐富的流量管理功能。

而傳統的 Load Balancer 則在 API 管理上較為弱勢，不具備如此豐富的高級功能。

高性能的網絡出入口?

對于需要大流量、極高穩定性的網絡出入口的場景，工作在四層的 Load Balancer 顯然更為適用。它可以把網絡原始四層流量直接分發到各個后端服務中，不存在中間層多次解析應用層協議的影響，具有更強的吞吐能力。

而工作在七層的 API Gateway 作為統一的入口，會由于需要解析協議，存在一定的吞吐量限制。即使是使用四層的 API Gateway 來做網絡出入口也不太有優勢，因為這一層不是 API Gateway 的側重點，相比于 Load Balancer 多年在這一層的技術累計，API Gateway 優勢也不明顯。

四、總結?

總的來說，API Gateway 和 Load Balancer 是分別用于解決不同層面問題的基礎設施。API Gateway 主要用于作為后端的 API 接口代理，提供對外訪問不同種類 API 的一個單獨入口，并且可以提供獨立于后端服務的限流、認證、監控等功能；而 Load Balancer 則主要用于四層流量分發，它可以將請求分攤到多臺后端服務器上，平衡后端的請求負載，以提高系統的整體可用性和容錯性。

在合理的架構設計下，一般都將 API Gateway 和 Load Balancer 配合使用，使用 Load Balancer 作為整個系統的網絡出入口，將流量分發到多個 API Gateway 實例，然后每個 API Gateway 實例分別對請求進行路由、認證、鑒權等操作，這樣可以使得整個網絡更加穩健、可靠、可擴展。
文章來源：API Gateway vs Load balancer: Choose the right network traffic management component for you