談談微服務中的 API 網關（API Gateway） - savorboard－IT工程師數位筆記本

文章出處

前言

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

那么，在本篇文章中，我們就一起來探討一下 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-umbrella: Ruby 實現的一個 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。

GitHub：https://github.com/dotnetcore/CAP

CAP 介紹：
http://www.cnblogs.com/savorboard/p/cap.html

有關分布式事務可以查看我的這篇文章。

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