前言

又是很久沒寫部落格了，最近一段時間換了新工作，比較忙，所以沒有抽出來太多的時間寫給關注我的粉絲寫一些乾貨了，就有人問我怎麼最近沒有更新部落格了，在這裡給大家抱歉。

那麼，在本篇文章中，我們就一起來探討一下 API 閘道器在整個微服務分散式架構中的一個作用。

背景

我們知道在微服務架構風格中，一個大應用被拆分成為了多個小的服務系統提供出來，這些小的系統他們可以自成體系，也就是說這些小系統可以擁有自己的資料庫，框架甚至語言等，這些小系統通常以提供 Rest Api 風格的介面來被 H5, Android, IOS 以及第三方應用程式呼叫。

但是在UI上進行展示的時候，我們通常需要在一個介面上展示很多資料，這些資料可能來自於不同的微服務中，舉個例子。

在一個電商系統中，檢視一個商品詳情頁，這個商品詳情頁包含商品的標題，價格，庫存，評論等，這些資料對於後端來說可能是位於不同的微服務系統之中，可能我後臺的系統是這樣來拆分我的服務的：

• 產品服務 - 負責提供商品的標題，描述，規格等。
• 價格服務 - 負責對產品進行定價，價格策略計算，促銷價等。
• 庫存服務 - 負責產品庫存。
• 評價服務 - 負責使用者對商品的評論，回覆等。

現在，商品詳情頁需要從這些微服務中拉取相應的資訊，問題來了？

問題

由於我們使用的服務系統架構，所以沒辦法像傳統單體應用一樣依靠資料庫的 join 查詢來得到最終結果，那麼如何才能訪問各個服務呢？

按照微服務設計的指導原則，我們的微服務可能存在下面的問題：

• 服務使用了多種協議，因為不同的協議有不同的應場景用，比如可能同時使用 HTTP, AMQP, gRPC 等。
• 服務的劃分可能隨著時間而變化。
• 服務的例項或者Host+埠可能會動態的變化。

那麼，對於前端的UI需求也可能會有以下幾種：

• 粗粒度的API，而微服務通常提供的細粒度的API，對於UI來說如果要呼叫細粒度的api可能需要呼叫很多次，這是個不小的問題。
• 不同的客戶端裝置可能需要不同的資料。Web,H5,APP
• 不同裝置的網路效能，對於多個api來說，這個訪問需要轉移的服務端會快得多

以上，就是我們構建微服務的過程中可能會遇到的問題。那麼如何解決呢？

這種情況下，我們就需要一個今天要講的這個東西， API 閘道器（API Gataway）。

API 閘道器

下面是百度上針對於 API 閘道器的介紹：

API閘道器是一個伺服器，是系統的唯一入口。從面向物件設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、快取、請求分片與管理、靜態響應處理。
API閘道器方式的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。通常，閘道器也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。

Chris Richardson 在他的部落格中把 API 閘道器劃分為以下兩種：

• 單節點 API 閘道器
• Backends for frontends 閘道器

單節點閘道器

單節點的 API閘道器為每個客戶端提供不同的API，而不是提供一種萬能風格的API。

這個閘道器和微軟在 eShop 專案中推薦的閘道器是一致的。

更多詳細資訊我會在下文進行說明。

Backends for frontends 閘道器

這種模式是針對不同的客戶端來實現一個不同的API閘道器。

落地方案

我一直在尋思一種最佳的 API 閘道器的落地方案，以上兩種 API 閘道器有什麼問題呢？

通常情況下， API 閘道器要做很多工作，它作為一個系統的後端總入口，承載著所有服務的組合路由轉換等工作，除此之外，我們一般也會把安全，限流，快取，日誌，監控，重試，熔斷等放到 API 閘道器來做，那麼可以試想在高併發的情況下，這裡可能會出現一個性能瓶頸。

另外，如果沒有開源專案的支撐前提下，自己來做這樣一套東西，是非常大的一個工作量，而且還要做 API 閘道器本身的高可用等，如果一旦做不好，有可能最先掛掉的不是你的其他服務，而就是這個API閘道器。

這個時候，通常我們會去找一些開源的 API 閘道器專案，博主已經給你找好了，目前社群的關於 API Gataway 的專案有以下這些：

Tyk：Tyk是一個開放原始碼的API閘道器，它是快速、可擴充套件和現代的。Tyk提供了一個API管理平臺，其中包括API閘道器、API分析、開發人員門戶和API管理面板。Try 是一個基於Go實現的閘道器服務。

Kong：Kong是一個可擴充套件的開放原始碼API Layer(也稱為API閘道器或API中介軟體)。Kong 在任何RESTful API的前面執行，通過外掛擴充套件，它提供了超越核心平臺的額外功能和服務。

Orange：和Kong類似也是基於OpenResty的一個API閘道器程式，是由國人開發的，學姐也是貢獻者之一。

Netflix zuul：Zuul是一種提供動態路由、監視、彈性、安全性等功能的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。

apiaxle: Nodejs 實現的一個 API 閘道器。

我們來說說上面的這些開源專案適不適合作為 API 閘道器來供我們使用。

拿單節點閘道器來說，這種閘道器相當於是處於 Web 層和 Service 之間，用來聚合服務的？注意，我們需要的是聚合服務，而以上這些開源專案都不具備這個功能，我說的聚合具體指的是開箱即用。我們要想使用這些服務需要來自己對API閘道器過一些擴充套件或者是開發一些外掛，這個時候問題就來了。擴充套件Tyk我需要會Go語言，擴充套件Kong我需要會寫lua指令碼，使用 zuul 還得會Java，這對於開發人員來說是不太現實的，那麼這個時候怎麼辦？

有些同學可能會說 ASP.NET Core 可以使用 Ocelot，說得沒錯，我們可以通過引入Ocelot來處理API聚合服務這一塊的業務，但是，這中間有一個問題，就像我在上面說的一樣，這很容易造成效能問題，另外一方面，Ocelot的功能相比上面的那些開源專案來說功能要弱很多，具體體現在哪些方面呢？

除了最重要的高效能的IO模型和叢集方案外， 比如會經常使用的 Dashboard 功能，這個對於運維來說是非常重要的，另外還有日誌，監控，安全，服務發現，版本控制等。

但是上面的這些 API 閘道器缺少什麼功能呢？ 比如超時，熔斷，重試，聚合查詢等。

注意：以下內容的這些想法全是我個人對於 API 閘道器的理解而誕生的，如有錯誤還請指正。

聰明的同學可能想出來了，怎麼辦呢？ 我們可以充分來結合兩者的優勢來在我們的 ASP.NET Core 應用程式中實現一個“雙重閘道器”。

下面是我畫的一個 API 閘道器在微服務架構中的一個作用圖：

應該大部分同學都可以看懂，我就簡單解釋一下。

• OpenResty Api Gateway

從左至右 HTTP 請求先由DNS在拿到第一手流量後負載均衡到基於 OpenResty 的 API Gataway 閘道器叢集，在這個流程我們可以使用像 Kong,Orage,Tyk 這些開源的支援高併發高訪問量 API 閘道器程式在做第一層流量的防護，在這一級我們可以做一些像身份認證，安全，監控，日誌，流控等策略。除了這些我們還可以做一些服務的發現和註冊（這個要看不同閘道器的支援程度），介面的版本控制，路由重寫等。

• Aggr Api Gateway

然後再由這些 API 閘道器把請求再負載到不同的 Aggr Api Gateway，在這裡我們做聚合服務這個操作，具體體現也就是圖中的黃色區域是需要由各個語言的開發人員來需要寫程式碼實現的。具體流程也就是我們可以引入像 Ocelot 這種和語言相關的 API 閘道器開源專案，然後通過 NuGet 包引入之後通過 Json配置+聚合程式碼的方式來整合後端的各個微服務提供聚合查詢等操作。這期間對於有需求的介面，我們可以應用超時，快取，熔斷，重試等策略。

從 Aggr Api Gateway 到後端微服務叢集這中間就屬於內部的通訊了，我們可以使用對內部友好的通訊協議比如 gRPC 或者 AMQP 等，然後進行 RPC呼叫提高通訊效能。

注意：Aggr Api Gateway 這個閘道器對於一些介面來說的話並不是必須的，也可以由後端微服務直接提供REST API給第一層閘道器使用。

以上，就是我理解的 API 閘道器在整個微服務架構中的一個地位，承上啟下，還是非常的重要。

廣告

我們知道，在 API 閘道器的後端是微服務的叢集，那麼除了聚合查詢之外有時候我們有時候需要做一些跨不同服務的操作，比如一次電商系統的下單操作，可以會設計到產品、價格、庫存等一系列跨微服務操作，在中間我們一般會採用整合事件(EventBus)來進行通訊這種解決方案，在這個過程中我們不僅僅的是需要通訊，那麼這些操作還需要保證事務一致性，而一般分散式系統中的事務我們追求的是最終一致性。

如果是在 .NET Core 中，我們可以使用博主開源的 EventBus + 分散式事務 解決方案 CAP。

有關分散式事務可以檢視我的這篇文章。

感興趣的同學可以給CAP一個 Star 以表支援，偷偷告訴你 Ocelot的作者也Star了哦。 :)

總結

通過本文我們瞭解到了什麼是 API 閘道器以及API閘道器的作用和其在微服務架構中所處的地位。然後我們瞭解到了 API 閘道器的一些開源專案以及博主介紹的落地方案，在實際的實踐中還是多希望大家能夠多多思考總結，這樣我們才能夠變得更加強大。

如果你覺得本篇文章對您有幫助的話，感謝您的【推薦】。

如果你對 .NET Core 有興趣的話可以關注我，我會定期的在部落格分享我的學習心得。