ASP.NET Core 3.x 中介軟體流程與路由體系
中介軟體分類
ASP.NET Core 中介軟體的配置方法可以分為以上三種，對應的Helper方法分別是：Run(), Use(), Map()。
- Run()，使用Run呼叫中介軟體的時候，會直接返回一個響應，所以後續的中介軟體將不會被執行了。
- Use()，它會對請求做一些工作或處理，例如新增一些請求的上下文資料，有時候甚至什麼也不做，直接把請求交給下一個中介軟體。
- Map()，它會把請求重新路由到其它的中介軟體路徑上去。
實際中呢，Use()這個helper方法用的最多。
Run()：
這是一個使用Run方法呼叫的中介軟體，Run方法會終止整個中介軟體管道，它應該返回某種型別的響應。
Use():
Use看起來和Run差不多，但是多了一個next引數。next可以用來呼叫請求管道中的下一個中介軟體。而當前的中介軟體也可以自己返回響應，這就忽略掉了next呼叫。
在next呼叫之前，我們可以寫一些請求進來的邏輯，而在next呼叫之後，就相當於返回響應了，這時候也可以寫一些邏輯。
在本例中，我們下面還使用了Run方法註冊了另一箇中間件。因為中介軟體會按照它們註冊的順序進行呼叫，所以在第一個Use方法裡執行next.Invoke()的時候，就會執行下面Run所呼叫的中介軟體。
Map()：
Map方法可以把請求路由到其它的中介軟體上面。
在這裡，如果請求的路徑以/jump結尾，那麼它所對應的handler方法，也就是HereIAm方法就會被呼叫，並返回一個響應。
而如果請求的路徑不是以/jump結尾，那麼HereIAm方法和裡面的中介軟體就不會被呼叫。
中介軟體Class
上面的例子，我都是使用的inline寫法的中介軟體。
而實際上，中介軟體通常是自成一個類。中介軟體的類需要類似這樣：
自定義的中介軟體類需要由這幾部分組成：
- 接受一個RequestDelegate型別的引數next的建構函式。
- 按約定，還需要定義一個叫做Invoke的方法。該方法裡會包含主要的業務邏輯，並且它會被請求管道所執行。Invoke方法可以忽略裡面的_next呼叫，並返回一個響應；也可以呼叫_next.Invoke()把請求傳送到管道的下一站。
中介軟體流程圖
Endpoint Routing 路由系統
ASP.NET Core 3.x 使用了一套叫做 Endpoint Routing 的路由系統。這套路由系統在ASP.NET Core 2.2的時候就已經露面了。
這套Endpoint Routing路由系統提供了更強大的功能和靈活性，以便能更好的處理請求。
早期ASP.NET Core的路由系統
我們先回顧一下早期版本的ASP.NET Core的路由系統：
在早期的ASP.NET Core框架裡，HTTP請求進入中介軟體管道，在管道的結尾處，有一個Router中介軟體，也就是路由中介軟體。這個路由中介軟體會把HTTP請求和路由資料傳送給MVC的一個元件，它叫做MVC Router Handler。
這個MVC 路由 Handler就會使用這些路由資料來決定哪個Controller的Action方法應該來負責處理這個請求。
然後 Router中介軟體就會執行被選中的Action方法，並生成響應，而這個響應就會順著中介軟體的管道原路返回。
問題出在哪？
為什麼早期的這套路由系統被拋棄了？它有什麼問題？
第一個問題就是，在被MVC處理之前，其它的中介軟體不知道最後哪個Action方法會被選中來處理這個請求。這對像Authorization（授權），Cors這樣的中介軟體會造成很大的困擾，因為他們不能提前知道該請求會被送往哪裡。
第二個問題就是，這套流程會把MVC和路由的職責緊密的耦合在一起，而實際MVC的本職工作應該僅僅就是生成響應。
Endpoint Routing 路由系統前來營救
Endpoint routing 路由系統，它把MVC的路由功能抽象剝離出來，並放置到中介軟體管道里，從而解決了早期ASP.NET Core路由系統的那兩個問題。
而在Endpoint Routing 路由系統裡，其實一共有兩個中介軟體，它們的名稱有點容易混淆，但是你只要記住他們的職責即可：
- Endpoint Routing 中介軟體。它決定了在程式中註冊的哪個Endpoint應該用來處理請求。
- Endpoint 中介軟體。它是用來執行選中的Endpoint，從而讓其生成響應的。
所以，Endpoint Routing的流程圖大致如下：
在這裡，Endpoint Routing 中介軟體會分析進來的請求，並把它和在程式中註冊的Endpoints進行比較。它會使用這些 Endpoints 上面的元資料來決定哪個是處理該請求的最佳人選。然後，這個選中的Endpoint 就會被賦給請求的物件，而其它後續的中介軟體就可以根據這個選中的Endpoint，來做一些自己的決策。在所有的中介軟體都執行完之後，這個被選中的Endpoint最終將被 Endpoint中介軟體所執行，而與之關聯的Action方法就會被執行。
Endpoint是什麼？
Endpoint是這樣的一些類，這些類包含一個請求的委託（Request Delegate）和其它的一些元資料，使用這些東西，Endpoint類可以生成一個響應。
而在MVC的上下文中，這個請求委託就是一個包裝類，它包裝了一個方法，這個方法可以例項化一個Controller並執行選中的Action方法。
Endpoint還包含元資料，這些元資料用來決定他們的請求委託是否應該用於當前的請求，還是另有其它用途。
說起來可能有點迷糊，一會我們看看原始碼。
Startup.cs
之前我們見過，ASP.NET Core裡面的Startup.cs裡面有兩個方法，分別是ConfigureServices()和Configure()，它們的職責就是註冊應用的一些服務和構建中介軟體請求管道。
而Startup.cs同時也是應用的路由以及Endpoint作為其它步驟的一分部進行註冊的地方。
看圖：
在ASP.NET Core應用程式啟動的時候，一個叫做ControllerActionEndpointDataSource的類作為應用程式級別的服務被建立了。
這個類裡面有一個叫做CreateEndpoints()的方法，它會獲取所有Controller的Action方法。
然後針對每個Action方法，它會建立一個Endpoint例項。這些Endpoint例項就是包裝了Controller和Action方法的執行的請求委託（Request Delegate）。
ControllerActionEndpointDataSource裡面包儲存著在應用程式裡註冊的路由模板。
而針對每個Endpoint，它要麼與某個按約定的路由模板相關聯，要麼與某個Controller Action上的Attribute路由資訊相關聯。而這些路由在稍後就會被用來將Endpoint與進來的請求進行匹配。
從Endpoint的角度檢視請求-響應流程圖
App啟動那部分就不說了。
第一個HTTP請求進來的時候，Endpoint Routing中介軟體就會把請求對映到一個Endpoint上。它會使用之App啟動時建立好的EndpointDataSource，來遍歷查詢所有可用的Endpoint，並檢查和它關聯的路由以及元資料，來找到最匹配的Endpoint。
一旦某個Endpoint例項被選中，它就會被附加在請求的物件上，這樣它就可以被後續的中介軟體所使用了。
最後在管道的盡頭，當 Endpoint中介軟體執行的時候，它就會執行Endpoint所關聯的請求委託。這個請求委託就會觸發和例項化選中的Controller和Action方法，併產生響應。最後響應再從中介軟體管道原路返回。