微服務API網關框架課程

課程下載連接：https://pan.baidu.com/s/1ql1J4IvGJ1wTBOa2EKtFgg 提取碼: b65w

老顧這系列課程就給你們介紹一下nignx + lua方式的網關框架，也是不少公司經常使用的網關框架

最近 微服務架構在項目中的應用愈來愈多，咱們知道在微服務架構風格中，一個大應用被拆分紅爲了多個小的服務系統提供出來，這些小的系統他們能夠自成體系，也就是說這些小系統能夠擁有本身的數據庫，框架甚至語言等，這些小系統一般以提供 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註冊和管理服務。