api商品分享源码_谈谈微服务中的 API 网关(API Gateway)
在本篇文章中,我們就一起來探討一下 API 網關在整個微服務分布式架構中的一個作用。
# 背景我們知道在微服務架構風格中,一個大應用被拆分成為了多個小的服務系統提供出來,這些小的系統他們可以自成體系,也就是說這些小系統可以擁有自己的數據庫,框架甚至語言等,這些小系統通常以提供 Rest Api 風格的接口來被 H5, Android, IOS 以及第三方應用程序調用。但是在UI上進行展示的時候,我們通常需要在一個界面上展示很多數據,這些數據可能來自于不同的微服務中,舉個例子。在一個電商系統中,查看一個商品詳情頁,這個商品詳情頁包含商品的標題,價格,庫存,評論等,這些數據對于后端來說可能是位于不同的微服務系統之中,可能我后臺的系統是這樣來拆分我的服務的:- 產品服務 - 負責提供商品的標題,描述,規格等。
- 價格服務 - 負責對產品進行定價,價格策略計算,促銷價等。
- 庫存服務 - 負責產品庫存。
- 評價服務 - 負責用戶對商品的評論,回復等。
# 問題
由于我們使用的服務系統架構,所以沒辦法像傳統單體應用一樣依靠數據庫的 join 查詢來得到最終結果,那么如何才能訪問各個服務呢?按照微服務設計的指導原則,我們的微服務可能存在下面的問題:- 服務使用了多種協議,因為不同的協議有不同的應場景用,比如可能同時使用 HTTP, AMQP, gRPC 等。
- 服務的劃分可能隨著時間而變化。
- 服務的實例或者Host+端口可能會動態的變化。
- 粗粒度的API,而微服務通常提供的細粒度的API,對于UI來說如果要調用細粒度的api可能需要調用很多次,這是個不小的問題。
- 不同的客戶端設備可能需要不同的數據。Web,H5,APP
- 不同設備的網絡性能,對于多個api來說,這個訪問需要轉移的服務端會快得多
下面是百度上針對于 API 網關的介紹:
API網關是一個服務器,是系統的唯一入口。從面向對象設計的角度看,它與外觀模式類似。API網關封裝了系統內部架構,為每個客戶端提供一個定制的API。它可能還具有其它職責,如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。
API網關方式的核心要點是,所有的客戶端和消費端都通過統一的網關接入微服務,在網關層處理所有的非業務功能。通常,網關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。
Chris Richardson 在他的博客中把 API 網關劃分為以下兩種:
單節點 API 網關
Backends for frontends 網關
單節點網關
單節點的 API網關為每個客戶端提供不同的API,而不是提供一種萬能風格的API。
這個網關和微軟在 eShop 項目中推薦的網關是一致的。
更多詳細信息我會在下文進行說明。
Backends for frontends 網關
這種模式是針對不同的客戶端來實現一個不同的API網關。
# 落地方案我一直在尋思一種最佳的 API 網關的落地方案,以上兩種 API 網關有什么問題呢?通常情況下, API 網關要做很多工作,它作為一個系統的后端總入口,承載著所有服務的組合路由轉換等工作,除此之外,我們一般也會把安全,限流,緩存,日志,監控,重試,熔斷等放到 API 網關來做,那么可以試想在高并發的情況下,這里可能會出現一個性能瓶頸。關注公眾號小黃鴨編程社區,回復關鍵字資料,領取最新的編程視頻資料。另外,如果沒有開源項目的支撐前提下,自己來做這樣一套東西,是非常大的一個工作量,而且還要做 API 網關本身的高可用等,如果一旦做不好,有可能最先掛掉的不是你的其他服務,而就是這個API網關。這個時候,通常我們會去找一些開源的 API 網關項目,博主已經給你找好了,目前社區的關于 API Gataway 的項目有以下這些:Tyk:Tyk是一個開放源碼的API網關,它是快速、可擴展和現代的。Tyk提供了一個API管理平臺,其中包括API網關、API分析、開發人員門戶和API管理面板。Try 是一個基于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 網關。我們來說說上面的這些開源項目適不適合作為 API 網關來供我們使用。拿單節點網關來說,這種網關相當于是處于 Web 層和 Service 之間,用來聚合服務的?注意,我們需要的是聚合服務,而以上這些開源項目都不具備這個功能,我說的聚合具體指的是開箱即用。我們要想使用這些服務需要來自己對API網關過一些擴展或者是開發一些插件,這個時候問題就來了。擴展Tyk我需要會Go語言,擴展Kong我需要會寫lua腳本,使用 zuul 還得會Java,這對于開發人員來說是不太現實的,那么這個時候怎么辦?有些同學可能會說 ASP.NET Core 可以使用 Ocelot,說得沒錯,我們可以通過引入Ocelot來處理API聚合服務這一塊的業務,但是,這中間有一個問題,就像我在上面說的一樣,這很容易造成性能問題,另外一方面,Ocelot的功能相比上面的那些開源項目來說功能要弱很多,具體體現在哪些方面呢?除了最重要的高性能的IO模型和集群方案外, 比如會經常使用的 Dashboard 功能,這個對于運維來說是非常重要的,另外還有日志,監控,安全,服務發現,版本控制等。但是上面的這些 API 網關缺少什么功能呢?比如超時,熔斷,重試,聚合查詢等。注意:以下內容的這些想法全是我個人對于 API 網關的理解而誕生的,如有錯誤還請指正。
聰明的同學可能想出來了,怎么辦呢?我們可以充分來結合兩者的優勢來在我們的 ASP.NET Core 應用程序中實現一個“雙重網關”。
下面是我畫的一個 API 網關在微服務架構中的一個作用圖:
應該大部分同學都可以看懂,我就簡單解釋一下。- OpenResty Api Gateway
- Aggr Api Gateway
作者:Savorboard
來源:https://www.cnblogs.com/savorboard/p/api-gateway.html
往期推薦?
- 快訊:Eclipse 4.16 穩定版發布了!
- Logback 配置文件這么寫,TPS 提高 10 倍!
- Spring Boot 2.3.1 發布了!與鴨哥一起解讀新特性:-)
總結
以上是生活随笔為你收集整理的api商品分享源码_谈谈微服务中的 API 网关(API Gateway)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: h标签对html网页的作用,网页H标签S
- 下一篇: 太原计算机专业专科大学排名,太原【计算机