作者程小蘭，API7.ai 技術(shù)工程師，Apache APISIX Contributor。

什么是微服務(wù)

微服務(wù)架構(gòu)（通常簡(jiǎn)稱(chēng)為微服務(wù)）是指開(kāi)發(fā)應(yīng)用所用的一種架構(gòu)形式。通過(guò)微服務(wù)，可將大型應(yīng)用分解成多個(gè)獨(dú)立的組件，其中每個(gè)組件都有各自的責(zé)任領(lǐng)域。

在處理一個(gè)用戶請(qǐng)求時(shí)，基于微服務(wù)的應(yīng)用可能會(huì)調(diào)用許多內(nèi)部微服務(wù)來(lái)共同生成其響應(yīng)。微服務(wù)是互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展的結(jié)果，互聯(lián)網(wǎng)業(yè)務(wù)的飛速發(fā)展導(dǎo)致系統(tǒng)的架構(gòu)也在不斷地發(fā)生變化，總體來(lái)說(shuō)，系統(tǒng)的架構(gòu)大致經(jīng)歷了：單體應(yīng)用架構(gòu)—> SOA 架構(gòu)—>微服務(wù)架構(gòu)的演變，具體發(fā)展歷程和各自的優(yōu)缺點(diǎn)如下表所示。

因此，微服務(wù)是互聯(lián)網(wǎng)發(fā)展的必然結(jié)果，很多傳統(tǒng)公司的系統(tǒng)架構(gòu)也在逐步微服務(wù)化。但是，隨著互聯(lián)網(wǎng)業(yè)務(wù)的發(fā)展，API 的數(shù)量也在劇增，使用網(wǎng)關(guān)對(duì)API統(tǒng)一管理也將面臨挑戰(zhàn)，選擇一個(gè)更強(qiáng)大的 API 網(wǎng)關(guān)，可以有效地增強(qiáng)系統(tǒng)的監(jiān)控、容災(zāi)、鑒權(quán)和限流等能力。

什么是 API 網(wǎng)關(guān)

API 網(wǎng)關(guān)為客戶與服務(wù)系統(tǒng)之間的交互提供了統(tǒng)一的接口，也是管理請(qǐng)求和響應(yīng)的中心點(diǎn)，選擇一個(gè)適合的 API 網(wǎng)關(guān)，可以有效地簡(jiǎn)化開(kāi)發(fā)并提高系統(tǒng)的運(yùn)維與管理效率。API 網(wǎng)關(guān)在微服務(wù)架構(gòu)中是系統(tǒng)設(shè)計(jì)的一個(gè)解決方案，用來(lái)整合各個(gè)不同模塊的微服務(wù)，統(tǒng)一協(xié)調(diào)服務(wù)。

API 網(wǎng)關(guān)作為一個(gè)系統(tǒng)訪問(wèn)的切面，對(duì)外提供統(tǒng)一的入口供客戶端訪問(wèn)，隱藏系統(tǒng)架構(gòu)實(shí)現(xiàn)的細(xì)節(jié)，讓微服務(wù)使用更為友好；并集成了一些通用特性（如鑒權(quán)、限流、熔斷），避免每個(gè)微服務(wù)單獨(dú)開(kāi)發(fā)，提升效率，使系統(tǒng)更加標(biāo)準(zhǔn)化，比如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、限流、降級(jí)與應(yīng)用檢測(cè)等功能。

為什么微服務(wù)需要 API 網(wǎng)關(guān)

Architecture Diagram

如上圖所示，API 網(wǎng)關(guān)作為客戶端和微服務(wù)的中間層，它可以將微服務(wù)以統(tǒng)一的地址對(duì)外提供服務(wù)，將外部訪問(wèn)這個(gè)地址的流量，根據(jù)適當(dāng)?shù)囊?guī)則路由到內(nèi)部集群中正確的服務(wù)節(jié)點(diǎn)之上，如果沒(méi)有 API 網(wǎng)關(guān)，流量的出入口則不統(tǒng)一，客戶端就需要知道所有服務(wù)的訪問(wèn)信息，微服務(wù)的意義將不復(fù)存在，所以，微服務(wù)網(wǎng)關(guān)在微服務(wù)系統(tǒng)架構(gòu)中的存在是必要的。此外，API 網(wǎng)關(guān)在系統(tǒng)的可觀測(cè)性、身份鑒權(quán)認(rèn)證、穩(wěn)定性和服務(wù)發(fā)現(xiàn)等方面也會(huì)發(fā)揮重要作用。

微服務(wù)遇到的挑戰(zhàn)

微服務(wù)網(wǎng)關(guān)應(yīng)該首先要具備 API 路由能力，微服務(wù)數(shù)量變多，API 數(shù)量急劇增加，網(wǎng)關(guān)還可以根據(jù)具體的場(chǎng)景作為流量過(guò)濾器來(lái)使用，以提供某些額外可選功能，因此對(duì)微服務(wù) API Gateway 提出了更高要求，比如：

可觀測(cè)性：在以往的單體應(yīng)用中，排查問(wèn)題往往通過(guò)查看日志定位錯(cuò)誤信息和異常堆棧；但是在微服務(wù)架構(gòu)中服務(wù)繁多，出現(xiàn)問(wèn)題時(shí)的問(wèn)題定位變得非常困難；因此，如何監(jiān)控微服務(wù)的運(yùn)行狀況、當(dāng)出現(xiàn)異常時(shí)能快速給出報(bào)警，這給開(kāi)發(fā)人員帶來(lái)很大挑戰(zhàn)。

鑒權(quán)認(rèn)證：而微服務(wù)架構(gòu)下，一個(gè)應(yīng)用會(huì)被拆分成若干個(gè)微應(yīng)用，每個(gè)微應(yīng)用都需要對(duì)訪問(wèn)進(jìn)行鑒權(quán)，每個(gè)微應(yīng)用都需要明確當(dāng)前訪問(wèn)用戶以及其權(quán)限。尤其當(dāng)訪問(wèn)來(lái)源不只是瀏覽器，還包括其它服務(wù)的調(diào)用時(shí)，單體應(yīng)用架構(gòu)下的鑒權(quán)方式就不是特別合適了。在微服務(wù)架構(gòu)下，要考慮外部應(yīng)用接入的場(chǎng)景、用戶 - 服務(wù)的鑒權(quán)、服務(wù) - 服務(wù)的鑒權(quán)等多種鑒權(quán)場(chǎng)景。

系統(tǒng)穩(wěn)定性：若大量請(qǐng)求超過(guò)微服務(wù)的處理能力時(shí)，可能會(huì)將服務(wù)打垮，甚至產(chǎn)生雪崩效應(yīng)、影響系統(tǒng)的整體穩(wěn)定性。

服務(wù)發(fā)現(xiàn)：微服務(wù)的分散管理，讓微服務(wù)的負(fù)載均衡的實(shí)現(xiàn)也更具有挑戰(zhàn)性。

解決方案

API 網(wǎng)關(guān)作為客戶端和服務(wù)端的中間橋梁，為微服務(wù)系統(tǒng)提供統(tǒng)一的管理機(jī)制：

除了基礎(chǔ)的請(qǐng)求分發(fā)、API 管理和條件路由等功能，還包括身份驗(yàn)證、監(jiān)控報(bào)警、調(diào)用鏈追蹤、負(fù)載均衡、限流隔離和熔斷降級(jí)。身份認(rèn)證：下圖表示的是微服務(wù)聯(lián)合 API 網(wǎng)關(guān)如何進(jìn)行身份認(rèn)證的，由圖可見(jiàn)所有請(qǐng)求都通過(guò)網(wǎng)關(guān)，從而有效地隱藏了微服務(wù)。

Architecture Diagram

監(jiān)控報(bào)警/調(diào)用鏈追蹤：

API 作為客戶端和服務(wù)端的中間橋梁，是微服務(wù)監(jiān)控的最好載體，API 網(wǎng)關(guān)監(jiān)控功能的主要職責(zé)是及時(shí)發(fā)現(xiàn)網(wǎng)關(guān)以及后端服務(wù)器的連接異常，在 API 的監(jiān)控平臺(tái)上面用戶可以隨時(shí)查看日志信息，監(jiān)控信息，調(diào)用鏈等等，并且主機(jī)發(fā)生的任何異常都會(huì)自動(dòng)報(bào)警到控制臺(tái)。有些網(wǎng)關(guān)甚至可以做到給客戶端和服務(wù)端雙向報(bào)警。

Architecture Diagram

限流隔離/熔斷降級(jí)：

隨著互聯(lián)網(wǎng)業(yè)務(wù)規(guī)模的增加，系統(tǒng)的并發(fā)度增高，多個(gè)服務(wù)之間相互調(diào)用鏈路，一條核心鏈路往往可能調(diào)用十個(gè)服務(wù)。如果在鏈路中，某個(gè)服務(wù)的 rt（響應(yīng)時(shí)間）急劇上升，上游服務(wù)不斷請(qǐng)求，造成惡性循環(huán)，上游等待結(jié)果線程數(shù)越多，使得更上游服務(wù)阻塞最終整條鏈路無(wú)法使用，從而導(dǎo)致服務(wù)雪崩，所以對(duì)入口流量進(jìn)行整治管理是很有必要的，下圖表示微服務(wù)系統(tǒng)是如何結(jié)合 API 網(wǎng)關(guān)進(jìn)行限流隔離和熔斷降級(jí)的。

Architecture Diagram

主流網(wǎng)關(guān)選擇

在微服務(wù)領(lǐng)域，有許多開(kāi)源網(wǎng)關(guān)實(shí)現(xiàn)，有 NGINX、Kong、Apache APISIX 和 Envoy 等，Java 技術(shù)棧的有 Netfilx Zuul、Spring Cloud Gateway、Soul 等?；蛟S你會(huì)問(wèn)“有了 NGINX 和 Kong，為什么還需要 Apache APISIX？” ，下面做個(gè)簡(jiǎn)單對(duì)比。

總結(jié)

隨著互聯(lián)網(wǎng)的發(fā)展，互聯(lián)網(wǎng)企業(yè)的業(yè)務(wù)也在不斷的飛速發(fā)展，進(jìn)而導(dǎo)致系統(tǒng)的架構(gòu)也在不斷的發(fā)生著變化，微服務(wù)架構(gòu)已經(jīng)在眾多公司得到廣泛應(yīng)用。隨著微服務(wù)的數(shù)據(jù)越來(lái)越多，API 的數(shù)量也越來(lái)越多，對(duì)于大流量的治理，選擇一個(gè)優(yōu)秀的 API 網(wǎng)關(guān)是至關(guān)重要的。

本文列舉了常見(jiàn)網(wǎng)關(guān)，并進(jìn)行對(duì)比，列出各自的優(yōu)缺點(diǎn)，如果你正在做 API 網(wǎng)關(guān)的技術(shù)選型，或者你的微服務(wù)系統(tǒng)出現(xiàn)了性能問(wèn)題，再或者你想搭建一個(gè)高效穩(wěn)定的微服務(wù)系統(tǒng)，希望本文可以帶給你一定的啟發(fā)。

審核編輯：湯梓紅