API網(wǎng)關(guān)模式怎么理解

API網(wǎng)關(guān)模式怎么理解，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

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

    網(wǎng)關(guān)一詞來(lái)源于計(jì)算機(jī)網(wǎng)絡(luò)中的定義，網(wǎng)關(guān)(Gateway)又稱網(wǎng)間連接器、協(xié)議轉(zhuǎn)換器。網(wǎng)關(guān)的準(zhǔn)確定義是： 兩個(gè)計(jì)算機(jī)程序或系統(tǒng)之間的連接，網(wǎng)關(guān)作為兩個(gè)程序之間的門戶，允許它們通過(guò)不同計(jì)算機(jī)之間的協(xié)議通信來(lái)共享信息。顧名思義API網(wǎng)關(guān)就是API之間相互調(diào)用的關(guān)卡和屏障。

API之間為什么需要網(wǎng)關(guān)

    試想一下我們?cè)趯?shí)現(xiàn)一個(gè)非常龐大的業(yè)務(wù)系統(tǒng)，分為不同的業(yè)務(wù)domain和子系統(tǒng)，各個(gè)domain和子系統(tǒng)提供處理業(yè)務(wù)的API，不同系統(tǒng)之間以API的方式進(jìn)行數(shù)據(jù)交互。通常情況下我們可能會(huì)將所有實(shí)現(xiàn)業(yè)務(wù)功能的API集成到一起（API Center）給不同的Channel的Portal提供數(shù)據(jù)處理的能力。當(dāng)有一天我們的系統(tǒng)需要與第三方發(fā)生交互，我們既需要暴露給外部系統(tǒng)調(diào)用的公開(kāi)API，同時(shí)也需要調(diào)用外部的API實(shí)現(xiàn)自身的業(yè)務(wù)需求。此時(shí)我們將會(huì)考慮很多的問(wèn)題，比如：服務(wù)之間訪問(wèn)的授權(quán)和認(rèn)證，安全和性能的監(jiān)控，緩存和日志的處理，超時(shí)的Retry，負(fù)載和熔斷的處理，查詢請(qǐng)求的聚合等等一系列的問(wèn)題。此時(shí)你需要一個(gè)可以集中處理所有可能在服務(wù)調(diào)用之間需要處理的一切事情，就像是小區(qū)的物業(yè)和安保一樣，需要對(duì)小區(qū)所有的業(yè)主處理職責(zé)范圍內(nèi)的一切事情。

    這是通常情況下API網(wǎng)關(guān)需要幫我們處理的事情，隨著系統(tǒng)業(yè)務(wù)的不斷復(fù)雜化，我們的系統(tǒng)越越龐大，API的交互越來(lái)越錯(cuò)綜復(fù)雜。此時(shí)我們可能會(huì)考慮將這個(gè)龐大的系統(tǒng)拆分成多個(gè)細(xì)小的domain，分別提供各自domain的API。這便是時(shí)下最流行的話題：微服務(wù)。當(dāng)我們的系統(tǒng)演進(jìn)到微服務(wù)的架構(gòu)時(shí)，API網(wǎng)關(guān)將是系統(tǒng)必不可少的關(guān)鍵部分。在微服務(wù)體系結(jié)構(gòu)中，客戶端應(yīng)用程序通常需要使用多個(gè)微服務(wù)的功能?？蛻舳巳绻苯酉M(fèi)某服務(wù)，那通常情況下將需要處理和協(xié)調(diào)用多個(gè)微服務(wù)endpoint。當(dāng)應(yīng)用程序引入新的微服務(wù)或更新現(xiàn)有微服務(wù)時(shí)會(huì)發(fā)生什么?試想一下如果你的應(yīng)用程序有許多微服務(wù)，那么處理和協(xié)調(diào)來(lái)自客戶端如此多的endpoint的請(qǐng)求，那對(duì)系統(tǒng)來(lái)說(shuō)是一場(chǎng)噩夢(mèng)，而且由于客戶端應(yīng)用程序?qū)⑴c這些endpoint產(chǎn)生耦合，這將會(huì)使我們的系統(tǒng)邊的混亂不堪。

    因此，我們需要一個(gè)中間層或間接層(Gateway)來(lái)處理不同client對(duì)API的請(qǐng)求，這將會(huì)使得我們的應(yīng)用程序處理起來(lái)非常方便。如果沒(méi)有API網(wǎng)關(guān)，客戶端應(yīng)用程序必須直接向微服務(wù)發(fā)送請(qǐng)求，這就會(huì)產(chǎn)生很多混亂的問(wèn)題，比如：

耦合: 如果沒(méi)有API網(wǎng)關(guān)，客戶端的應(yīng)用程序?qū)⑴c內(nèi)部微服務(wù)間耦合?？蛻舳诵蛐枰缹?shí)現(xiàn)業(yè)務(wù)需求的API分散在服務(wù)中的哪些部分，當(dāng)我們開(kāi)發(fā)和重構(gòu)內(nèi)部服務(wù)時(shí)，將會(huì)影響到客戶端應(yīng)用程序，并且很難維護(hù)，因?yàn)榭蛻舳藨?yīng)用程序需要跟蹤多個(gè)服務(wù)的endpoint

多次請(qǐng)求:客戶端應(yīng)用程序中的一個(gè)頁(yè)面可能需要多次調(diào)用多個(gè)服務(wù)來(lái)完成某個(gè)功能，這可能導(dǎo)致客戶端和服務(wù)器之間的多次往返請(qǐng)求，增加了顯著的延遲。我們知道在中間級(jí)別處理的聚合可以提高客戶端應(yīng)用程序的性能和用戶體驗(yàn)。

安全問(wèn)題:如果沒(méi)有網(wǎng)關(guān)，所有的服務(wù)都必須公開(kāi)給“外部世界”，這使得攻擊面比隱藏內(nèi)部服務(wù)更大，而這些服務(wù)不是客戶端應(yīng)用程序直接使用的。攻擊面越小應(yīng)用程序就越安全。

橫切關(guān)注點(diǎn):每個(gè)公開(kāi)發(fā)布的服務(wù)都必須處理諸如授權(quán)、SSL等問(wèn)題。在許多情況下這些關(guān)注點(diǎn)可以在一個(gè)層中處理，這樣內(nèi)部服務(wù)就可以簡(jiǎn)化，這讓我想起了面向切面的編程（AOP）

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

    當(dāng)我們?cè)谑褂枚鄠€(gè)客戶端應(yīng)用程序設(shè)計(jì)和構(gòu)建大型或復(fù)雜的基于微服務(wù)的應(yīng)用程序時(shí)，可以考慮使用API網(wǎng)關(guān)，這是為某些微服務(wù)組提供單一入口點(diǎn)的服務(wù)，它類似于面向?qū)ο笤O(shè)計(jì)的Facade（外觀類）模式，但在微服務(wù)中它是系統(tǒng)的一部分。API網(wǎng)關(guān)模式的一個(gè)變體也稱為“Backend for front-end”(BFF)，因?yàn)槟憧赡軙?huì)根據(jù)每個(gè)客戶端應(yīng)用程序的不同需求創(chuàng)建多個(gè)API網(wǎng)關(guān)。因此API網(wǎng)關(guān)位于客戶端應(yīng)用程序和微服務(wù)之間，它充當(dāng)反向代理將請(qǐng)求從客戶端路由到服務(wù)，它還可以提供額外的橫切特性，如身份驗(yàn)證、SSL終止和緩存。

下面的圖顯示了自定義API網(wǎng)關(guān)如何適合于基于微服務(wù)的體系結(jié)構(gòu)。

在上面的示例中，API網(wǎng)關(guān)將作為自定義Web API或ASP.NET WebHost服務(wù)的一個(gè)容器運(yùn)行

    在該圖中需要強(qiáng)調(diào)的是我們將使用一個(gè)面向多個(gè)不同客戶端的自定義API網(wǎng)關(guān)服務(wù)。這可能是一個(gè)重要的風(fēng)險(xiǎn)，因?yàn)槟愕腁PI網(wǎng)關(guān)服務(wù)將根據(jù)客戶端需求的不斷增長(zhǎng)和發(fā)展，最終由于這些不同的需求，它將變得臃腫不堪，實(shí)際上它可能非常類似于單片應(yīng)用程序或單片服務(wù)。這就是為什么我們非常推薦將API網(wǎng)關(guān)拆分為多個(gè)服務(wù)或多個(gè)更小的API網(wǎng)關(guān)。

    在使用API網(wǎng)關(guān)模式時(shí)我們也要非常小心，通常使用單個(gè)API網(wǎng)關(guān)聚合應(yīng)用程序的所有內(nèi)部微服務(wù)不是一個(gè)好的實(shí)踐，因?yàn)橐坏┻@樣做了它就充當(dāng)一個(gè)整體聚合器或協(xié)調(diào)器并通過(guò)耦合所有微服務(wù)來(lái)違反微服務(wù)自治。因此API網(wǎng)關(guān)應(yīng)該基于業(yè)務(wù)邊界和客戶端應(yīng)用程序進(jìn)行隔離，而不是作為所有內(nèi)部微服務(wù)的單一聚合器。當(dāng)把API網(wǎng)關(guān)層分解為多個(gè)API網(wǎng)關(guān)時(shí), 如果你的應(yīng)用程序有多個(gè)客戶端, 這可以是一個(gè)主要的樞紐來(lái)識(shí)別多個(gè)API的網(wǎng)關(guān)類型，這樣你就可以有不同的外觀類來(lái)應(yīng)對(duì)每個(gè)客戶端的需求。這是我們稱之為“Backend for front-end”的模式(BFF)，其中每個(gè)API網(wǎng)關(guān)可以為每個(gè)客戶端提供不同的API，甚至可能基于客戶端的特定需求實(shí)現(xiàn)特定的適配器代碼，該代碼在下面調(diào)用多個(gè)內(nèi)部微服務(wù)，如下圖所示：

上圖展示了一個(gè)帶有多個(gè)細(xì)粒度API網(wǎng)關(guān)的簡(jiǎn)化體系結(jié)構(gòu)，在這種情況下識(shí)別每個(gè)API GateWay的邊界純粹是基于BFF的模式，因此只是基于每個(gè)客戶端提供各自所需的API，但在較大的應(yīng)用程序也應(yīng)該更進(jìn)一步，以創(chuàng)建基于業(yè)務(wù)邊界的網(wǎng)關(guān)作為第二設(shè)計(jì)衡量因素。

API網(wǎng)關(guān)模式中的主要特性 

  API網(wǎng)關(guān)可以根據(jù)產(chǎn)品的不同提供多種特性，它可能提供更豐富或更簡(jiǎn)單的特性，但是對(duì)于任何API網(wǎng)關(guān)來(lái)說(shuō)，最重要和基本的特性是以下設(shè)計(jì)方式：

反向代理或網(wǎng)關(guān)路由：API網(wǎng)關(guān)提供反向代理，將請(qǐng)求(通常是Http請(qǐng)求)重新定向或路由到內(nèi)部微服務(wù)的端點(diǎn)。網(wǎng)關(guān)為客戶端應(yīng)用程序提供一個(gè)endpoint或URL，然后在內(nèi)部將請(qǐng)求映射到一組內(nèi)部微服務(wù)。這個(gè)路由特性有助于從微服務(wù)的方式來(lái)解耦客戶端，而且也很方便在單一API和客戶端之間實(shí)現(xiàn)網(wǎng)關(guān)的控制，這樣的話你可以添加新的API作為新的microservices同時(shí)仍然使用遺留單一的API，直到它在未來(lái)被分成許多microservices。因?yàn)锳PI的網(wǎng)關(guān)的存在，客戶端應(yīng)用程序不會(huì)注意到所使用的API實(shí)現(xiàn)為內(nèi)部microservices或單一的API，當(dāng)在演進(jìn)和和重構(gòu)我們的單一API到 microservices的過(guò)程中因?yàn)橛辛薃PI網(wǎng)關(guān)路由的存在，才不會(huì)帶來(lái)Client請(qǐng)求的URI的變化。想了解更多網(wǎng)關(guān)路由的東西請(qǐng)戳這里。

請(qǐng)求聚合：作為網(wǎng)關(guān)模式的一部分，你可以將針對(duì)多個(gè)內(nèi)部微服務(wù)的多個(gè)客戶端請(qǐng)求(通常是Http請(qǐng)求)聚合到單個(gè)客戶端請(qǐng)求中。當(dāng)客戶端頁(yè)面需要調(diào)用來(lái)自多個(gè)微服務(wù)的數(shù)據(jù)時(shí)，這種模式特別方便。使用這種方法客戶端將發(fā)送一個(gè)請(qǐng)求到API網(wǎng)關(guān)，然后網(wǎng)關(guān)將負(fù)責(zé)發(fā)送多個(gè)請(qǐng)求來(lái)獲取內(nèi)部microservices然后聚合結(jié)果再發(fā)送回客戶端。這種設(shè)計(jì)模式的主要優(yōu)點(diǎn)和目標(biāo)是減少客戶端應(yīng)用程序和后端API之間的隔閡，對(duì)于微服務(wù)所在的數(shù)據(jù)中心之外的遠(yuǎn)程應(yīng)用程序來(lái)說(shuō)這一點(diǎn)尤為重要，比如移動(dòng)應(yīng)用程序或來(lái)自客戶端遠(yuǎn)程瀏覽器中的Javascript的SPA應(yīng)用程序的請(qǐng)求。對(duì)于在服務(wù)器環(huán)境中執(zhí)行請(qǐng)求的常規(guī)web應(yīng)用程序(如ASP)，這種模式并不重要，因?yàn)檠舆t比遠(yuǎn)程客戶機(jī)應(yīng)用程序要小得多。是否能夠執(zhí)行此聚合取決于你使用的API網(wǎng)關(guān)產(chǎn)品，然而在許多情況下，在API網(wǎng)關(guān)的范圍內(nèi)創(chuàng)建聚合微服務(wù)將會(huì)更加的靈活，所以你也可以在代碼中定義聚合(即c#代碼)。想了解更多請(qǐng)求聚合的東西請(qǐng)戳這里。

橫切關(guān)注點(diǎn)或網(wǎng)關(guān)卸載：根據(jù)每個(gè)API網(wǎng)關(guān)產(chǎn)品提供的特性，你可以將功能從單個(gè)微服務(wù)轉(zhuǎn)移到網(wǎng)關(guān)，通過(guò)將橫切關(guān)注點(diǎn)合并到一層來(lái)簡(jiǎn)化每個(gè)微服務(wù)的實(shí)現(xiàn)。這對(duì)于可以在每個(gè)內(nèi)部微服務(wù)(如以下功能)中正確實(shí)現(xiàn)的復(fù)雜的特殊功能來(lái)說(shuō)特別方便。

身份驗(yàn)證和授權(quán)
服務(wù)發(fā)現(xiàn)集成
響應(yīng)緩存
重試策略，斷路器和QoS。
速度限制和節(jié)流
負(fù)載平衡
日志記錄、跟蹤、相關(guān)性
頭文件、查詢字符串和聲明轉(zhuǎn)換
IP白名單

根據(jù)每個(gè)實(shí)現(xiàn)API網(wǎng)關(guān)產(chǎn)品可以提供更多的橫切關(guān)注點(diǎn)，但這些都是最常見(jiàn)的特性。例如Azure API管理提供了這些特性中的大部分，以及許多對(duì)商業(yè)API非常有用的高級(jí)特性。但是對(duì)于更簡(jiǎn)單的方法，像Ocelot這樣的輕量級(jí)API網(wǎng)關(guān)是相當(dāng)靈活的，因?yàn)槟憧梢詫⑺渴鸬侥闼x擇的環(huán)境和你的微服務(wù)。

看完上述內(nèi)容，你們掌握API網(wǎng)關(guān)模式怎么理解的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！