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方法就会被执行。
