在微服務(wù)架構(gòu)風(fēng)格中，一個(gè)大應(yīng)用通常會(huì)被拆分成為了多個(gè)小的服務(wù)系統(tǒng)提供出來，這些小的系統(tǒng)他們可以自成體系，也就是說這些小系統(tǒng)可以擁有自己的數(shù)據(jù)庫，框架甚至語言等，這些小系統(tǒng)通常以提供 Rest Api 風(fēng)格的接口來被 H5, Android, IOS 以及第三方應(yīng)用程序調(diào)用。

我們通常需要在一個(gè)界面上展示很多數(shù)據(jù)，這些數(shù)據(jù)可能來自于不同的微服務(wù)中，比如在一個(gè)電商系統(tǒng)中，查看一個(gè)商品詳情頁，這個(gè)商品詳情頁包含商品的標(biāo)題，價(jià)格，庫存，評(píng)論等，這些數(shù)據(jù)對(duì)于后端來說可能是位于不同的微服務(wù)系統(tǒng)之中。我們要如何從這些微服務(wù)中拉取相應(yīng)的信息回來呢？

基于以上背景，在微服務(wù)架構(gòu)中，我們可能會(huì)遇到一下問題：

• 服務(wù)的劃分可能隨著時(shí)間或者需求變更而變化
• 服務(wù)實(shí)例會(huì)動(dòng)態(tài)變化
• 服務(wù)的API粒度，相對(duì)而言在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都只提供相對(duì)細(xì)粒度的API
• 不同的客戶端（H5,App等）可能需要不同的數(shù)據(jù)

這種情況下，我們就需要：API 網(wǎng)關(guān)（API Gateway）。API 網(wǎng)關(guān)模式意味著你要把API 網(wǎng)關(guān)放到你的微服務(wù)們的最前端，并且要讓 API 網(wǎng)關(guān)變成由應(yīng)用所發(fā)起的每個(gè)請(qǐng)求的入口，這樣就可以明顯的簡化客戶端實(shí)現(xiàn)和微服務(wù)應(yīng)用程序之間的溝通方式。

API 網(wǎng)關(guān)

API Gateway 可以分為兩種：

1.單節(jié)點(diǎn) API Gateway

2.BFF(Backends for frontends) Gateway

API 網(wǎng)關(guān)職責(zé)

在我們內(nèi)部，API 網(wǎng)關(guān)需要承擔(dān)包括但不限于下面的這些職責(zé)：

1.請(qǐng)求路由，版本控制

API Gateway 是微服務(wù)的入口，可以根據(jù)不同的請(qǐng)求路由到不同的服務(wù)上，也可以在 Gateway 上進(jìn)行路由的版本控制，這樣即使后服務(wù)發(fā)生了變化，Gateway 的路徑依然可以不改變。

2.用戶登錄，權(quán)限認(rèn)證

客戶端在與我們后端服務(wù)進(jìn)行交互之前，需要先進(jìn)行登錄鑒權(quán)操作，這是后端所有的服務(wù)都需要有的共有邏輯，因此在 Gateway 做這個(gè)事情就再合適不過。

3.數(shù)據(jù)聚合

由于不同的客戶端往往需要的數(shù)據(jù)完全不同，而這些數(shù)據(jù)又是不同的 service 提供的，比如上面提到的查看一個(gè)商品詳情頁，我們可能需要同時(shí)從商品服務(wù)，庫存服務(wù)，評(píng)價(jià)服務(wù)等中拉取信息，我們可以借助 Gateway 方便完成來自不同 service 的數(shù)據(jù)聚合。

4.協(xié)議轉(zhuǎn)換

在我們的實(shí)踐中，CS（Client to Server）協(xié)議和SS（Server to Server）協(xié)議是不一樣的，為了保證數(shù)據(jù)傳輸?shù)目煽啃裕覀兊腃S協(xié)議會(huì)有鑒權(quán)以及加密解密的邏輯，而在內(nèi)部的SS協(xié)議則不需要這些邏輯，因此在 Gateway 我們需要有一個(gè)協(xié)議轉(zhuǎn)換的過程。

5.熔斷，降級(jí)，限流

當(dāng)監(jiān)測到某個(gè)服務(wù)發(fā)生異常，或者當(dāng)服務(wù)的流量超過我們服務(wù)的承載能力等情況時(shí)，我們可以采取相應(yīng)的措施，對(duì)整個(gè)系統(tǒng)的容錯(cuò)性、穩(wěn)定性有很大幫助。

6.負(fù)載均衡

API 網(wǎng)關(guān)知道所有服務(wù)實(shí)例的地址，所以可以根據(jù)不同服務(wù)采取不同的負(fù)載均衡策略。

7.灰度發(fā)布

有時(shí)候我不希望讓所有的流量都一次性的到達(dá)程序的新版本，因?yàn)槟莻€(gè)新版本也許并沒有測試地很充分。灰度發(fā)布允許你直接只導(dǎo)入指定量的流量到新的版本，API 網(wǎng)關(guān)就可以幫你來做這件事情。你可以配置10%的請(qǐng)求到新的版本，然后一旦你確保了新版本沒有bug，你可以把流量切換到100%。

API 網(wǎng)關(guān)架構(gòu)

在我們的內(nèi)部規(guī)劃中(部分功能未實(shí)現(xiàn))，我們的 API 網(wǎng)關(guān)主要會(huì)分為三個(gè)部分，也就是上圖中綠色的幾部分：

1.多網(wǎng)關(guān)集群(Backends for frontends)

我們針對(duì)不同的客戶端，都有相應(yīng)的網(wǎng)關(guān)層來接入。現(xiàn)階段這一部分已經(jīng)實(shí)現(xiàn)的功能主要是：用戶登錄，鑒權(quán)，服務(wù)發(fā)現(xiàn)注冊(cè)，協(xié)議轉(zhuǎn)換，接口版本控制等。后續(xù)我們還規(guī)劃的功能有：監(jiān)控，APM調(diào)用鏈，日志，流控策略等。

2.聚合服務(wù)(Merge Service)

在某些客戶端的需求中，比如上面提到的商品詳情的頁面，我們需要從多個(gè)服務(wù)拉取數(shù)據(jù)，為了減少客戶端的復(fù)雜度，以及加快客戶端的訪問速度，我們會(huì)在前面加一個(gè)聚合層，用來做聚合查詢，在某些接口中可以把多個(gè)服務(wù)的數(shù)據(jù)一次性返回給客戶端。

3.儀表盤管理端(Dashboard)

Dashboard 提供可視化的分析平臺(tái)，包括服務(wù)的管理，監(jiān)控?cái)?shù)據(jù)報(bào)警配置，日志查詢，灰度發(fā)布操作，API文檔管理等，這些功能對(duì)于開發(fā)和日常運(yùn)維來說是非常重要的。