ASP.NET Core微服務框架Ocelot+Consul+IdentityServer4的操作方法

今天就跟大家聊聊有關ASP.NET Core微服務框架Ocelot+Consul+IdentityServer4的操作方法，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

一、背景介紹

API網關的流行源于最近幾年移動應用與企業間接口對接的興起，使得原來單一的PC客戶端，變化到PC客戶端、各種瀏覽器、手機移動端及智能終端等。同時系統之間大部分都不是單獨運行，經常會涉及與其他系統對接、共享數據的需求。隨著微服務架構概念的提出，API網關成為了微服務架構的一個標配組件。隨著業務快速發展，面向手機移動應用業務越來越多，為了減少客戶端與服務的耦合，節約后端微服務的開發成本，建立一個高性能、高可用、減少上線風險的API網關成為一個迫切的需求。

1）、目前面臨現狀：假設你正好是一個后端開發，而老板又剛好讓你開發網站，其中需要涉及到很多后端的微服務，比如會員、商品、推薦服務等等。那么這里就會遇到一個問題，APP/Browser怎么去訪問這些后端的服務?如果業務比較簡單的話，可以給每個業務都分配一個獨立的域名(https://service.api.company.com)，但這種方式會有幾個問題:每個業務都會需要鑒權、限流、權限校驗等邏輯，如果每個業務都各自為戰，自己造輪子實現一遍，會很蛋疼，完全可以抽出來，放到一個統一的地方去做。

2）、有效的解決辦法：更好的方式是采用API網關，實現一個API網關接管所有的入口流量，類似Nginx的作用，將所有用戶的請求轉發給后端的服務器，但網關做的不僅僅只是簡單的轉發，也會針對流量做一些擴展。比如鑒權、限流、權限、熔斷、協議轉換、錯誤碼統一、緩存、日志、監控、告警等，這樣將通用的邏輯抽出來，由網關統一去做，業務方也能夠更專注于業務邏輯，提升迭代的效率。通過引入API網關，客戶端只需要與API網關交互，而不用與各個業務方的接口分別通訊，

本次分享課程阿笨將在基于上兩堂課程的基礎上以ASP .NET Core 為例子，目前比較火熱的就是 ocelot+consul 的搭配，通過在服務中嵌入 ocelot 和 consul 的客戶端，自動的完成服務注冊到（Consul）和服務發現（ocelot讀取Consul中的服務）；當用戶訪問某個 url 的時候，ocelot 將會根據路由將用戶請求轉發到從 Consul 拉取到的真正的服務中同時通過統一身份認證授權中心IdentityServer4進行鑒權。

二、ASP.NET Core微服務框架Ocelot+Consul+IdentityServer4項目結構介紹

ASP.NET Core微服務框架Ocelot+Consul+IdentityServer4實戰演練

三、 Consul服務注冊與發現介紹

四、下游微服務通過API接入Consul

五、Ocelot網關介紹

六、Ocelot網關認證授權流程圖

七、認證授權IdentityServer4介紹以及搭建

八、Ocelot網關接入認證授權中心

九、Ocelot網關接入Conusl服務注冊與發現

十、Ocelot網關統一查看多個API微服務Swagger接口文檔

網關在硬件里有自己的定義,而在軟件架構里也有自己的解釋,它就是所有請求的入口,請求打到網關上,經過處理和加工,再返回給客戶端,這個處理過程中當然就是網關的核心,也是Ocelot的核心,我們可以把用戶授權,校驗,緩存,認證等很多關注點在網關中實現!

看完上述內容，你們對ASP.NET Core微服務框架Ocelot+Consul+IdentityServer4的操作方法有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。