設(shè)計模式中有一種責(zé)任鏈模式，它將“處理請求”和“處理步驟”分開。每個處理步驟，只關(guān)心這個步驟上需要做的處理操作，處理步驟存在先后順序。

消息從第一個“處理步驟”流入，從最后一個“處理步驟”流出，每個步驟對經(jīng)過的消息進(jìn)行處理，整個過程形成了一個鏈條。在 API 網(wǎng)關(guān)中也用到了類似的模式。

Zuul 網(wǎng)關(guān)過濾器鏈?zhǔn)教幚?/p>

下面以 Zuul 為例，當(dāng)消息出入網(wǎng)關(guān)需要經(jīng)歷一系列的過濾器。這些過濾器之間是有先后順序的，并且在每個過濾器需要進(jìn)行的工作也是各不一樣：

異步請求

所有的請求通過 API 網(wǎng)關(guān)訪問應(yīng)用服務(wù)，一旦吞吐量上去了，如何高效地處理這些請求？

拿 Zuul 為例，Zuul1 采用：一個線程處理一個請求的方式。線程負(fù)責(zé)接受請求，然后調(diào)用應(yīng)用返回結(jié)果。

如果把網(wǎng)絡(luò)請求看成一次 IO 操作的話，處理請求的線程，從接受請求，到服務(wù)返回響應(yīng)，都是阻塞狀態(tài)。

同時，如果多個線程都處在這種狀態(tài)，會導(dǎo)致系統(tǒng)緩慢。因為每個網(wǎng)關(guān)能夠開啟的線程數(shù)量是有限的，特別是在訪問的高峰期。

每個線程處理一個請求

為了解決這個問題，Zuul2 啟動了異步請求的機(jī)制。每個請求進(jìn)入網(wǎng)關(guān)的時候，會被包裝成一個事件，CPU 內(nèi)核會維持一個監(jiān)聽器，不斷輪詢“請求事件”。

一旦，發(fā)現(xiàn)請求事件，就會調(diào)用對應(yīng)的應(yīng)用。獲取應(yīng)用返回的信息以后，按照請求的要求把數(shù)據(jù)/文件放到指定的緩沖區(qū)，同時發(fā)送一個通知事件，告訴請求端數(shù)據(jù)已經(jīng)就緒，可以從這個緩沖獲取數(shù)據(jù)/文件。

這個過程是異步的，請求的線程不用一直等待數(shù)據(jù)的返回。它在請求完畢以后，就直接返回了，這時它可以做其他的事情。

請求數(shù)據(jù)被 CPU 內(nèi)核獲取，并且發(fā)送到指定的數(shù)據(jù)緩沖區(qū)時，請求的線程會接到“數(shù)據(jù)返回”的通知，然后就直接使用數(shù)據(jù)，不用自己去做取數(shù)據(jù)的操作。

異步請求處理，CPU 處理數(shù)據(jù)以后通知請求端

實現(xiàn)異步處理請求有兩種模式，分別是：

Reactor 工作原理流水圖

Reactor：通過 handle_events 事件循環(huán)處理請求。用戶線程注冊事件處理器之后，可以繼續(xù)執(zhí)行其他的工作（異步），而 Reactor 線程負(fù)責(zé)調(diào)用內(nèi)核的 Select 函數(shù)檢查 Socket 狀態(tài)。

當(dāng)有 Socket 被激活時（獲取網(wǎng)絡(luò)數(shù)據(jù)），則通知相應(yīng)的用戶線程，執(zhí)行 handle_event 進(jìn)行數(shù)據(jù)讀取、處理的工作。

Proactor 工作原理流水圖

Proactor：用戶線程使用 CPU 內(nèi)核提供的異步 IO 發(fā)起請求，請求發(fā)起以后立即返回。CPU 內(nèi)核繼續(xù)執(zhí)行用戶請求線程代碼。

此時用戶線程已將 AsynchronousOperation（異步處理）和 CompletionHandler（完成獲取資源）注冊到內(nèi)核。之后操作系統(tǒng)開啟獨立的內(nèi)核線程去處理 IO 操作。

當(dāng)請求的數(shù)據(jù)到達(dá)時，由內(nèi)核負(fù)責(zé)讀取 Socket（網(wǎng)絡(luò)請求）中的數(shù)據(jù)，并寫入用戶指定的緩沖區(qū)中。

最后內(nèi)核將數(shù)據(jù)和用戶線程注冊的 CompletionHandler 分發(fā)給內(nèi)部 Proactor，Proactor 將 IO 完成的信息通知給用戶線程（一般通過調(diào)用用戶線程注冊的完成事件處理函數(shù)），完成異步 IO。

API 網(wǎng)關(guān)實現(xiàn)功能

說起對 API 網(wǎng)關(guān)的使用，我們還是對具體功能更加感興趣。讓我們一起來看看它實現(xiàn)了哪些功能。

負(fù)載均衡

當(dāng)網(wǎng)關(guān)后面掛接同一應(yīng)用的多個副本時，每次用戶的請求都會通過網(wǎng)關(guān)的負(fù)載均衡算法，路由到對應(yīng)的服務(wù)上面。例如：隨機(jī)算法，權(quán)重算法，Hash 算法等等。

如果上游服務(wù)采取微服務(wù)的架構(gòu)，也可以和注冊中心合作實現(xiàn)動態(tài)的負(fù)載均衡。

當(dāng)微服務(wù)動態(tài)掛載（動態(tài)擴(kuò)容）的時候，可以通過服務(wù)注冊中心獲取微服務(wù)的注冊信息，從而實現(xiàn)負(fù)載均衡。

Nginx+Lua+服務(wù)注冊中心實現(xiàn)動態(tài)負(fù)載均衡

路由選擇

這個不言而喻，網(wǎng)關(guān)可以根據(jù)請求的 URL 地址解析，知道需要訪問的服務(wù)。再通過路由表把請求路由到目標(biāo)服務(wù)上去。

有時候因為網(wǎng)絡(luò)原因，服務(wù)可能會暫時的不可用，這個時候我們希望可以再次對服務(wù)進(jìn)行重試。

Zuul 作為 API 網(wǎng)關(guān)將請求路由到上游服務(wù)器

例如：Zuul 與 Spring Retry 合作完成路由重試。

流量控制

限流是 API 網(wǎng)關(guān)常用的功能之一，當(dāng)上游服務(wù)超出請求承載范圍，或者服務(wù)因為某種原因無法正常使用，都會導(dǎo)致服務(wù)處理能力下滑。

這個時候，API 網(wǎng)關(guān)作為“看門人”，就可以限制流入的請求，讓應(yīng)用服務(wù)器免受沖擊。

限流實際上就是限制流入請求的數(shù)量，其算法不少，有令牌桶算法，漏桶算法，連接數(shù)限制等等。這里我們就介紹三個常用的，一般通過 Nginx+Lua 來實現(xiàn)。

令牌桶限流

統(tǒng)一鑒權(quán)

訪問應(yīng)用服務(wù)器的請求都需要擁有一定權(quán)限，如果說每訪問一個服務(wù)都需要驗證一次權(quán)限，這個對效率是很大的影響?？梢园褭?quán)限認(rèn)證放到 API 網(wǎng)關(guān)來進(jìn)行。

目前比較常見的做法是，用戶通過登錄服務(wù)獲取 Token，把它存放到客戶端，在每次請求的時候把這個 Token 放入請求頭，一起發(fā)送給服務(wù)器。

API 網(wǎng)關(guān)要做的事情就是解析這個 Token，知道訪問者是誰（鑒定），他能做什么/訪問什么（權(quán)限）。

說白了就是看訪問者能夠訪問哪些 URL，這里根據(jù)權(quán)限/角色定義一個訪問列表。

如果要實現(xiàn)多個系統(tǒng)的 OSS（Single Sign On 單點登錄），API 網(wǎng)關(guān)需要和 CAS（Central Authentication Service 中心鑒權(quán)服務(wù)）做連接，來確定請求者的身份和權(quán)限。

熔斷降級

當(dāng)應(yīng)用服務(wù)出現(xiàn)異常，不能繼續(xù)提供服務(wù)的時候，也就是說應(yīng)用服務(wù)不可用了。作為 API 網(wǎng)關(guān)需要做出處理，把請求導(dǎo)入到其他服務(wù)上。

或者對服務(wù)進(jìn)行降級處理，例如：用兜底的服務(wù)數(shù)據(jù)返回客戶端，或者提示服務(wù)暫時不可用。

同時通過服務(wù)注冊中心，監(jiān)聽存在問題的服務(wù)，一旦服務(wù)恢復(fù)，隨即恢復(fù)路由請求到該服務(wù)。

例如：Zuul 中提供了 ZuulFallbackProvider 接口來實現(xiàn)熔斷，它提供兩個方法，一個指明熔斷攔截的服務(wù) getRoute，一個指定返回內(nèi)容 ClientHttpResponse。

我們通過自定義的 Fallback 方法，并且將其指定給某個 Route 來實現(xiàn)該 Route 訪問出問題的熔斷處理。

主要繼承 ZuulFallbackProvider 接口來實現(xiàn)，ZuulFallbackProvider 默認(rèn)有兩個方法，一個用來指明熔斷攔截哪個服務(wù)，一個定制返回內(nèi)容。

API 網(wǎng)關(guān)熔斷降級

發(fā)布測試

在發(fā)布版本的時候會采用：金絲雀發(fā)布和藍(lán)綠發(fā)布。作為 API 網(wǎng)關(guān)可以使用路由選擇和流量切換來協(xié)助上述行為。這里以金絲雀發(fā)布為例，看看 API 網(wǎng)關(guān)如何做路由轉(zhuǎn)換的。

假設(shè)將 4 個服務(wù)從 V1 更新到 V2 版本，這 4 個服務(wù)的流量請求由 1 個 API 網(wǎng)關(guān)管理。

那么先將一臺服務(wù)與 API 網(wǎng)關(guān)斷開，部署 V2 版本的服務(wù)，然后 API 網(wǎng)關(guān)再將流量導(dǎo)入到 V2 版本的服務(wù)上。

這里流量的導(dǎo)入可以是逐步進(jìn)行的，一旦 V2 版本的服務(wù)趨于穩(wěn)定。再如法炮制，將其他服務(wù)替換成 V2 版本。

金絲雀發(fā)布一般先發(fā) 1 臺，或者一個小比例，例如 2% 的服務(wù)器，主要做流量驗證用，也稱為金絲雀（Canary）測試（灰度測試）

其來歷是，曠工下礦洞前，先放一只金絲雀探查是否有毒氣，金絲雀發(fā)布由此得名。

金絲雀測試需要完善的監(jiān)控設(shè)施配合，通過監(jiān)控指標(biāo)反饋，觀察金絲雀的健康狀況，作為后續(xù)發(fā)布或回滾的依據(jù)。

如果金絲測試通過，則把剩余的 V1 版本全部升級為 V2 版本。如果金絲雀測試失敗，則直接回退金絲雀，發(fā)布失敗。

緩存數(shù)據(jù)

我們可以在 API 網(wǎng)關(guān)緩存一些修改頻率不高的數(shù)據(jù)。例如：用戶信息，配置信息，通過服務(wù)定期刷新這個緩存就行了：

日志記錄

通過 API 網(wǎng)關(guān)上的過濾器我們可以加入日志服務(wù)，記錄請求和返回信息。同時可以建立一個管理員的界面去監(jiān)控這些數(shù)據(jù)。

日志服務(wù)簡圖

日志記錄了以后，可以做很多功能擴(kuò)展。我們整理了以下幾點供大家參考：

日志記錄衍生的功能

流行 API 網(wǎng)關(guān)對比

在介紹了 API 網(wǎng)關(guān)的功能以后，再來看看目前幾個流行的 API 網(wǎng)關(guān)項目?？纯此麄兏髯缘奶攸c，并且把他們做一個簡單的比較。這些網(wǎng)關(guān)目前都是開源的，大家可以有選擇地在項目中使用。

Kong

Kong 是 Mash ape 公司的開源項目，它是一個在 Nginx 中運行的 Lua 應(yīng)用程序，并且可以通過 Lua-Nginx 模塊實現(xiàn)擴(kuò)展。

所以，可以通過插件集合的方式定制功能，例如：HTTP 基本認(rèn)證、密鑰認(rèn)證、CORS（Cross-origin Resource Sharing，跨域資源共享）、TCP、UDP、日志、API 限流、請求轉(zhuǎn)發(fā)以及監(jiān)控，都是目前已有的插件。

由于是基于 Nginx 的，所以可以對網(wǎng)關(guān)進(jìn)行水平擴(kuò)展，來應(yīng)對大批量的網(wǎng)絡(luò)請求。

Kong 架構(gòu)圖

Kong 主要有三個組件：

Traefik

Traefik 架構(gòu)圖

Traefik 是 HTTP 反向代理和負(fù)載均衡器，可以輕松部署微服務(wù)，可以與現(xiàn)有的組件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd）做集成。

因為支持動態(tài)配置，所以它的伸縮性很好。不過它只支持 HTTP、HTTPS 和 GRPC。如果你需要 TCP 負(fù)載均衡，那么您需要選擇其他方案了。

Ambassador

Ambassador 架構(gòu)圖

Ambassador 是一個基于 Envoy Proxy 構(gòu)建的，Kubernetes 原生的開源微服務(wù)網(wǎng)關(guān)。

它在構(gòu)建之初就致力于支持多個獨立的團(tuán)隊，這些團(tuán)隊需要為最終用戶快速發(fā)布、監(jiān)控和更新服務(wù)。

Ambassador 還具有 Kubernetes Ingress 和負(fù)載均衡的能力。它支持處理 Kubernetes Ingress Controller 和負(fù)載均衡等功能，可以與 Istio 無縫集成。

Zuul

Zuul 2 結(jié)構(gòu)圖

Zuul 是 Spring Cloud 全家桶中的微服務(wù) API 網(wǎng)關(guān)。所有從設(shè)備或網(wǎng)站來的請求都會經(jīng)過 Zuul 到達(dá)后端的 Netflix 應(yīng)用程序。

作為一個邊界性質(zhì)的應(yīng)用程序，Zuul 提供了動態(tài)路由、監(jiān)控、彈性負(fù)載和安全功能。包括 Zuul1 和 Zuul2 兩個版本。

介紹了幾個開源 API 網(wǎng)關(guān)的基本信息以后，我們從幾個維度對他們進(jìn)行比較：

從開源社區(qū)活躍度來說，Kong 和 Traefik 較好；從成熟度來看，較好的是 Kong、Traefik；從架構(gòu)優(yōu)勢的擴(kuò)展性來看，Kong 有豐富的插件，Ambassador 也有插件但不多，而 Zuul 是需要自研。

但 Zuul 由于與 Spring Cloud 集成，如果使用 Spring Cloud 的小伙伴可以考慮使用。

總結(jié)

API 網(wǎng)關(guān)是系統(tǒng)內(nèi)外通訊的中介者。從定位上來說它服務(wù) WebApp，MobileApp，合作伙伴 OpenAPI，企業(yè)內(nèi)部可擴(kuò)展 API，以及 IOT 設(shè)備。

從架構(gòu)設(shè)計角度來說，分為 Gateway-Core（核心）、Gateway-Admin（管理）、Gateway-Monitor（監(jiān)控）三部分。

API 網(wǎng)關(guān)需要注意的技術(shù)原理有，協(xié)議轉(zhuǎn)換，鏈?zhǔn)教幚硪约爱惒秸埱?。它的?yīng)用比較廣泛，例如：負(fù)載均衡，路由選擇，流量控制，統(tǒng)一鑒權(quán)，熔斷降級，發(fā)布測試，緩存數(shù)據(jù)，日志記錄等。

比較流行的開源 API網(wǎng)關(guān)有 Kong，Traefik，Ambassador，Zuul。從使用上來說他們各有千秋，可以根據(jù)項目的情況選取。

天天寫CRUD的你，到了該給系統(tǒng)接入API網(wǎng)關(guān)的時候了

今天給大家分享一個API網(wǎng)關(guān)的知識，很多兄弟可能平時經(jīng)常搞的都是一些CRUD的業(yè)務(wù)系統(tǒng)開發(fā)，從來沒接觸過API網(wǎng)關(guān)，那今天來講講，API網(wǎng)關(guān)是啥，到底能對我們起到什么作用呢？這個一般面試的時候也很可能會問到這個知識點的。

先來看看業(yè)務(wù)系統(tǒng)技術(shù)棧

平時咱們可能寫系統(tǒng)的時候，往往就是基于spring boot+spring mvc+spring+mybatis這套技術(shù)棧來開發(fā)業(yè)務(wù)代碼，然后連接一個mysql就行了，你調(diào)用別的系統(tǒng)往往就是基于dubbo，注冊中心可能是zookeeper也可能是nacos，就類似下面的這個圖，對不對？

網(wǎng)關(guān)路由請求轉(zhuǎn)發(fā)功能

好，那么現(xiàn)在給大家講第一個痛點，那就是你們公司可能存在n多個業(yè)務(wù)系統(tǒng)，那琳瑯滿目的，可能有幾十個系統(tǒng)，此時對于前端/APP端他們還能知道哪個請求發(fā)送給哪個系統(tǒng)嗎，這真的是太麻煩了，對不對，所以說，此時一般會引入一個API網(wǎng)關(guān)。

你每個業(yè)務(wù)系統(tǒng)吧，在API網(wǎng)關(guān)里配置一下，自己要處理什么樣的請求url，然后API網(wǎng)關(guān)收到請求以后，根據(jù)請求url路徑判斷一下，就知道應(yīng)該把請求轉(zhuǎn)發(fā)給哪個業(yè)務(wù)系統(tǒng)了，完美，對不對？看看下圖吧。

網(wǎng)關(guān)統(tǒng)一授權(quán)和鑒權(quán)功能

下一個問題來了，你這個系統(tǒng)能允許別人誰來都隨便調(diào)用你嗎？你不得搞一個授權(quán)和鑒權(quán)的過程？你不得甄別甄別發(fā)送請求來的這個人是好人壞人？你不得想想發(fā)送過來的這個請求到底應(yīng)該不應(yīng)該處理嗎？所以這個時候這個鑒權(quán)的事情你自己搞嗎？那太麻煩了吧，你也鑒權(quán)，別的系統(tǒng)自己也鑒權(quán)，那真的是麻煩大了。

所以這個時候，我們就直接在API網(wǎng)關(guān)里加入鑒權(quán)功能不就完了，一個請求過來是好人還是壞人，API網(wǎng)關(guān)就幫你鑒權(quán)了，通過鑒權(quán)的請求才能往后端發(fā)送，如下圖。

API網(wǎng)關(guān)層流控功能

再下一個痛點來了，那就是假設(shè)咱們系統(tǒng)一共就部署了幾臺機(jī)器，總共每秒幾千請求了不得了，結(jié)果有一天運營搞了一個特別棒的活動，每秒來了幾萬流量和請求，一下子給你擊垮了，你說你怎么辦，你扛不住啊？所以這個時候啊，還得在API網(wǎng)關(guān)層加入流控的功能，每個業(yè)務(wù)系統(tǒng)可以配置自己能抗的QPS，他根據(jù)這個來限制每秒轉(zhuǎn)發(fā)給你的請求不就完了，如下圖。

API網(wǎng)關(guān)層灰度發(fā)布功能

然后呢，還有一個經(jīng)常遇到的痛點，那就是咱們每次系統(tǒng)上線部署，如果一下子把新的版本部署到所有機(jī)器里去，就怕新版本上線就掉倆字，直接就崩潰，這可怎么辦。所以一般來說，可以引入一個灰度發(fā)布，這個灰度發(fā)布意思就是說，假設(shè)你系統(tǒng)部署了3臺機(jī)器，每次上線先部署1臺機(jī)器，然后線上的流量里劃分5%給這個新部署的灰度版本機(jī)器，先觀察一下咋樣，要是沒問題，再把后續(xù)兩臺機(jī)器給部署了，這就是灰度發(fā)布。

灰度發(fā)布也可以叫做金絲雀發(fā)布，這個金絲雀發(fā)布是啥意思呢，就是以前古代有盜版的人下墓的時候先把金絲雀扔進(jìn)去看看，如果他不叫了，說明墓里有毒氣，現(xiàn)在這個灰度發(fā)布也是一個意思，先把新版本部署到一臺機(jī)器里去，觀察一下，要是他崩了，就說明代碼有問題。

所以此時就可以基于API網(wǎng)關(guān)來實現(xiàn)灰度發(fā)布了，每次部署了灰度版本以后，讓API網(wǎng)關(guān)就劃分5%的流量給這個灰度版本，一切正常了再全量部署，如下圖。

好了，到這里為止，就給大家把這個API網(wǎng)關(guān)的作用講清楚了，大家平時不要老是埋頭寫crud代碼啊，對API網(wǎng)關(guān)這些東西，也是要了解一下的，別啥都不知道。

私信 "面試 " 免費 領(lǐng)取600+ 頁石杉老師原創(chuàng)精品文章匯總PDF

600+頁石杉老師原創(chuàng)文章

相關(guān)問答

有沒有考慮用jfinal來做一個api網(wǎng)關(guān)呢?-OSCHINA

建議樓主把api網(wǎng)關(guān)要解決哪些問題盡量詳細(xì)地列一下。不然誰都不知道api網(wǎng)關(guān)是啥。如果只是接受restful的url返回json的模式,連jfinal都不用了,直接servelt上用...

微服務(wù)架構(gòu)實踐(APIGateway)-OSCHINA-中文開源技術(shù)交流社區(qū)

我們就需要:API網(wǎng)關(guān)(APIGateway)。API網(wǎng)關(guān)模式意味著你要把API網(wǎng)關(guān)放到你的微服務(wù)們的最前端,并且要讓API網(wǎng)關(guān)變成由應(yīng)用所發(fā)起的每個請求的入口,這樣就...

F5推出的API網(wǎng)關(guān)防護(hù)解決方案怎么樣?-ZOL問答

F5API網(wǎng)關(guān)防護(hù)解決方案(包括了F5APM、AdvancedWAF產(chǎn)品)同樣支持BIGDATAEngine解決方案,可以基于硬件,虛擬化實例(VE)的形態(tài)部署于傳統(tǒng)環(huán)境、虛擬化環(huán)境...

API網(wǎng)關(guān)與高性能服務(wù)最佳實踐丨OpenTalk廣州站-OSCHINA...

ApacheAPISIX社區(qū)聯(lián)合又拍云,邀請業(yè)內(nèi)資深的Nginx、Envoy、API網(wǎng)關(guān)、微服務(wù)、ServiceMesh等方面的技術(shù)專家,分享網(wǎng)關(guān)和高性能服務(wù)的實戰(zhàn)經(jīng)驗,推動這些開源...

微服務(wù)網(wǎng)關(guān)和api網(wǎng)關(guān)區(qū)別?

[最佳回答]答:api網(wǎng)關(guān)和微服務(wù)網(wǎng)關(guān)的區(qū)別如下。1.部署位置不同微服務(wù)網(wǎng)關(guān)主要是部署在內(nèi)網(wǎng),作為微服務(wù)內(nèi)部API的通訊。企業(yè)級應(yīng)用網(wǎng)關(guān)一般部署在DMZ區(qū)域或者在藏在負(fù)...

如何架構(gòu)一個合適的企業(yè)API網(wǎng)關(guān)?

[最佳回答]在我們講的微服務(wù)架構(gòu)下的API網(wǎng)關(guān),一般指的是前三類使用場景。即,主要是把企業(yè)內(nèi)部的API能力,暴露給其他應(yīng)用或合作伙伴使用。網(wǎng)關(guān)層作為客戶端與服務(wù)端的一層...

sdk和api網(wǎng)關(guān)區(qū)別?

[最佳回答]api網(wǎng)關(guān)API網(wǎng)關(guān)是一個服務(wù)器,是系統(tǒng)的唯一入口。從面向?qū)ο笤O(shè)計的角度看,它與外觀模式類似。API網(wǎng)關(guān)封裝了系統(tǒng)內(nèi)部架構(gòu),為每個客戶端提供一個定制的API。...

KongAPI網(wǎng)關(guān)的使用-OSCHINA-中文開源技術(shù)交流社區(qū)

配置如下:1、添加到APIS信息:{"upstream_url":"https://www.sdk.cn/news/1596","s...

網(wǎng)關(guān)api是啥?

[最佳回答]API網(wǎng)關(guān)是微服務(wù)架構(gòu)(MicroservicesArchitecture)標(biāo)準(zhǔn)化服務(wù)的模式。API網(wǎng)關(guān)定位為應(yīng)用系統(tǒng)服務(wù)接口的網(wǎng)關(guān),區(qū)別于網(wǎng)絡(luò)技術(shù)的網(wǎng)關(guān),但是原理則是一樣。API網(wǎng)...

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

[最佳回答]1.防止內(nèi)部關(guān)注暴露給外部客戶端API網(wǎng)關(guān)將外部公共API與內(nèi)部微服務(wù)API分開,允許添加微服務(wù)和更改邊界。其結(jié)果是能夠在不對外部綁定客戶端產(chǎn)生負(fù)面影響的情況...