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

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

背景

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

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

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

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

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

3. 難重構(gòu)

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

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

整體架構(gòu)

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

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

1. 優(yōu)點

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

2. 缺點

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

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

1. 開發(fā)語言

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

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

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

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

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

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

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

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

5. 局部失敗

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

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

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

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

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

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

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

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

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

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

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

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

廣告

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