這篇文章主要介紹“API網(wǎng)關(guān)有哪些優(yōu)缺點(diǎn)”，在日常操作中，相信很多人在API網(wǎng)關(guān)有哪些優(yōu)缺點(diǎn)問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”API網(wǎng)關(guān)有哪些優(yōu)缺點(diǎn)”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

在萬(wàn)載等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專(zhuān)注、極致的服務(wù)理念，為客戶(hù)提供成都做網(wǎng)站、網(wǎng)站制作 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站設(shè)計(jì),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),網(wǎng)絡(luò)營(yíng)銷(xiāo)推廣,成都外貿(mào)網(wǎng)站建設(shè),萬(wàn)載網(wǎng)站建設(shè)費(fèi)用合理。

背景

理論上，客戶(hù)端可以直接向微服務(wù)發(fā)送請(qǐng)求，每個(gè)微服務(wù)都有一個(gè)公開(kāi)的URL，該URL將映射到微服務(wù)的負(fù)載均衡器，由它負(fù)責(zé)在可用實(shí)例之間分發(fā)請(qǐng)求。但這種方式存在如下缺陷：

1. 客戶(hù)端需求和微服務(wù)暴露的細(xì)粒度 API 不匹配

經(jīng)常有一個(gè)業(yè)務(wù)調(diào)用很多個(gè)服務(wù)，假如客戶(hù)端發(fā)送許多請(qǐng)求，這在公網(wǎng)上可能會(huì)很低效，而且會(huì)使客戶(hù)端代碼變得更復(fù)雜。

2. 服務(wù)使用的協(xié)議不是 Web 友好的

有的服務(wù)可能使用二進(jìn)制 RPC（比如 thrift），有的服務(wù)可能使用 AMQP 消息傳遞協(xié)議。不管哪種協(xié)議都不是瀏覽器友好或防火墻友好的，最好是內(nèi)部使用。在防火墻之外，應(yīng)用程序應(yīng)該使用諸如 HTTP 和 WebSocket 之類(lèi)的協(xié)議。

3. 難重構(gòu)

隨著時(shí)間推移可能想要更改系統(tǒng)劃分成服務(wù)的方式。例如，合并兩個(gè)服務(wù)或者將一個(gè)服務(wù)拆分成兩個(gè)或更多服務(wù)。如果客戶(hù)端與微服務(wù)直接通信，那么執(zhí)行這類(lèi)重構(gòu)就很困難。

由于以上問(wèn)題，客戶(hù)端與微服務(wù)直接通信很少是合理的，更好的方法是使用 API 網(wǎng)關(guān)，由 API 網(wǎng)關(guān)作為后端服務(wù)系統(tǒng)的唯一入口。它封裝了系統(tǒng)內(nèi)部架構(gòu)，為每個(gè)客戶(hù)端提供一個(gè)定制的 API 。由它負(fù)責(zé)服務(wù)請(qǐng)求路由、組合及協(xié)議轉(zhuǎn)換。有的 API 網(wǎng)關(guān)還有其它職責(zé)，如身份驗(yàn)證、監(jiān)控、負(fù)載均衡、緩存。

整體架構(gòu)

完備的服務(wù)網(wǎng)關(guān)應(yīng)該包括三大部分：API 網(wǎng)關(guān)、網(wǎng)關(guān)控制臺(tái)、度量數(shù)據(jù)采集分析。實(shí)際形態(tài)各異，可以按需搭建，但肯定少不了 API 網(wǎng)關(guān)，網(wǎng)關(guān)控制臺(tái)的功能職責(zé)可能會(huì)放到服務(wù)注冊(cè)等地方而沒(méi)有單獨(dú)抽取出來(lái)，至于度量數(shù)據(jù)采集可能會(huì)在整個(gè)微服務(wù)架構(gòu)中存一個(gè)通用的度量數(shù)據(jù)采集應(yīng)用以監(jiān)控所有類(lèi)型應(yīng)用。

API 網(wǎng)關(guān)的優(yōu)缺點(diǎn)

1. 優(yōu)點(diǎn)

封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)?？蛻?hù)端只需要同網(wǎng)關(guān)交互，而不必調(diào)用特定的服務(wù)。API 網(wǎng)關(guān)為每一類(lèi)客戶(hù)端提供了特定的 API ，從而減少客戶(hù)端與應(yīng)用程序間的交互次數(shù)，簡(jiǎn)化客戶(hù)端代碼的處理。

2. 缺點(diǎn)

增加了一個(gè)必須開(kāi)發(fā)、部署和維護(hù)的高可用組件。還有一個(gè)風(fēng)險(xiǎn)是 API 網(wǎng)關(guān)變成了開(kāi)發(fā)瓶頸。為了暴露每個(gè)微服務(wù)，開(kāi)發(fā)人員必須更新 API 網(wǎng)關(guān)。API 網(wǎng)關(guān)的更新過(guò)程要盡可能地簡(jiǎn)單，否則為了更新網(wǎng)關(guān)，開(kāi)發(fā)人員將不得不排隊(duì)等待。不過(guò)，雖然有這些不足，但對(duì)于大多數(shù)現(xiàn)實(shí)世界的應(yīng)用程序而言使用 API 網(wǎng)關(guān)是合理的。

實(shí)現(xiàn)的技術(shù)

1. 開(kāi)發(fā)語(yǔ)言

對(duì)于大多數(shù)應(yīng)用程序而言，API 網(wǎng)關(guān)的性能和可擴(kuò)展性通常都非常重要。因此，API 網(wǎng)關(guān)將構(gòu)建在一個(gè)支持異步、I/O 非阻塞的平臺(tái)上。Java系可以使用一種基于 NIO 的框架，比如Netty、Vertx、Spring Reactor ，還可以使用 Node.js、NGINX Plus。

2. 響應(yīng)式編程

API 網(wǎng)關(guān)通過(guò)簡(jiǎn)單地將請(qǐng)求路由給合適的后端服務(wù)來(lái)處理部分請(qǐng)求，而通過(guò)調(diào)用多個(gè)后端服務(wù)并合并結(jié)果來(lái)處理其它請(qǐng)求。對(duì)于沒(méi)有依賴(lài)關(guān)系的請(qǐng)求，API 網(wǎng)關(guān)應(yīng)該并發(fā)執(zhí)行以最小化響應(yīng)時(shí)間。使用傳統(tǒng)的異步回調(diào)方法編寫(xiě) API 組合代碼會(huì)陷入回調(diào)地獄。代碼會(huì)變得混亂、難以理解、容易出錯(cuò)?？梢允褂庙憫?yīng)式編程以一種聲明式樣式編寫(xiě)代碼。比如 Scala 中的Future 、Java 8 中的 CompletableFuture 和 JavaScript 中的 Promise ，還有最初是微軟為 .NET 平臺(tái)開(kāi)發(fā)的 Reactive Extensions（RX）。Netflix 創(chuàng)建了 RxJava for JVM ，專(zhuān)門(mén)用于他們的 API 網(wǎng)關(guān)。

3. 進(jìn)程通信模型

微服務(wù)的應(yīng)用程序必定是一個(gè)分布式系統(tǒng)，所以必須使用進(jìn)程間的通信機(jī)制。有兩種類(lèi)型的進(jìn)程間通信機(jī)制可供選擇。一種是使用異步的、基于消息傳遞的機(jī)制。有些實(shí)現(xiàn)使用諸如JMS 或 AMQP 那樣的消息代理，而其它的實(shí)現(xiàn)（如 Zeromq ）則沒(méi)有代理，服務(wù)間直接通信。另一種是諸如 HTTP 或 Thrift 那樣的同步機(jī)制。通常，一個(gè)系統(tǒng)會(huì)同時(shí)使用異步和同步兩種類(lèi)型。它甚至還可能使用同一類(lèi)型的多種實(shí)現(xiàn)?？傊?，API 網(wǎng)關(guān)需要支持多種通信機(jī)制。

4. 服務(wù)發(fā)現(xiàn)

API 網(wǎng)關(guān)需要知道它與之通信的每個(gè)微服務(wù)的位置（IP 地址和端口）。應(yīng)用程序服務(wù)的位置是動(dòng)態(tài)分配的。而且，單個(gè)服務(wù)的一組實(shí)例也會(huì)隨著自動(dòng)擴(kuò)展或升級(jí)而動(dòng)態(tài)變化。API 網(wǎng)關(guān)需要使用系統(tǒng)的服務(wù)發(fā)現(xiàn)機(jī)制，可以是服務(wù)器端發(fā)現(xiàn)，也可以是客戶(hù)端發(fā)現(xiàn)。如果系統(tǒng)使用客戶(hù)端發(fā)現(xiàn)，那么 API 網(wǎng)關(guān)必須能夠查詢(xún)服務(wù)注冊(cè)中心，這是一個(gè)包含所有微服務(wù)實(shí)例及其位置的數(shù)據(jù)庫(kù)。

Spring cloud 提供了服務(wù)注冊(cè)和發(fā)現(xiàn)功能，如果需要自己實(shí)現(xiàn)，可以考慮用 Zookeeper 作為注冊(cè)表，客戶(hù)端用 Curator 。

5. 局部失敗

在實(shí)現(xiàn) API 網(wǎng)關(guān)時(shí)，還有一個(gè)問(wèn)題需要處理，就是局部失敗的問(wèn)題。該問(wèn)題在所有的分布式系統(tǒng)中都會(huì)出現(xiàn)，無(wú)論什么時(shí)候，當(dāng)一個(gè)服務(wù)調(diào)用另一個(gè)響應(yīng)慢或不可用的服務(wù)，就會(huì)出現(xiàn)這個(gè)問(wèn)題。API 網(wǎng)關(guān)永遠(yuǎn)不能因?yàn)闊o(wú)限期地等待下游服務(wù)而阻塞。不過(guò)，如何處理失敗取決于特定的場(chǎng)景以及哪個(gè)服務(wù)失敗。如果緩存數(shù)據(jù)可用，那么 API 網(wǎng)關(guān)還可以返回緩存數(shù)據(jù)。數(shù)據(jù)可以由API網(wǎng)關(guān)自己緩存，也可以存儲(chǔ)在像 redis 或 Memcached 那樣的外部緩存中。通過(guò)返回默認(rèn)數(shù)據(jù)或者緩存數(shù)據(jù)，API 網(wǎng)關(guān)可以確保系統(tǒng)故障不影響用戶(hù)的體驗(yàn)。

在編寫(xiě)代碼調(diào)用遠(yuǎn)程服務(wù)方面，Netflix Hystrix 是一個(gè)異常有用的庫(kù)。Hystrix 會(huì)將超出設(shè)定閥值的調(diào)用超時(shí)。它實(shí)現(xiàn)了一個(gè)“斷路器（circuit breaker）”模式，可以防止客戶(hù)端對(duì)無(wú)響應(yīng)的服務(wù)進(jìn)行不必要的等待。如果服務(wù)的錯(cuò)誤率超出了設(shè)定的閥值，那么 Hystrix 會(huì)切斷斷路器，在一個(gè)指定的時(shí)間范圍內(nèi)，所有請(qǐng)求都會(huì)立即失敗。Hystrix 允許用戶(hù)定義一個(gè)請(qǐng)求失敗后的后援操作，比如從緩存讀取數(shù)據(jù)，或者返回一個(gè)默認(rèn)值。如果你正在使用 JVM，那么你絕對(duì)應(yīng)該考慮使用 Hystrix 。而如果你正在使用一個(gè)非 JVM 環(huán)境，那么你應(yīng)該使用一個(gè)等效的庫(kù)。

6.參考實(shí)現(xiàn)方案

以上列出在 DIY 這個(gè) API 網(wǎng)關(guān)時(shí)需要考慮的點(diǎn)，以及參考的技術(shù)實(shí)現(xiàn)。下面是幾種目前比較流行的 API 網(wǎng)關(guān)搭建的技術(shù)方案供參考，后續(xù)文章將給出這些方案搭建的例子

1）Nginx + Lua實(shí)現(xiàn)負(fù)載均衡、限流、服務(wù)發(fā)現(xiàn)等功能

2）使用 spring cloud 技術(shù)棧，其中 zuul 就是用作 API 網(wǎng)關(guān)的

3）Mashape 的開(kāi)源 API 網(wǎng)關(guān) Kong

7.網(wǎng)關(guān)控制臺(tái)

提供 domain 管理、應(yīng)用管理、服務(wù)授權(quán)、服務(wù)監(jiān)控、統(tǒng)計(jì)和度量數(shù)據(jù)展示、查看服務(wù)全局視圖等功能。服務(wù)消費(fèi)者和服務(wù)提供者都要在網(wǎng)關(guān)控制臺(tái)進(jìn)行應(yīng)用注冊(cè)，控制臺(tái)為每個(gè)應(yīng)用分配應(yīng)用id(appId唯一)和應(yīng)用密鑰(appSecret)。注冊(cè)時(shí)需要提供的信息：應(yīng)用名稱(chēng)、應(yīng)用描述、應(yīng)用負(fù)責(zé)人相關(guān)信息。

到此，關(guān)于“API網(wǎng)關(guān)有哪些優(yōu)缺點(diǎn)”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！

文章名稱(chēng)：API網(wǎng)關(guān)有哪些優(yōu)缺點(diǎn)
標(biāo)題網(wǎng)址：http://aaarwkj.com/article42/gpgdec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開(kāi)發(fā)、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站策劃、自適應(yīng)網(wǎng)站、網(wǎng)站建設(shè)、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)