??? 微服務架構在項目中的應用越來越多，我們知道在微服務架構風格中，一個大應用被拆分成為了多個小的服務系統提供出來，這些小的系統他們可以自成體系，也就是說這些小系統可以擁有自己的數據庫，框架甚至語言等，這些小系統通常以提供 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 網關。

?

網關技術選項

轉載于:https://www.cnblogs.com/reblue520/p/11428888.html

總結

以上是生活随笔為你收集整理的openresty开发系列1--网关API架构及选型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。