由于互聯(lián)網(wǎng)技術(shù)的發(fā)展，網(wǎng)絡(luò)數(shù)據(jù)的請求數(shù)節(jié)節(jié)攀升，這使得服務(wù)器承受的壓力越來越大。在早期的系統(tǒng)架構(gòu)中，通常使用負(fù)載均衡來將網(wǎng)絡(luò)流量平攤到多個(gè)服務(wù)器中，以此減輕單臺(tái)服務(wù)器的壓力。但是現(xiàn)如今，后端服務(wù)的種類在不斷地變多，每個(gè)種類的后端都以 API 的形式對外暴露，這使得 API 的數(shù)量也在不斷變多。以傳統(tǒng)的?負(fù)載均衡為主的系統(tǒng)架構(gòu)的局限性就變得明顯起來，因?yàn)樗饕ぷ髟谒膶?，在七層上功能較弱，于是一款主要工作在七層且具有豐富擴(kuò)展能力的基礎(chǔ)設(shè)施便應(yīng)運(yùn)而生，它就是 API 網(wǎng)關(guān)。

在本文中，我們將介紹負(fù)載均衡和 API?網(wǎng)關(guān)的功能特點(diǎn)，并探討它們之間的區(qū)別，幫助讀者更好地了解這兩者之間的關(guān)系。

一、什么是負(fù)載均衡（Load Balancer）

負(fù)載均衡的主要作用是為多個(gè)后端服務(wù)提供負(fù)載均衡功能，依據(jù)不同的負(fù)載均衡算法讓這些服務(wù)可以分?jǐn)偭髁?。?fù)載均衡的歷史非常悠久，從演進(jìn)路徑上看大致可以分為以下這幾個(gè)階段：

• 第一階段：這一階段的負(fù)載均衡通常由硬件設(shè)備組成，具有高性能、高可靠性的特點(diǎn)，但靈活性較差，價(jià)格昂貴。比較典型的是 F5 這種基于硬件的負(fù)載均衡。

• 第二階段：負(fù)載均衡開始以軟件形式實(shí)現(xiàn)，使其更加靈活和可擴(kuò)展，通常以軟件分發(fā)的形式出現(xiàn)，因此價(jià)格也比較低廉，比如 LVS 就屬于這一類。

• 第三階段：隨著云計(jì)算技術(shù)的興起，負(fù)載均衡也開始有了云版本，這個(gè)版本的負(fù)載均衡其中一個(gè)好處是可以幫助企業(yè)以更低的成本獲得高性能的負(fù)載均衡服務(wù)，另一個(gè)好處是它能夠利用云計(jì)算的可擴(kuò)展性和彈性的特點(diǎn)來提高整體可用性。例如 AWS 的 Classic Load Balancer、Application Load Balancer、Network Load Balancer 等。

負(fù)載均衡除了用于分?jǐn)偭髁?、提高網(wǎng)絡(luò)的伸縮性外，還可以用于提升網(wǎng)絡(luò)安全。比如可以將內(nèi)網(wǎng)服務(wù)器與外網(wǎng)進(jìn)行隔離，防止互聯(lián)網(wǎng)的惡意攻擊和訪問。一個(gè)簡單的使用場景就是，一個(gè)包含敏感信息的內(nèi)部服務(wù)器，負(fù)載均衡可以把內(nèi)部服務(wù)器隔離在內(nèi)網(wǎng)中，這樣就能有效保護(hù)內(nèi)部服務(wù)器的安全。

二、什么是 API 網(wǎng)關(guān)（Gateway）

API?網(wǎng)關(guān)簡單來說是一種主要工作在七層，專門用于 API 的管理和流量轉(zhuǎn)發(fā)的基礎(chǔ)設(shè)施，并在此基礎(chǔ)上擁有負(fù)載均衡所不具備的強(qiáng)大的擴(kuò)展性，比如：認(rèn)證、可觀測性、自定義插件等等。簡單來說，包括但不限于以下這些特點(diǎn)：

• 豐富的路由策略：API?網(wǎng)關(guān)工作在七層，所以它可以解析到 HTTP/HTTPS 層的數(shù)據(jù)。因此它可以根據(jù)請求的 Path 或 Domain 甚至是 Header 作為條件，將請求轉(zhuǎn)發(fā)到不同的上游服務(wù)器。

• 認(rèn)證：可以在API層面支持多種多樣的認(rèn)證方式來避免非法請求，比如 OAuth2、JWT 等等，直接將認(rèn)證這部分服務(wù)獨(dú)立出來，不侵入或者少侵入業(yè)務(wù)代碼。

• 限流：支持對不同程度的路由進(jìn)行細(xì)粒度的限流，防止惡意攻擊，防止后端服務(wù)雪崩。

• 可觀測性：可觀察性是指從系統(tǒng)外部觀察系統(tǒng)內(nèi)部程序的運(yùn)行狀態(tài)和資源使用情況的能力。API?網(wǎng)關(guān)支持將日志對接到 Kafka、 Google Cloud Logging Service、Elasticsearch 等，支持將相關(guān) metrics 接入到 prometheus、datadog 等。

• 擴(kuò)展：因?yàn)?API?網(wǎng)關(guān)自身是網(wǎng)關(guān)身份，這就注定對它要求是能適配各家公司不同應(yīng)用場景，比如不同的鑒權(quán)、灰度、安全策略、日志收集等，必須允許用戶自由選擇所需擴(kuò)展或者自定義開發(fā)，因此擴(kuò)展性很強(qiáng)，允許選擇的擴(kuò)展種類也十分豐富。以 Apache APISIX 舉例，光是認(rèn)證的擴(kuò)展就有 13 款，幾乎涵蓋了市面上常見的認(rèn)證需求。

目前市面上有許多 API?網(wǎng)關(guān)，比如 Apache APISIX、Kong、Tyk、Zuul 等，開發(fā)者可以根據(jù)自己的需求選擇合適的 API?網(wǎng)關(guān)。

三、API?網(wǎng)關(guān)與負(fù)載均衡主要區(qū)別

首先，他們主要工作的側(cè)重點(diǎn)不同。雖然說 API?網(wǎng)關(guān)和負(fù)載均衡都支持四層和七層的代理。但是，API?網(wǎng)關(guān)主要側(cè)重于七層，而負(fù)載均衡主要側(cè)重于四層。

工作在四層的負(fù)載均衡擁有許多有利的特點(diǎn)，首先是它相比于 API?網(wǎng)關(guān)減少了協(xié)議解析的損耗，具有更強(qiáng)的吞吐能力。其次就是它支持透傳客戶端 IP 地址，而 API?網(wǎng)關(guān)，一般是通過 HTTP 頭方式傳遞客戶端 IP 地址。

其次就是功能的豐富程度不同。負(fù)載均衡的 HTTP 七層處理能力比較弱，往往不包含認(rèn)證、授權(quán)、鑒權(quán)、復(fù)雜路由邏輯、日志收集等功能。API?網(wǎng)關(guān)則具有相當(dāng)強(qiáng)大的七層協(xié)議處理能力，可以在此基礎(chǔ)上，附加各種各樣的功能擴(kuò)展，比如權(quán)限控制、日志、API 管理、Serverless 等等。

現(xiàn)如今，科技公司的產(chǎn)品需求變幻莫測，對于很多公司來說支持自定義開發(fā)是剛需。API?網(wǎng)關(guān)支持各式的自定義開發(fā)，比如支持豐富的編程語言，支持在流量轉(zhuǎn)發(fā)的不同階段注入自定義的處理邏輯，而負(fù)載均衡基本不支持任何自定義功能開發(fā)。

還有一點(diǎn)就是負(fù)載均衡通常采用流量直接分發(fā)的形式做負(fù)載均衡，它通過算法將流量數(shù)據(jù)直接發(fā)向某個(gè)后端服務(wù)器節(jié)點(diǎn)。這意味著后端等待接收流量的每一個(gè)服務(wù)實(shí)例行為都必須是一致的，這減少了一定的靈活性。而 API?網(wǎng)關(guān)則是以 URL Path 、Domain、Header 等維度進(jìn)行流量分發(fā)，后端等待接收流量的服務(wù)實(shí)例可以多種多樣，可以是某個(gè) Private API，也可以是某個(gè) gRPC 的 API。這就使流量分發(fā)變得十分地靈活。

四、使用場景

微服務(wù)場景

API?網(wǎng)關(guān)對于采用了微服務(wù)架構(gòu)的系統(tǒng)是剛需。首先它可以方便地管理和路由多種不同的后端服務(wù)，其次可以提供許多高級(jí)功能，比如身份驗(yàn)證、授權(quán)、限流、轉(zhuǎn)發(fā)、日志記錄等功能。這樣不同的微服務(wù)之間無需重復(fù)實(shí)現(xiàn)限流、認(rèn)證等功能，讓微服務(wù)的每個(gè)服務(wù)的功能實(shí)現(xiàn)更加純粹，減少研發(fā)成本。

由于微服務(wù)的特點(diǎn)是服務(wù)種類多，工作在四層的負(fù)載均衡不太適合對種類繁多后端服務(wù)做負(fù)載均衡，它更適合用于單體后端服務(wù)。即使是工作在七層的負(fù)載均衡，因?yàn)橐话悴荒芴峁┹^為豐富的高級(jí)功能，相比于 API?網(wǎng)關(guān)在微服務(wù)上優(yōu)勢也不明顯。

API 管理與發(fā)布

在需要對大量的 API 進(jìn)行管理和發(fā)布的場景，API?網(wǎng)關(guān)也非常適用，因?yàn)樗哂袕?qiáng)大的 API 管理功能，可以讓你隨時(shí)隨地讓某個(gè) API 上線或者下線，快速地修改 API 轉(zhuǎn)發(fā)的配置，快速地為某個(gè) API 添加限流、認(rèn)證、日志等等功能而無需重新啟動(dòng) API?網(wǎng)關(guān)。

以 Apache APISIX 為例，Apache APISIX 是 Apache 基金會(huì)旗下的頂級(jí)開源項(xiàng)目，也是當(dāng)前最活躍的開源網(wǎng)關(guān)項(xiàng)目。作為一個(gè)動(dòng)態(tài)、實(shí)時(shí)、高性能的開源 API 網(wǎng)關(guān)，Apache APISIX 提供了負(fù)載均衡、動(dòng)態(tài)上游、灰度發(fā)布、服務(wù)熔斷、身份認(rèn)證、可觀測性等豐富的流量管理功能。

而傳統(tǒng)的負(fù)載均衡則在 API 管理上較為弱勢，不具備如此豐富的高級(jí)功能。

高性能的網(wǎng)絡(luò)出入口

對于需要大流量、極高穩(wěn)定性的網(wǎng)絡(luò)出入口的場景，工作在四層的負(fù)載均衡顯然更為適用。它可以把網(wǎng)絡(luò)原始四層流量直接分發(fā)到各個(gè)后端服務(wù)中，不存在中間層多次解析應(yīng)用層協(xié)議的影響，具有更強(qiáng)的吞吐能力。

而工作在七層的 API?網(wǎng)關(guān)作為統(tǒng)一的入口，會(huì)由于需要解析協(xié)議，存在一定的吞吐量限制。即使是使用四層的 API?網(wǎng)關(guān)來做網(wǎng)絡(luò)出入口也不太有優(yōu)勢，因?yàn)檫@一層不是 API?網(wǎng)關(guān)的側(cè)重點(diǎn)，相比于負(fù)載均衡多年在這一層的技術(shù)累計(jì)，API?網(wǎng)關(guān)優(yōu)勢也不明顯。

總結(jié)

總的來說，API?網(wǎng)關(guān)和負(fù)載均衡是分別用于解決不同層面問題的基礎(chǔ)設(shè)施。API?網(wǎng)關(guān)主要用于作為后端的 API 接口代理，提供對外訪問不同種類 API 的一個(gè)單獨(dú)入口，并且可以提供獨(dú)立于后端服務(wù)的限流、認(rèn)證、監(jiān)控等功能；而負(fù)載均衡則主要用于四層流量分發(fā)，它可以將請求分?jǐn)偟蕉嗯_(tái)后端服務(wù)器上，平衡后端的請求負(fù)載，以提高系統(tǒng)的整體可用性和容錯(cuò)性。

在合理的架構(gòu)設(shè)計(jì)下，一般都將 API?網(wǎng)關(guān)和負(fù)載均衡配合使用，使用負(fù)載均衡作為整個(gè)系統(tǒng)的網(wǎng)絡(luò)出入口，將流量分發(fā)到多個(gè) API?網(wǎng)關(guān)實(shí)例，然后每個(gè) API?網(wǎng)關(guān)實(shí)例分別對請求進(jìn)行路由、認(rèn)證、鑒權(quán)等操作，這樣可以使得整個(gè)網(wǎng)絡(luò)更加穩(wěn)健、可靠、可擴(kuò)展。文章來源地址http://www.zghlxwxcb.cn/news/detail-501897.html

到了這里，關(guān)于API 網(wǎng)關(guān) vs 負(fù)載均衡：選擇適合你的網(wǎng)絡(luò)流量管理組件的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！