在本篇文章中，我們就一起來(lái)探討一下 API 網(wǎng)關(guān)在整個(gè)微服務(wù)分布式架構(gòu)中的一個(gè)作用。

# 背景我們知道在微服務(wù)架構(gòu)風(fēng)格中，一個(gè)大應(yīng)用被拆分成為了多個(gè)小的服務(wù)系統(tǒng)提供出來(lái)，這些小的系統(tǒng)他們可以自成體系，也就是說(shuō)這些小系統(tǒng)可以擁有自己的數(shù)據(jù)庫(kù)，框架甚至語(yǔ)言等，這些小系統(tǒng)通常以提供 Rest Api 風(fēng)格的接口來(lái)被 H5, Android, IOS 以及第三方應(yīng)用程序調(diào)用。但是在UI上進(jìn)行展示的時(shí)候，我們通常需要在一個(gè)界面上展示很多數(shù)據(jù)，這些數(shù)據(jù)可能來(lái)自于不同的微服務(wù)中，舉個(gè)例子。在一個(gè)電商系統(tǒng)中，查看一個(gè)商品詳情頁(yè)，這個(gè)商品詳情頁(yè)包含商品的標(biāo)題，價(jià)格，庫(kù)存，評(píng)論等，這些數(shù)據(jù)對(duì)于后端來(lái)說(shuō)可能是位于不同的微服務(wù)系統(tǒng)之中，可能我后臺(tái)的系統(tǒng)是這樣來(lái)拆分我的服務(wù)的：

• 產(chǎn)品服務(wù) - 負(fù)責(zé)提供商品的標(biāo)題，描述，規(guī)格等。
• 價(jià)格服務(wù) - 負(fù)責(zé)對(duì)產(chǎn)品進(jìn)行定價(jià)，價(jià)格策略計(jì)算，促銷價(jià)等。
• 庫(kù)存服務(wù) - 負(fù)責(zé)產(chǎn)品庫(kù)存。
• 評(píng)價(jià)服務(wù) - 負(fù)責(zé)用戶對(duì)商品的評(píng)論，回復(fù)等。

現(xiàn)在，商品詳情頁(yè)需要從這些微服務(wù)中拉取相應(yīng)的信息，問(wèn)題來(lái)了？

# 問(wèn)題

由于我們使用的服務(wù)系統(tǒng)架構(gòu)，所以沒(méi)辦法像傳統(tǒng)單體應(yīng)用一樣依靠數(shù)據(jù)庫(kù)的 join 查詢來(lái)得到最終結(jié)果，那么如何才能訪問(wèn)各個(gè)服務(wù)呢？按照微服務(wù)設(shè)計(jì)的指導(dǎo)原則，我們的微服務(wù)可能存在下面的問(wèn)題：

• 服務(wù)使用了多種協(xié)議，因?yàn)椴煌膮f(xié)議有不同的應(yīng)場(chǎng)景用，比如可能同時(shí)使用 HTTP, AMQP, gRPC 等。
• 服務(wù)的劃分可能隨著時(shí)間而變化。
• 服務(wù)的實(shí)例或者Host+端口可能會(huì)動(dòng)態(tài)的變化。

那么，對(duì)于前端的UI需求也可能會(huì)有以下幾種：

• 粗粒度的API，而微服務(wù)通常提供的細(xì)粒度的API，對(duì)于UI來(lái)說(shuō)如果要調(diào)用細(xì)粒度的api可能需要調(diào)用很多次，這是個(gè)不小的問(wèn)題。
• 不同的客戶端設(shè)備可能需要不同的數(shù)據(jù)。Web,H5,APP
• 不同設(shè)備的網(wǎng)絡(luò)性能，對(duì)于多個(gè)api來(lái)說(shuō)，這個(gè)訪問(wèn)需要轉(zhuǎn)移的服務(wù)端會(huì)快得多

以上，就是我們構(gòu)建微服務(wù)的過(guò)程中可能會(huì)遇到的問(wèn)題。那么如何解決呢？這種情況下，我們就需要一個(gè)今天要講的這個(gè)東西， API 網(wǎng)關(guān)(API Gataway)。# API 網(wǎng)關(guān)

下面是百度上針對(duì)于 API 網(wǎng)關(guān)的介紹：

API網(wǎng)關(guān)是一個(gè)服務(wù)器，是系統(tǒng)的唯一入口。從面向?qū)ο笤O(shè)計(jì)的角度看，它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶端提供一個(gè)定制的API。它可能還具有其它職責(zé)，如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存、請(qǐng)求分片與管理、靜態(tài)響應(yīng)處理。
API網(wǎng)關(guān)方式的核心要點(diǎn)是，所有的客戶端和消費(fèi)端都通過(guò)統(tǒng)一的網(wǎng)關(guān)接入微服務(wù)，在網(wǎng)關(guān)層處理所有的非業(yè)務(wù)功能。通常，網(wǎng)關(guān)也是提供REST/HTTP的訪問(wèn)API。服務(wù)端通過(guò)API-GW注冊(cè)和管理服務(wù)。

Chris Richardson 在他的博客中把 API 網(wǎng)關(guān)劃分為以下兩種：

• 單節(jié)點(diǎn) API 網(wǎng)關(guān)

• Backends for frontends 網(wǎng)關(guān)

單節(jié)點(diǎn)網(wǎng)關(guān)

單節(jié)點(diǎn)的 API網(wǎng)關(guān)為每個(gè)客戶端提供不同的API，而不是提供一種萬(wàn)能風(fēng)格的API。

這個(gè)網(wǎng)關(guān)和微軟在 eShop 項(xiàng)目中推薦的網(wǎng)關(guān)是一致的。

更多詳細(xì)信息我會(huì)在下文進(jìn)行說(shuō)明。

Backends for frontends 網(wǎng)關(guān)

這種模式是針對(duì)不同的客戶端來(lái)實(shí)現(xiàn)一個(gè)不同的API網(wǎng)關(guān)。

# 落地方案我一直在尋思一種最佳的 API 網(wǎng)關(guān)的落地方案，以上兩種 API 網(wǎng)關(guān)有什么問(wèn)題呢？通常情況下， API 網(wǎng)關(guān)要做很多工作，它作為一個(gè)系統(tǒng)的后端總?cè)肟?#xff0c;承載著所有服務(wù)的組合路由轉(zhuǎn)換等工作，除此之外，我們一般也會(huì)把安全，限流，緩存，日志，監(jiān)控，重試，熔斷等放到 API 網(wǎng)關(guān)來(lái)做，那么可以試想在高并發(fā)的情況下，這里可能會(huì)出現(xiàn)一個(gè)性能瓶頸。關(guān)注公眾號(hào)小黃鴨編程社區(qū)，回復(fù)關(guān)鍵字資料，領(lǐng)取最新的編程視頻資料。另外，如果沒(méi)有開(kāi)源項(xiàng)目的支撐前提下，自己來(lái)做這樣一套東西，是非常大的一個(gè)工作量，而且還要做 API 網(wǎng)關(guān)本身的高可用等，如果一旦做不好，有可能最先掛掉的不是你的其他服務(wù)，而就是這個(gè)API網(wǎng)關(guān)。這個(gè)時(shí)候，通常我們會(huì)去找一些開(kāi)源的 API 網(wǎng)關(guān)項(xiàng)目，博主已經(jīng)給你找好了，目前社區(qū)的關(guān)于 API Gataway 的項(xiàng)目有以下這些：Tyk：Tyk是一個(gè)開(kāi)放源碼的API網(wǎng)關(guān)，它是快速、可擴(kuò)展和現(xiàn)代的。Tyk提供了一個(gè)API管理平臺(tái)，其中包括API網(wǎng)關(guān)、API分析、開(kāi)發(fā)人員門(mén)戶和API管理面板。Try 是一個(gè)基于Go實(shí)現(xiàn)的網(wǎng)關(guān)服務(wù)。Kong：Kong是一個(gè)可擴(kuò)展的開(kāi)放源碼API Layer(也稱為API網(wǎng)關(guān)或API中間件)。Kong 在任何RESTful API的前面運(yùn)行，通過(guò)插件擴(kuò)展，它提供了超越核心平臺(tái)的額外功能和服務(wù)。Orange：和Kong類似也是基于OpenResty的一個(gè)API網(wǎng)關(guān)程序，是由國(guó)人開(kāi)發(fā)的，學(xué)姐也是貢獻(xiàn)者之一。Netflix zuul：Zuul是一種提供動(dòng)態(tài)路由、監(jiān)視、彈性、安全性等功能的邊緣服務(wù)。Zuul是Netflix出品的一個(gè)基于JVM路由和服務(wù)端的負(fù)載均衡器。apiaxle: Nodejs 實(shí)現(xiàn)的一個(gè) API 網(wǎng)關(guān)。api-umbrella: Ruby 實(shí)現(xiàn)的一個(gè) API 網(wǎng)關(guān)。我們來(lái)說(shuō)說(shuō)上面的這些開(kāi)源項(xiàng)目適不適合作為 API 網(wǎng)關(guān)來(lái)供我們使用。拿單節(jié)點(diǎn)網(wǎng)關(guān)來(lái)說(shuō)，這種網(wǎng)關(guān)相當(dāng)于是處于 Web 層和 Service 之間，用來(lái)聚合服務(wù)的？注意，我們需要的是聚合服務(wù)，而以上這些開(kāi)源項(xiàng)目都不具備這個(gè)功能，我說(shuō)的聚合具體指的是開(kāi)箱即用。我們要想使用這些服務(wù)需要來(lái)自己對(duì)API網(wǎng)關(guān)過(guò)一些擴(kuò)展或者是開(kāi)發(fā)一些插件，這個(gè)時(shí)候問(wèn)題就來(lái)了。擴(kuò)展Tyk我需要會(huì)Go語(yǔ)言，擴(kuò)展Kong我需要會(huì)寫(xiě)lua腳本，使用 zuul 還得會(huì)Java，這對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)是不太現(xiàn)實(shí)的，那么這個(gè)時(shí)候怎么辦？有些同學(xué)可能會(huì)說(shuō) ASP.NET Core 可以使用 Ocelot，說(shuō)得沒(méi)錯(cuò)，我們可以通過(guò)引入Ocelot來(lái)處理API聚合服務(wù)這一塊的業(yè)務(wù)，但是，這中間有一個(gè)問(wèn)題，就像我在上面說(shuō)的一樣，這很容易造成性能問(wèn)題，另外一方面，Ocelot的功能相比上面的那些開(kāi)源項(xiàng)目來(lái)說(shuō)功能要弱很多，具體體現(xiàn)在哪些方面呢？除了最重要的高性能的IO模型和集群方案外， 比如會(huì)經(jīng)常使用的 Dashboard 功能，這個(gè)對(duì)于運(yùn)維來(lái)說(shuō)是非常重要的，另外還有日志，監(jiān)控，安全，服務(wù)發(fā)現(xiàn)，版本控制等。但是上面的這些 API 網(wǎng)關(guān)缺少什么功能呢？比如超時(shí)，熔斷，重試，聚合查詢等。

注意：以下內(nèi)容的這些想法全是我個(gè)人對(duì)于 API 網(wǎng)關(guān)的理解而誕生的，如有錯(cuò)誤還請(qǐng)指正。

聰明的同學(xué)可能想出來(lái)了，怎么辦呢？我們可以充分來(lái)結(jié)合兩者的優(yōu)勢(shì)來(lái)在我們的 ASP.NET Core 應(yīng)用程序中實(shí)現(xiàn)一個(gè)“雙重網(wǎng)關(guān)”。

下面是我畫(huà)的一個(gè) API 網(wǎng)關(guān)在微服務(wù)架構(gòu)中的一個(gè)作用圖：

應(yīng)該大部分同學(xué)都可以看懂，我就簡(jiǎn)單解釋一下。

• OpenResty Api Gateway

從左至右 HTTP 請(qǐng)求先由DNS在拿到第一手流量后負(fù)載均衡到基于 OpenResty 的 API Gataway 網(wǎng)關(guān)集群，在這個(gè)流程我們可以使用像 Kong,Orage,Tyk 這些開(kāi)源的支持高并發(fā)高訪問(wèn)量 API 網(wǎng)關(guān)程序在做第一層流量的防護(hù)，在這一級(jí)我們可以做一些像身份認(rèn)證，安全，監(jiān)控，日志，流控等策略。除了這些我們還可以做一些服務(wù)的發(fā)現(xiàn)和注冊(cè)(這個(gè)要看不同網(wǎng)關(guān)的支持程度)，接口的版本控制，路由重寫(xiě)等。

• Aggr Api Gateway

然后再由這些 API 網(wǎng)關(guān)把請(qǐng)求再負(fù)載到不同的 Aggr Api Gateway，在這里我們做聚合服務(wù)這個(gè)操作，具體體現(xiàn)也就是圖中的黃色區(qū)域是需要由各個(gè)語(yǔ)言的開(kāi)發(fā)人員來(lái)需要寫(xiě)代碼實(shí)現(xiàn)的。具體流程也就是我們可以引入像 Ocelot 這種和語(yǔ)言相關(guān)的 API 網(wǎng)關(guān)開(kāi)源項(xiàng)目，然后通過(guò) NuGet 包引入之后通過(guò) Json配置+聚合代碼的方式來(lái)整合后端的各個(gè)微服務(wù)提供聚合查詢等操作。這期間對(duì)于有需求的接口，我們可以應(yīng)用超時(shí)，緩存，熔斷，重試等策略。從 Aggr Api Gateway 到后端微服務(wù)集群這中間就屬于內(nèi)部的通訊了，我們可以使用對(duì)內(nèi)部友好的通訊協(xié)議比如 gRPC 或者 AMQP 等，然后進(jìn)行 RPC調(diào)用提高通訊性能。注意：Aggr Api Gateway 這個(gè)網(wǎng)關(guān)對(duì)于一些接口來(lái)說(shuō)的話并不是必須的，也可以由后端微服務(wù)直接提供REST API給第一層網(wǎng)關(guān)使用。以上，就是我理解的 API 網(wǎng)關(guān)在整個(gè)微服務(wù)架構(gòu)中的一個(gè)地位，承上啟下，還是非常的重要。我們知道，在 API 網(wǎng)關(guān)的后端是微服務(wù)的集群，那么除了聚合查詢之外有時(shí)候我們有時(shí)候需要做一些跨不同服務(wù)的操作，比如一次電商系統(tǒng)的下單操作，可以會(huì)設(shè)計(jì)到產(chǎn)品、價(jià)格、庫(kù)存等一系列跨微服務(wù)操作，在中間我們一般會(huì)采用集成事件(EventBus)來(lái)進(jìn)行通訊這種解決方案，在這個(gè)過(guò)程中我們不僅僅的是需要通訊，那么這些操作還需要保證事務(wù)一致性，而一般分布式系統(tǒng)中的事務(wù)我們追求的是最終一致性。如果是在 .NET Core 中，我們可以使用博主開(kāi)源的 EventBus + 分布式事務(wù) 解決方案 CAP。GitHub：https://github.com/dotnetcore/CAP# 總結(jié)通過(guò)本文我們了解到了什么是 API 網(wǎng)關(guān)以及API網(wǎng)關(guān)的作用和其在微服務(wù)架構(gòu)中所處的地位。然后我們了解到了 API 網(wǎng)關(guān)的一些開(kāi)源項(xiàng)目以及博主介紹的落地方案，在實(shí)際的實(shí)踐中還是多希望大家能夠多多思考總結(jié)，這樣我們才能夠變得更加強(qiáng)大。

作者：Savorboard

來(lái)源：https://www.cnblogs.com/savorboard/p/api-gateway.html

往期推薦

?

• 快訊：Eclipse 4.16 穩(wěn)定版發(fā)布了！
• Logback 配置文件這么寫(xiě)，TPS 提高 10 倍！
• Spring Boot 2.3.1 發(fā)布了！與鴨哥一起解讀新特性:-)

戳

總結(jié)

以上是生活随笔為你收集整理的api商品分享源码_谈谈微服务中的 API 网关（API Gateway）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。