您好,登錄后才能下訂單哦!
課程下載鏈接:https://pan.baidu.com/s/1ql1J4IvGJ1wTBOa2EKtFgg 提取碼: b65w
老顧這系列課程就給大家介紹一下nignx + lua方式的網關框架,也是很多公司常用的網關框架
最近 微服務架構在項目中的應用越來越多,我們知道在微服務架構風格中,一個大應用被拆分成為了多個小的服務系統提供出來,這些小的系統他們可以自成體系,也就是說這些小系統可以擁有自己的數據庫,框架甚至語言等,這些小系統通常以提供 Rest Api 風格的接口來被 H5, Android, IOS 以及第三方應用程序調用。
但是在UI上進行展示的時候,我們通常需要在一個界面上展示很多數據,這些數據可能來自于不同的微服務中,舉個例子。
在一個電商系統中,查看一個商品詳情頁,這個商品詳情頁包含商品的標題,價格,庫存,評論等,這些數據對于后端來說可能是位于不同的微服務系統之中,可能我后臺的系統是這樣來拆分我的服務的:
1、產品服務 - 負責提供商品的標題,描述,規格等。
2、價格服務 - 負責對產品進行定價,價格策略計算,促銷價等。
3、庫存服務 - 負責產品庫存。
4、評價服務 - 負責用戶對商品的評論,回復等。
現在,商品詳情頁需要從這些微服務中拉取相應的信息,問題來了?
問題
由于我們使用的服務系統架構,所以沒辦法像傳統單體應用一樣依靠數據庫的 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注冊和管理服務。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。