一、部署gitlab 這裡使用的是Centos8,安裝Docker環境 ,這裡不說了,參考:https://www.cnblogs.com/wei325/p/15139701.html gitlab有ce版和ee版,ce版為免費版本;ee版為企業版本,需要收費;企業使用ce版足夠了,這裡用ce版。 ...
1. 請求管道
請求管道是什麼?請求管道描述的是一個請求進到我們的後端應用,後端應用如何處理的過程,從接收到請求,之後請求怎麼流轉,經過哪些處理,最後怎麼返迴響應。請求管道就是一次請求在後端應用的生命周期。瞭解請求管道,有助於我們明白後端應用是怎麼工作的,我們的代碼是怎麼工作的,在我們的業務代碼執行前後經過哪些步驟,有助於我們之後更好的實現一些AOP操作。
請求管道是 .net 應用的一個最基本的概念。在 .net core 中,微軟對框架底層進行了全新的設計,相對於原本的ASP.NET中的全家桶模式的管道模型,.net core的管道模型更加靈活便捷,可做到熱插拔,通過管道可以隨意註冊自己想要的服務或者第三方服務插件,這也是.net core性能更好的原因。
以上是微軟官方文檔中的管道模型圖。從圖中可以看到 伺服器接收到請求之後,將接收到的請求向後傳遞,依次經過一個個 Middleware 進行處理,然後由最後一個 MiddleWare 生成響應內容並回傳,再反向依次經過每一個 Middleware,直到由伺服器發送出去。整個過程就像一條流水線一樣,管道這個詞是很形象的,而 Middleware 就像一層一層的“濾網”,過濾所有的請求和響應。
2. 中間件
管道之中,對請求、響應進行加工處理的模塊是 Middleware
,也就是中間件。中間件本質上是一個委托。
2.1 工作模式
從上面的圖可以看出,每一個中間件都會被執行兩次,在下一個中間件執行之前和之後各執行一次,分別是在處理請求和處理響應,只有一個中間件是例外的,那就是最後一個中間件,它後面沒有下一個中間件,所以執行到它管道就會迴轉。
這代表了中間件的兩種工作模式,也是中間件的兩種基本註冊方式。中間件本質上是一個委托,在代碼實現上就體現在委托的入參有所不同以及註冊調用的方法不同。
中間件兩種最基本的註冊方式:
- Use 方法註冊
- use 註冊的中間件會傳入next參數,在處理完本身的邏輯之後可以調用 next() 去執行下一個中間件
- 如果不執行,就等於Run
- Run 方法註冊
- Run 只是執行,沒有去調用Next ,一般作為終結點。
- Run 方法註冊,只是一個擴展方法,最終還是調用Use方法
在代碼中分別是以下方式:
app.Use(async (context, next) =>
{
await context.Response.WriteAsync("Hello Middlerware !");
if(context.Request.Query.TryGetValue("query", out var query))
{
await context.Response.WriteAsync(query);
}
await next();
await context.Response.WriteAsync("End Middleware !");
});
app.Run(async context =>
{
await context.Response.WriteAsync("Hello last Middleware");
});
最後的執行結果如下,也可以從代碼執行的先後順序看出管道流動的順序。當前中間件手動調用 next() 之後,就進入下一個中間件,下一個中間件處理完成之後,按照管道的順序再一個一個回傳。在這個過程中一直不變,被管道傳遞的就是HttpContext,而我們拿到 HttpContext,即可以通過 Request 和 Response 對當前這一次的請求做任何處理了。
通過分析asp.net core的源碼,可以看到在我們調用 Run() 的時候,實際上還是調用了 Use() 方法。
而 Use() 方法中,主要的邏輯僅僅只是將相應的委托存放到集合中
之後在 build 方法調用的時候才一個一個地調用中間件委托。
除了上面的 Use() 、Run() 兩個最基本的方法註冊中間件之外,還有另外一些方法,如通過 Map() 方法註冊中間件,這種方式會創建一個新的管道分支,在路由滿足Map的規則時,請求則轉型新的管道分支,最後沿著管道分支返迴響應,而不走原有的管道。
app.Use(async (context, next) =>
{
await context.Response.WriteAsync("Hello Middlerware1 ! ");
if(context.Request.Query.TryGetValue("query", out var query))
{
await context.Response.WriteAsync(query);
}
await next();
await context.Response.WriteAsync("End Middleware1 ! ");
});
app.Map("/map", app =>
{
// map方法中的委托,傳入的時IApplicationBuilder, 在這裡相當於一個新的管道,也可以和主管道一樣進行任意操作
app.Run(async context =>
{
await context.Response.WriteAsync("Hello map Middleware pipeline ! ");
});
});
app.Run(async context =>
{
await context.Response.WriteAsync("Hello last Middleware ! ");
});
執行結果如下:
其他的分支管道創建方式,如 MapWhen,和 Map 大同小異,只是對於匹配判斷的方式有所不同。像微軟內置中間件中的靜態文件中間件,MVC 中間件,其實都是以分支管道的方式實現的,一旦匹配到請求就會走管道分支。
2.2 中間件的使用配置
使用一個中間件需要在 .net core 的入口文件中進行配置,如果是 .net 6版本,那隻要在 program.cs 文件中進行配置即可,通過 WebApplication 對象,也就是 app 調用相關的方法。
如果是 .net 6 以下版本,可以在 startup.cs 文件中的 Configure 方法中配置。.net 6 與之前版本入口文件的不同上一篇文章也講過,這裡就不贅述了。
這裡可以看得到,一些中間件的調用並沒有直接使用 Use() 和 Run(),畢竟將各個中間件的處理邏輯全部放在入口文件很不好管理,而且也很不優雅。這裡涉及到了中間件封裝的約定規則,一般情況下封裝一個中間件都會提供一個 Use[Middleware] 方法以供使用者進行中間件的調用,WebApplication 對象的 UseXXX 方法都是中間件調用的方法。
2.3 ASP.NET Core 框架內置中間件
ASP.NET Core 框架之中內置有很多中間件,並且我們通過 VS 創建某一個類型的項目時,如MVC、Razor Page,初始化的項目代碼中會幫我們配置好一些中間件。
以上為官方文檔中列出的內置中間件,可以看到在列表中對每個中間件的順序進行了說明。
管道中的中間件排列是有先後之分的,請求和響應按照中間件的排列順序進行傳遞,這也是我們代碼邏輯執行的順序,而且一些中間件需要依賴於其他中間件的處理結果,或者必須在某些中間件前先執行,否則就會出問題了。
而中間件插入到管道中的順序,就是依據我們在入口文件中調用相應中間註冊方法的順序,所以代碼的前後順序非常重要,一旦寫錯了就會出現很多意想不到的的Bug。
向 Program.cs 文件中添加中間件組件的順序定義了針對請求調用這些組件的順序,以及響應的相反順序。 此順序對於安全性、性能和功能至關重要。這是官方文檔中的原話。
官方文檔給出了典型MVC應用的管道中間件順序,這裡其實不止MVC,Razor Page、Web Api 也是這樣的管道模型,如下圖。這裡也明確了我們自定義的中間件應該插入到哪個位置。
更多的內置中間件的作用,以及相應的管道順序要求,請詳細閱讀一下官方文檔,這裡就不細說了。
參考文章:
ASP.NET Core 系列:
目錄:ASP.NET Core 系列總結
上一篇: ASP.NET Core - .NET 6 的入口文件