早期路由系统
.NET Core2.2之前的框架中，中间件管道的结尾有一个Router中间件，也就是路由中间件，这个路由中间件会把HTTP请求和路由数据发送给MVC的一个组件，它叫做MVC Router Handler。
这个MVC 路由 Handler就会使用这些路由数据来决定哪个Controller的Action方法应该来负责处理这个请求。
然后 Router中间件就会执行被选中的Action方法，并生成响应，而这个响应就会顺着中间件的管道原路返回。
早期路由系统的弊端：
在Router中间件之前的中间件不知道请求被哪个Controller/Action处理了。如果你在中间件中想知道被哪个Action处理了，必须将逻辑卸载Router中间件中，导致职责耦合。
在core中授权中间件、CORS中间件都支持策略，通过Contrller上的Attribute获取对应策略，所以需要在Router中间件之前知道请求被路由到哪个Controller/Action,以及标识的Attribute等信息
Endpoint Routing路由系统
Endpoint routing 路由系统解决了以上问题。使用了两个中间件
- app.UseRouting()。它是用来标记路由决策在请求管道里发生的位置，也就是在这里会选择端点
- app.UseEndpoints()。它是用来执行选中的Endpoint，从而让其生成响应的
这样做的好处就是，我们可以在选择端点和执行端点的中间位置插入其它的中间件。这样的话，插入到中间位置的中间件就会知道哪个端点被选取了，而且它也有可能会选择其它的端点
Endpoint Routing中间件
Endpoint Routing 中间件会分析进来的请求，并把它和在程序中注册的Endpoints进行比较。它会使用这些 Endpoints 上面的元数据来决定哪个是处理该请求的最佳人选。然后，这个选中的Endpoint 就会被赋给请求的对象，而其它后续的中间件就可以根据这个选中的Endpoint，来做一些自己的决策。在所有的中间件都执行完之后，这个被选中的Endpoint最终将被 Endpoint中间件所执行，而与之关联的Action方法就会被执行。
如果中间件中需要获取到Controller、Action信息，将中间件放到Endpoint Routing和Endpoint两个中间件之间，通过以下代码获取信息
Endpoint endpoint = httpContext.GetEndpoint();
ControllerActionDescriptor controllerActionDescriptor = endpoint.Metadata.GetMetadata<ControllerActionDescriptor>();
var controllerType = controllerActionDescriptor.ControllerTypeInfo;//Controller Type
var allowAnonymous = endpoint.Metadata.GetMetadata<IAllowAnonymous>();//AllowAnonymousAttribute
Endpoint
Endpoint类中包含一个请求的委托（Request Delegate）和其它的一些元数据，使用这些东西，Endpoint类可以生成一个响应。
而在MVC的上下文中，这个请求委托就是一个包装类，它包装了一个方法，这个方法可以实例化一个Controller并执行选中的Action方法。
Endpoint还包含元数据，这些元数据用来决定他们的请求委托是否应该用于当前的请求，还是另有其它用途。
ControllerActionEndpointDataSource
ControllerActionEndpointDataSource里面包存储着在应用程序里注册的路由模板
ControllerActionEndpointDataSource类作为应用程序级别的服务被创建了
这个类里面有一个叫做CreateEndpoints()的方法，它会获取所有Controller的Action方法
然后针对每个Action方法，它会创建一个Endpoint实例。这些Endpoint实例就是包装了Controller和Action方法的执行的请求委托（Request Delegate）
而针对每个Endpoint，它要么与某个按约定的路由模板相关联，要么与某个Controller Action上的Attribute路由信息相关联。而这些路由在稍后就会被用来将Endpoint与进来的请求进行匹配。
属性路由
webapi更适合属性路由，添加以下代码可以支持属性路由
