我是从.net 4.5直接跳到.net core 3.x的，感觉asp.net这套东西最初是从4.5中的owin形成的。
目前官方文档重点是讲路由，没有特别说明与传统路由的区别，本篇主要介绍终结点路由的相关概念和如何使用，不会详细介绍路由，这个参考官方文档就ok了。如果将来有机会研究到底层再深度剖析。
参考：
https://docs.microsoft.com/zh-cn/aspnet/core/fundamentals/routing?view=aspnetcore-3.1
https://q.cnblogs.com/q/113644/
https://aregcode.com/blog/2019/dotnetcore-understanding-aspnet-endpoint-routing/
最初我们访问 时，服务端是存在a.aspx这个文件的，服务端根据此文件帮我们创建一个对应类的实例处理请求。
后来需求越来越复杂，出现了路由，目的是将请求地址与执行请求的处理器的直接关联，变成映射关联，映射规则由我们自己配置。
在asp.net core 3.x之前这个路由系统是包含在mvc内部的，.net framework时代有个特殊的HttpModule来实现mvc，路由系统也包含其中。.net core是由有个特殊的中间件来实现mvc的，路由系统就包含在这个中间件中。
这种方式有个问题，mvc只是一个中间件，路由系统包含在其中，如果我们希望在mvc中间件之后加入其它中间件，其它中间件是无法（也许是不方便）访问路由相关信息的。
另外asp.net core并不是只有mvc，还有webapi、blazor、signlR、接入gRpc等，将来还有更多，我们的路由系统能否提出来，让所有框架都可以用？
因此出现了终结点路由，我们说路由的根本目的是将用户请求地址，映射为一个请求处理器，最简单的请求处理器可以是一个委托 Func<HttpCotnext,Task>，也可以是mvc/webapi中某个controller的某个action，所以从抽象的角度讲 一个终结点 就是一个处理请求的委托。由于mvc中action上还有很多attribute，因此我们的终结点还应该提供一个集合，用来存储与此请求处理委托的关联数据。
从抽象的角度可以简单理解为 一个终结点 = 处理请求的委托 + 与之关联的附加（元）数据。对应到mvc来理解的话 终结点 = action + 应用其上的attribute集合。但记住终结点是个抽象的概念，并不只服务于mvc，原理大概如下：
在程序启动前我们应该定义好程序中有哪些终结点，当然不是我们手动一个个定义，而是根据目标框架自动生成，针对mvc来说的话可以自动将程序中与路由匹配的action转换成对应的终结点，其它框架应该也有对应的方式，反正最终我们所有用来处理请求的东东都变成了终结点。这步是在定义路由时自动完成的
除了定义终结点我们还要定义 请求路径 与 终结点的对应关系，将来请求抵达时才能匹配找到合适的终结点来处理我们的请求，这步相当于定义路由
我们还需要定义一个解析器，当请求抵达时根据终结点与路径的对应关系找到终结点，微软已定义好对应的中间件来表示这个解析器。
最后我们需要定义一个中间件，在上面的中间件执行后 我们可以拿到与当前请求匹配的终结点，最终调用它的委托处理请求，这个中间件就是mvc中间件
到此asp.net core 3.x的中间件路由默认差不多就这样了，此时我们可以定义自己的中间件，放在步骤3后面，拿到终结点做一些高级处理。微软定义的一些中间件也是这个套路
如何使用在通过vs默认模板创建asp.net core 3.x项目时，在startup中会看到这样的代码
1 app.UseRouting(); 2 app.UseEndpoints(endpoints => { 3 endpoints.MapControllerRoute( 4 name: "default", 5 pattern: "{controller=Home}/{action=Index}/{id?}"); 6 });