XIAOSUO 记录个人学习的足迹

摘要：最近有一个重写一个电商老系统的需求。这是一个运行了10来年的单体应用，随着业务的越来复杂，这套系统已经很难维护了，性能也越来越差，公司也终于启动了重写计划。 重写肯定是不会再使用单体架构了，具体是用分布式架构，还是微服务来写，其实也就是服务的颗粒度划分的问题。但无论是分布式还是微服务，系统的复杂度会是增加几十甚至上百倍。 在重写之前，我一直在想是完全从零开始搭建框架，还是使用ABP这样提供了基础设施最佳实践的框架。好在公司的业务也不是很复杂，几个人的团队已经可以着手重写的任务了。于是我计划在搭建框架前，先跟团队一直深入学习一遍ABP的底层。 ABP是模块化设计理念可以说是它的精髓，这也是之所以要学习这个框架的原因。我们的计划是使用ABP的基础核心库来打架项目基础创建，这样重写时哪些可以用ABP的基础设施来直接搭建应用，哪些要完全自建底层逻辑，哪些甚至可以套用旧代码简单重构，就会轻松很多。 说了这么多，不管是分布式还是微服务，ABP还是从零开始，首先要做的是对齐设计思想。而这绕不开的就是DDD，我们今天先来总结一下DDD的核心思想。 一、什么是领域驱动设计 1. 传统软件开发 业务梳理 == 软件设计 == 开发 初期-简单-迭代-复杂-冗杂-屎山代码-牵一发而动全身-重构系统-演进 示例：订单服务（查询订单、创建订单、订单评价、支付……） 项目流程：讨论需求==数据库建模==项目开发==迭代数据库的设计==上线 2. 领域驱动开发 根据领域知识一步步驱动软件设计的过程就是领域驱动设计（DDD,Domain-Driven Design） 领域驱动设计（DDD）是一种处理高度复杂领域的设计思想 设计思想：通过分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性 项目流程：领域模型=数据库设计 3. 战略设计和战术设计 领域驱动设计包括战略设计和战术设计两部分： 战略设计：从业务视角出发=》业务领域模型=》边界=》通用语言的限界上下文 战术设计：从技术视角出发=》技术实现=》实体、聚合根、值对象、领域服务…… 二、领域驱动设计的基础概念 1. 领域和子域 领域（业务问题域）具体指一种特定的范围或区域，就是用来确定范围的，范围就是边界 细分-限定-领域模型-代码实现 领域越大业务范围就越大 领域可以进一步划分为子领域（子域 更小的） 子…… 阅读全文

摘要： 阅读全文

摘要：一、CAR 1. CAR本质 URL请求----调用Action----生成html响应(或其他响应) CAR就是个普通类---普通方法---最终生成HTML(也可能是其他的) 一个URL，怎么调用的Action---一定是反射----反射创建控制器实例，反射准备方法参数，反射调用Action方法(也许来点优化) 然后生成一段内容(啥都可以)，写入到Response里面---然后由Kestrel回发到浏览器----浏览器解析报文做呈现 先Get这个本质，不要被各种封装各种特性看花眼了~ 2. 关键节点-上帝视角 CAR虽然是最后才生效，但是在前面也出现了---全流程debug一下，回顾一下： 启动环节services.AddControllers注册IOC时扫描dll，保存到ApplicationManager 初始化中间件MapControllerRoute()转成ControllerActionDescripter 第一次请求进入，路由初始化DFAMatcher时触发转换成Endpoint，路由匹配找到Endpoint---鉴权授权--- 执行Endpoint时实例化和缓存各种工厂、 Filter等---做好调用准备 执行Filter管道， ActionBegin状态实例化控制器， Bind参数 ActionInside状态开始执行Action，得到ActionResult ResultInside状态开始执行ExecuteResult，得到结果 Controller-Action-Result流程结束 3. CAR源码 按照主流程往后走，先关注Controller，再Action，再Result，其中会有回溯 步骤1： services.AddControllers注册时扫描dll，转成ApplciationPart，保存到ApplciationPartManager 知识点：当前项目引用的dll都算数，所以是独立类库---扩展PartDemo 收集完的内容都是保存在ApplciationPartManager—等于是个中间层，其实就可以开个后门，通过其他方式添加数据进去---所以可以热插拔 甚至可以动态编译脚本---后插拔进去 步骤2：初始化中间件MapControllerRoute()注册UpdateCollection，注册Updat…… 阅读全文

摘要：一、快速认识Filter 1. 流程衔接点 MVC(Filter+Controller+Action+Result)流程和前面的各种中间件Middleware处理，是如何衔接起来的？ Http请求穿过一系列中间件，最终由路由RoutingMiddleware匹配得到RouteEndpoint 在EndpointMiddleware里面会执行其RequestDelegate，委托执行时就是FilterController-Action-Result 该委托在ControllerRequestDelegateFactory里面来构建的，里面通过ControllerActionInvoker来调用 这里有个新名字叫 FilterPipeline 2. 快速认识Filter Filter是MVC里面核心组成部分，有着丰富的种类，交叉的顺序，复杂的嵌套，很有挑战！ Filter分2种： 声明特性，实现Filter接口：CustomSimpleShowActionFilterAttributeCustomSimpleShowAsyncActionFilterAttributeCustomSimpleShowDoubleActionFilterAttribute:一个Filter里面既有同步，又有异步，只执行异步！能改参数，能改结果，非常强大注意异步版本的结果修改坑 控制器类实现Filter接口包括Action同步异步-Result同步异步---控制器生效，全部Action都有效 3. AOP面向切面编程 要说Filter，得理解下AOP面向切面编程Aspect Oriented Programming POP面向过程，没有封装没有边界，难以应对复杂需求OOP面向对象，有封装有边界，能应付复杂需求，但原子---类---不容破坏，否则会影响稳定性---开闭原则 AOP能在不破坏封装的前提下，去额外扩展功能比如ActionFilter，啥都没修改，就能增加执行逻辑AOP的好处： 聚焦业务逻辑，轻松扩展功能 代码复用，集中管理 4. 框架中的AOP 现代化开发框架中，要灵活应用AOP面向切面编程思想： ASP.NET Core三层AOP 中间件：离MVC比较远，面向与请求级的事儿 Filter：更贴近MVC，面向单个请求,更细一些 IOC容器的AOP扩展：细化到具体业…… 阅读全文

摘要：从Http无状态协议---用户持久化的需求---最初是Cookie+Session---Token但是不管是哪种方式，有一段内容是不变的： 请求服务端，获取凭证 客户端再次请求，带上凭证 服务端识别凭证，判断是否允许访问 认证授权的本质是做啥的？ 其实就是第3步解决用户识别和判断授权的问题被拆分成了2个动作： 认证Authentication：凭证识别解析，有没有登陆，凭证有没有过期，是张三还是李四 授权Authorization：基于解析来权限检测，判断下张三/李四有没有权限访问这个资源 一、实操 1. 没有任何权限要求实操 添加相关控制器， Cookie式登陆方法 UseAuthentication + AddAuthentication + Cookie UseAuthorization + AddAuthorization(可不写) [Authorize] [AllowAnonymous] 校验流程： 未登陆，直接访问，跳转登录页 AllowAnonymous可直接访问 登陆后跳转，正常访问 退出后访问，跳转登陆页 2. 授权 Roles授权： [Authorize(Roles = Admin)] Policy授权： [Authorize(Policy = AdminPolicy)] 复杂Policy授权： [Authorize(Policy = MutiPolicy)] 授权的设计，也是可以满足开发者各种这样的需求—目前还没演示完 如果是没有登陆，是跳转LoginPath---401 如果是有凭证，但没有权限，是跳转AccessDeniedPath--403 3. 发送了什么？ 请求到达Action之前，即使没有标记，也会自动认证 主动认证：理解认证信息保存 主动授权：理解授权检测过程 4. 理解总结 认证授权是ASP.NET Core框架封装的2个中间件，目的在于请求进入具体的Filter-M-V-C之前，通过中间件完成用户权限检测包含2个步骤： 认证Authentication：鉴别有没有登陆，解析是张三还是李四(且将信息传递下去)---UseAuthentication配置Http管道，保证请求来了，都要做一次凭证的解析AddAuthentication配置IOC，告诉如何认证(凭证在那儿，啥格式的) 授权Authori…… 阅读全文

摘要：一、核心流程概述 执行AddMVC() 将MVC的核心服务注册到容器，且通过反射扫描把相关dll收集起来 执行app.UseRouting() 将EndpointRoutingMiddleware中间件注册到http管道 执行app. MapControllerRoute() 将本程序集定义的所有Controller-Action-ParameterConversion转换为一个个的ControllerActionDescriptor放到路由中间件的配置对象RouteOptions中,注册并传入EndpointMiddleware中间件注册到http管道中 请求来了，管道模型Build---没啥动作，倒序执行中间件的实例化 收到一条http请求，先进入EndpointRoutingMiddleware，首次请求时会完成ControllerActionDescriptor到EndPoint的转化，然后通过DFA算法匹配一个Endpoint，并放到HttpContext中去 鉴权/授权/其他中间件可以根据根据Endpoint的信息对这个请求进行鉴权授权或其他操作。 EndpointMiddleware中间件执行Endpoint中的RequestDelegate逻辑，即执行FilterController-Action-Result等系列操作(MVC) 二、AddMVC 1. 上帝视角 AddMVC（AddControllersWithViews）是最初发生的，是IOC注册环节的事儿，在管道注册之前，其职责有2个： 添加MVC各种IOC注册，超多。。 反射遍历相关程序集，封装成ApplicationPart，供后续使用 2. 源码解读 从MvcServiceCollectionExtensions开始，绕一圈，最终是AddMvcCore()方法 先实例化ApplicationPartManager-----拿着项目名字，通过反射加载Dll，将信息封装到ApplciationPartManager的ApplicationParts属性中---扩展点 ConfigureDefaultFeatureProviders(partManager);的调用，这行代码是创建了一个新的ControllerFeatureProvider实例放进了partManager的Fea…… 阅读全文

摘要：一、ExceptionHandler ASP.NET Core管道最外面，就是app.UseExceptionHandler(/Home/Error);这个是全局异常处理，这个/Home/Error在哪里？ 直接看源码 UseExceptionHandler----ExceptionHandlerExtensions，开启新的Http管道，里面就是个ExceptionHandlerMiddlewareImpl------注册中间件 异常真的发生了，中间件的Invoke方法，看catch里面，最终是到ErrorPage.design.cs文件---请求响应时 没有Add，因为太简单了---没啥东西 中间件其实有3件事儿： AddXXX----builder.Build()期间，去完成的IOC注册 UseXXXX---app.Run()期间，去完成中间件注册，组装Http管道 Middleware的InvokeAsync()—请求响应时，才执行 关于全局异常处理中间件和Filter的区别 ExceptionHandlerMiddleware是全局性质，是兜底的----而ExceptionFilter其实只管控制器-Action的异常，是管不了View-ResultFilter的异常 精细度不同，中间件只知道模糊信息，不适合做业务处理----ExceptionFilter贴近业务的，可以返回业务信息 其实完整的异常方案，就应该是二者叠加-- 二、HTTPS HstsMiddleware HSTS 是 HTTP 严格传输安全(HTTP Strict Transport Security) 的缩写效果是：优先使用https---如果有https，就使用这个 源码解读： HstsMiddleware-----就是设置个header--- Strict-Transport-Security= maxage= HttpsRedirection UseHttpsRedirection 就是优先访问https，访问http会自动跳转（后台有配置https）效果：直接VS的https启动，访问http，开关中间件尝试https://localhost:7066 http://localhost:7067 源码： HttpsPolicyBuilderExtension…… 阅读全文

摘要：一、HttpPipeline 1. 理解Http请求流程 Http请求响应流程，也就是浏览器输入个地址，发生了什么事儿： 浏览器输入地址， www.xxx.com DNS解析，找到IP+Port，然后浏览器向该地址发Http报文---纯文本 Nginx/IIS/Kestrel监听端口，收到报文解析得到HttpContext 将请求转发到业务代码处理---怎么进入到controller+action？ 处理结果由服务器回发到客户端，浏览器解析报文完成渲染 所谓HttpPipeline就是程序如何处理请求的全过程--- 理解Http管道所处的位置： Web服务器解析报文之后，在Web服务器回发报文之前 Http管道和controller-action的关系：其实是包含关系，任何处理动作都是管道的一部分 2. 理解Http管道 HttpPipeline本质是个啥？ 接受HttpContext，然后做一系列的处理(Cookie Session 鉴权授权 缓存 路由 MVC)---最终将结果保存在HttpContext的Response里面 然后在ASP.NET Core里面，就被抽象成为一个委托—RequestDelegate---接受一个HttpContext，然后执行一系列操作 但是开发中，管道模型是很复杂的呀？因为Http请求的处理并不简单，包含了很多环节---Cookie/Session/鉴权授权/缓存/https/静态文件-------还有就是各种不同的业务处理需求(M-V-C)-----还有开发者的扩展需求(限流—黑名单白名单)-----所以需要一套扩展性的框架 这套实现，就是ASP.NET Core的HttpPipeline 3. 管道模型上帝视角 先创建个WebApplicationBuilder()---然后各种配置IOC/Logging/Configuration---然后Build()完成了各种初始化---得到WebApplication WebApplication去Use添加添加中间件(委托)---实际上是ApplicationBuilder在Use------就是把中间件(Func委托)保存到一个集合 最后框架在Run的时候，会执行ApplicationBuilder的Build方法，将委托集合遍历调用，组装成最终的RequestDel…… 阅读全文

摘要：一、从.NET Framework到.NET Core 1. 本质 .NET Framework：描述的是上层应用框架，底层就只支持windows平台， BCL CLR都是只有一个 .NET Core： 2016年.NETCore1.0，特点是3个CLR共存的（NET Framework、NER Core、XAMARIN） 最后个版本是.NET Core3.1 .NET5：终结3个分支，统一，一个CLR，一个BCL——2020年全球疫情，导致很多内容没完成 .NET6：口号也是统一平台，各种该实现的都实现了一下 .NET7：进一步完善统一，没有太大的变化，缝缝补补 2. 跨平台的理解 运行时CLR——CoreCLR C#程序——》编译器——》DLL/EXE(metadata、IL)——》CLR/JIT——》机器码 不能跨平台是因为只有一个CLR，不同的CLR匹配不同的平台 以前不能开发Linux的CLR，是因为NET Framework底层库依赖window，如IIS，画图库等 3. ASP.NET Core有哪些好处的功能 依赖注入 日志系统架构 引入了一个跨平台的网络服务器，kestrel 试用appsettings来配置工程 试用startup来注册服务 更好的支持异步编程 对于跨网站请求的预防和保护机制 验证令牌 @Html.AntiForgrtyToken 使用HTTPS 设置CSP（内容安全策略）：定义哪些资源可以被加载和执行，减少XSS攻击风险 context.Response.Headers.Add(Content-Security-Policy, default-src 'self'; script-src 'self' https://xxx.com); 强大的验证和数据绑定功能：如[BindRequired]、[BindNever]属性 使用安全API端点设计：如JWT进行认证 4. ASP.NET Core有哪些更好的地方 跨平台 对架构本身安装没有依赖，因为所有的依赖都跟程序本身在一起 处理请求的效率更高，能够处理更多请求 更多安装配置方法 二、ASP.NET Core启动流程 创建WebApplicationBuilder：做一些信息读取 配置WebApplicationBuilder：各种…… 阅读全文

摘要：什么是无服务器计算 “无服务器”是云计算中资源抽象的极致体现。从它的命名上你就可以看出，所谓“无服务器”就是想让用户感觉不到服务器的存在，这是因为有一朵巨大的云在底层进行着支撑。 如果说容器是给予了我们很大的定制空间，让你更加容易地按照自己的需要，来进行应用程序的拆分和封装；那么无服务器则是完全屏蔽了计算资源，它是在真正地引导你不再去关心底层环境，你只要遵循标准方式来直接编写业务代码就可以了。 而且在粒度上，无服务器会允许你拆分得更细致、更轻量。你甚至可以把每一个具有独立功能的函数，来作为一个单独的服务进行部署和运行。这也是为什么，在有些云计算的分类方法下，无服务器计算能够单独“开宗立派”，被称为函数即服务（Function-as-a-Service，FaaS）的原因。 各大云厂商现在都已经推出了各自的无服务器计算服务，比如 AWS 的 Lambda、阿里云的函数计算，和微软 Azure 的 Azure Functions。在国内的云厂商中，腾讯云的云函数也是在无服务器计算上投入较早、产品较为成熟的厂商。 无服务器计算是多面手 无服务器计算所能做的，可远远不止充当快速的 Web 开发工具。事件模型是无服务器的核心编程模型和运行逻辑，所以它非常适合相当广泛的事件驱动开发场景。 事件的起始，要依靠触发器。 云上 Serverless 服务一般都配套提供了多种多样的触发器，包括 API 触发器、对象存储触发器、队列触发器等等。比如上面的实验中，我们用的就是API 触发器，它的触发条件为 API 网关带来的外部 Web 请求。 较为常用的还有对象存储触发器。比如当用户上传了一个文件，后台程序把它保存到对象存储中，这时相应的无服务器函数会被这个新对象触发，你就能对这个新上传的文件进行必要的处理了。 此外，还值得了解相当实用的定时触发器，它可以按照设置的条件周期性触发。通过它和云函数的配合，可以在一定程度上代替操作系统中 crontab 类工具起到的作用，也许能帮你节省一台专门触发运行定时任务的虚拟机。 如果说触发器是无服务器计算的上游的话，那么各种各样的外部交互方式，也让无服务器计算能够对外访问，并向下游输出。云端的 Serverless 环境中，一般都能够提供一系列重要类库和 SDK，让你能够在函数内访问其他云服务，尤其是像数据库、消息队列这样的外部存储。 所以，在云端…… 阅读全文