終身高級VIP會員
  
- 資源幣
- 11472
- 積分
- 4971
- 貢獻
- 0
- 在線時間
- 2065 小時
- 注冊時間
- 2015-4-20
- 最后登錄
- 2024-7-9
|
微服務Api網(wǎng)關框架-龍果學院 價值399
最近 微服務架構在項目中的應用越來越多，我們知道在微服務架構風格中，一個大應用被拆分成為了多個小的服務系統(tǒng)提供出來，這些小的系統(tǒng)他們可以自成體系，也就是說這些小系統(tǒng)可以擁有自己的數(shù)據(jù)庫，框架甚至語言等，這些小系統(tǒng)通常以提供 Rest Api 風格的接口來被 H5, Android, IOS 以及第三方應用程序調用。
但是在UI上進行展示的時候，我們通常需要在一個界面上展示很多數(shù)據(jù)，這些數(shù)據(jù)可能來自于不同的微服務中，舉個例子。
在一個電商系統(tǒng)中，查看一個商品詳情頁，這個商品詳情頁包含商品的標題，價格，庫存，評論等，這些數(shù)據(jù)對于后端來說可能是位于不同的微服務系統(tǒng)之中，可能我后臺的系統(tǒng)是這樣來拆分我的服務的：
產品服務 - 負責提供商品的標題，描述，規(guī)格等。
價格服務 - 負責對產品進行定價，價格策略計算，促銷價等。
庫存服務 - 負責產品庫存。
評價服務 - 負責用戶對商品的評論，回復等。
現(xiàn)在，商品詳情頁需要從這些微服務中拉取相應的信息，問題來了？
問題
由于我們使用的服務系統(tǒng)架構，所以沒辦法像傳統(tǒng)單體應用一樣依靠數(shù)據(jù)庫的 join 查詢來得到最終結果，那么如何才能訪問各個服務呢？
按照微服務設計的指導原則，我們的微服務可能存在下面的問題：
服務使用了多種協(xié)議，因為不同的協(xié)議有不同的應場景用，比如可能同時使用 HTTP, AMQP, gRPC 等。
服務的劃分可能隨著時間而變化。
服務的實例或者Host+端口可能會動態(tài)的變化。
那么，對于前端的UI需求也可能會有以下幾種：
粗粒度的API，而微服務通常提供的細粒度的API，對于UI來說如果要調用細粒度的api可能需要調用很多次，這是個不小的問題。
不同的客戶端設備可能需要不同的數(shù)據(jù)。Web,H5,APP
不同設備的網(wǎng)絡性能，對于多個api來說，這個訪問需要轉移的服務端會快得多
以上，就是我們構建微服務的過程中可能會遇到的問題。那么如何解決呢？
這種情況下， API 網(wǎng)關（API Gataway）誕生了。
API 網(wǎng)關
API網(wǎng)關是一個服務器，是系統(tǒng)的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網(wǎng)關封裝了系統(tǒng)內部架構，為每個客戶端提供一個定制的API。它可能還具有其它職責，如身份驗證、監(jiān)控、負載均衡、緩存、請求分片與管理、靜態(tài)響應處理。
API網(wǎng)關方式的核心要點是，所有的客戶端和消費端都通過統(tǒng)一的網(wǎng)關接入微服務，在網(wǎng)關層處理所有的非業(yè)務功能。通常，網(wǎng)關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。
API網(wǎng)關網(wǎng)關的價值：
網(wǎng)關層對外部和內部進行了隔離，保障了后臺服務的安全性。
對外訪問控制由網(wǎng)絡層面轉換成了運維層面，減少變更的流程和錯誤成本
減少客戶端與服務的耦合，服務可以獨立發(fā)展。通過網(wǎng)關層來做映射。
通過網(wǎng)關層聚合，減少外部訪問的頻次，提升訪問效率。
節(jié)約后端服務開發(fā)成本，減少上線風險。
為服務熔斷，灰度發(fā)布，線上測試提供簡單方案。
當然現(xiàn)在市面上的Api網(wǎng)關開源項目，有以下項目
Tyk：Tyk是一個開放源碼的API網(wǎng)關，它是快速、可擴展和現(xiàn)代的。Tyk提供了一個API管理平臺，其中包括API網(wǎng)關、API分析、開發(fā)人員門戶和API管理面板。Try 是一個基于Go實現(xiàn)的網(wǎng)關服務。
Kong：Kong是一個可擴展的開放源碼API Layer(也稱為API網(wǎng)關或API中間件)。Kong 在任何RESTful API的前面運行，通過插件擴展，它提供了超越核心平臺的額外功能和服務。
Orange：和Kong類似也是基于OpenResty的一個API網(wǎng)關程序，是由國人開發(fā)的。
Netflix zuul：Zuul是一種提供動態(tài)路由、監(jiān)視、彈性、安全性等功能的邊緣服務。Zuul是Netflix出品的一個基于JVM路由和服務端的負載均衡器。
apiaxle: Nodejs 實現(xiàn)的一個 API 網(wǎng)關。
api-umbrella: Ruby 實現(xiàn)的一個 API 網(wǎng)關。
老顧這系列課程就給大家介紹一下nignx + lua方式的網(wǎng)關框架，也是很多公司常用的網(wǎng)關框架
課程大綱
第1章 第一章
第1講 漫談網(wǎng)關架構
第2講 網(wǎng)關技術選型
第3講 nginx下載安裝
第4講 正向代理、反向代理
第5講 nginx命令、信號控制
第6講 nginx平滑升級
第7講 nginx配置文件說明
第8講 nginx配置連接數(shù)
第9講 nginx虛擬主機
第10講 nginx日志以及切割
第11講 nginx的location詳解
第12講 nginx的負載均衡
第13講 nginx的echo模塊安裝
第14講 openresty背景介紹
第15講 openresty安裝
第16講 openresty的helloworld
第17講 lua介紹以及helloworld
第18講 lua基本語法一
第19講 lua基本語法二
第20講 lua基本語法三
第21講 lua基本語法四
第22講 lua運算符
第23講 lua控制結構一
第24講 lua控制結構二
第25講 lua的正則表達式
第26講 lua的string操作
第27講 lua的table操作
第28講 lua變量
第29講 lua時間操作
第30講 lua模塊
第31講 lua元表
第32講 lua面向對象
第33講 openresty中使用lua
第34講 openresty中使用json模塊
第35講 openresty中使用redis模塊
第36講 openresty中封裝redis操作
第37講 openresty中使用mysql
第38講 lua發(fā)起http請求
第39講 openresty中使用http模塊
第40講 openresty中使用全局緩存
第41講 openresty執(zhí)行流程
第42講 openresty執(zhí)行詳解之初始化階段
第43講 openresty執(zhí)行詳解之重寫賦值階段
第44講 openresty執(zhí)行詳解之重寫url階段
第45講 openresty執(zhí)行詳解之訪問階段
第46講 openresty執(zhí)行詳解之內容階段
第47講 openresty執(zhí)行詳解之響應階段
第48講 openresty實現(xiàn)訪問頻率控制
第49講 openresty實現(xiàn)黑名單控制
第50講 openresty實現(xiàn)接口簽名驗證
第51講 openresty實現(xiàn)網(wǎng)關框架
第52講 openresty實現(xiàn)網(wǎng)關主入口
第53講 openresty實現(xiàn)網(wǎng)關插件可配置
第54講 openresty實現(xiàn)網(wǎng)關插件加載
第55講 openresy實現(xiàn)網(wǎng)關之簽名驗證插件
第56講 openresy實現(xiàn)網(wǎng)關之黑名單插件
第57講 openresty實現(xiàn)網(wǎng)關之頻率插件
第58講 網(wǎng)關框架總結
|
|
發(fā)表于 2019-8-4 18:55:27
收藏