openresty開發系列1--網關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網關方式的核心要點是，全部的客戶端和消費端都經過統一的網關接入微服務，在網關層處理全部的非業務功能。一般，網關也是提供REST/HTTP的訪問API。服務端經過API-GW註冊和管理服務。
API網關網關的價值：

    網關層對外部和內部進行了隔離，保障了後臺服務的安全性。
    對外訪問控制由網絡層面轉換成了運維層面，減小變動的流程和錯誤成本
    減小客戶端與服務的耦合，服務能夠獨立發展。經過網關層來作映射。
    經過網關層聚合，減小外部訪問的頻次，提高訪問效率。
    節約後端服務開發成本，減小上線風險。
    爲服務熔斷，灰度發佈，線上測試提供簡單方案。

微服務API網關框架

單節點場景

 

多節點場景

 

網關做用

統一入口

安全：黑名單、權限身份認證

限流：實現微服務訪問流量計算，基於流量計算分析進行限流，能夠定義多種限流規則。

緩存：數據緩存

日誌：日誌記錄

監控：記錄請求響應數據，api耗時分析，性能監控

重試：異常重試

熔斷： 降級

 

現有框架

Tyk：Tyk是一個開放源碼的API網關，它是快速、可擴展和現代的。Tyk提供了一個API管理平臺，其中包括API網關、API分析、開發人員門戶和API管理面板。Trk 是一個基於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 網關。

 

網關技術選項