XIAOSUO 记录个人学习的足迹

摘要：webapi：使用asp.net core使用c#创建的Restful服务，就是webapi, webapi中的控制器是派生自ControllerBase的类， ControllerBase类 不要通过从 Controller 类派生来创建 Web API 控制器。 Controller 派生自 ControllerBase，并添加对视图的支持，因此它用于处理 Web 页面，而不是 Web API 请求。 此规则有一个例外：如果打算为视图和 Web API 使用相同的控制器，则从 Controller 派生控制器。 ControllerBase 类提供了很多用于处理 HTTP 请求的属性和方法。 例如，ControllerBase.CreatedAtAction 返回 201 状态代码： 下面是 ControllerBase 提供的方法的更多示例。 方法 说明 BadRequest 返回 400 状态代码。 NotFound 返回 404 状态代码。 PhysicalFile 返回文件。 TryUpdateModelAsync 调用模型绑定。 TryValidateModel 调用模型验证。 特性 Microsoft.AspNetCore.Mvc 命名空间提供可用于配置 Web API 控制器的行为和操作方法的属性。 下述示例使用属性来指定受支持的 HTTP 操作动作和所有可返回的已知 HTTP 状态代码： HttpPost [ProducesResponseType(StatusCodes.Status400BadRequest)] public ActionResult Create(Pet pet) { pet.Id = _petsInMemoryStore.Any() ? _petsInMemoryStore.Max(p = p.Id) + 1 : 1; _petsInMemoryStore.Add(pet); return CreatedAtAction(nameof(GetById), new , pet); } 特性 说明 [[Route\]] 指定控制器或操作的 URL 模式。 [[Bind\]] 指定要包含的前缀和属性，以进行模型绑定。 [[HttpGet\]] 标识支持 HTTP GE…… 阅读全文

摘要：什么是API API全称Aplication Programming Itererface即应用程序编程接口， 我们在开发应用程序时经常用到。API作为接口，用来“连接”两个不同的系统，并使其中一方为另一 方提供服务，比如在操作系统上运行的应用程序能够访问操作系统所提供的API,并通过这些API来调用操,作系统的各种功能。因此，API 是一个系统向外暴露或公开的一套接口， 通过这些接口，外部应用程序能够访问该系统。在Web应用程序中，Web API具有同样的特性，它作为一个Web应用程序，向外提供了,在Web应用程序中，Web API具有同样的特性，它作为一个Web应用程序，向外提供了一些接口， 这些接口的功能通常是对数据进行操作,一些接口， 这些接口的功能通常是对数据进行操作(如获取或修改数据等)，它们能够被外部应用程序，比如桌面应用程序、手机应用甚至其他Web应用程序(如ASP.NET Core MVC视图应用、单页Web应用)等访问并调用。WebAPI能够实现不同应用程序之间的访问，它与平台或编程语言无关，可以使用不同的技术来构建Web API,如Java、.NET等; 什么是REST REST(Representational State Transfer) 表述性传递状态，Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格，作为一种web服务的设计与开发方式，Rest可以降低开发的复杂性，提高系统的可伸缩性。 REST是一种基于资源的架构风格，在REST中，资源(Resource)是最基本的概念任何能够命名的对象都是资源，如：user,team,order,docment。他表示web服务要操作的一个实体，一个资源具有一个统一资源标识符。(Uniform Resource Identifier URI),如 users/123。通过资源能够标识并访问资源。 资源标识 主键编号进行标识 资源集合 除了单个资源外，资源集合表示多个相同类型的资源，如users。在系统设计时，不同的实体之间往往存在着某种关联关系。如一个用户有多个订单。同样，在REST中，这种关联关系也能够有资源之间的层次关系体现出来。如users/123/orders/1 由于REST资源为中心，因此REST接口的端点(Endpoint)均以资源或资源集合结尾，它…… 阅读全文

摘要：OpenID Connect 如果要谈单点登录和身份认证，就不得不谈OpenID Connect (OIDC)。最典型的使用实例就是使用Google账户登录其他应用，这一经典的协议模式，为其他厂商的第三方登录起到了标杆的作用，被广泛参考和使用。 OpenID Connect简介 OpenID Connect是基于OAuth 2.0规范族的可互操作的身份验证协议。它使用简单的REST / JSON消息流来实现，和之前任何一种身份认证协议相比，开发者可以轻松集成。 OpenID Connect允许开发者验证跨网站和应用的用户，而无需拥有和管理密码文件。OpenID Connect允许所有类型的客户,包括基于浏览器的JavaScript和本机移动应用程序,启动登录流动和接收可验证断言对登录用户的身份。 OpenID的历史是什么？ OpenID Connect是OpenID的第三代技术。首先是原始的OpenID，它不是商业应用，但让行业领导者思考什么是可能的。OpenID 2.0设计更为完善，提供良好的安全性保证。然而，其自身存在一些设计上的局限性，最致命的是其中依赖方必须是网页，但不能是本机应用程序；此外它还要依赖XML，这些都会导致一些应用问题。 OpenID Connect的目标是让更多的开发者使用，并扩大其使用范围。幸运的是，这个目标并不遥远，现在有很好的商业和开源库来帮助实现身份验证机制。 OIDC基础 简要而言，OIDC是一种安全机制，用于应用连接到身份认证服务器（Identity Service）获取用户信息，并将这些信息以安全可靠的方法返回给应用。 在最初，因为OpenID1/2经常和OAuth协议（一种授权协议）一起提及，所以二者经常被搞混。 OpenID是Authentication，即认证，对用户的身份进行认证，判断其身份是否有效，也就是让网站知道“你是你所声称的那个用户”； OAuth是Authorization，即授权，在已知用户身份合法的情况下，经用户授权来允许某些操作，也就是让网站知道“你能被允许做那些事情”。 由此可知，授权要在认证之后进行，只有确定用户身份只有才能授权。 (身份验证)+ OAuth 2.0 = OpenID Connect OpenID Connect是“认证”和“授权”的结合，因为其基于OAuth协议，…… 阅读全文

摘要：OAuth2是什么 OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，第三方无需知道用户的账号及密码，就可获取到用户的授权信息 OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0 Oatuh2用来做什么 有这样一种场景，一个用户（假设是QQ），希望让一个第三方的应用（比如说某个论坛），能够得到关于自身的一些信息（唯一用户标识，比如说QQ号，用户个人信息，比如说是一些基础资料，昵称和头像等）。但是在获得这些资料的同时，却也不能提供用户名和密码之类的验证信息。比如说用户不可能将自身的用户名和密码给第三方让第三方到用户中心之类的地方去获取信息。要达到这样的结果肯定有许多的实现方式。而Oatuh2就是实现上述目标的一种规范，或者说是具体实现的指导方案。 Oauth2具体做法 OAuth定义了四个角色： 资源所有者（resource owner）： 能够对受保护资源授予访问权限的实体。当资源所有者是一个人时，它被称为终端用户。 资源服务器（resource server）： 托管受保护资源的服务器，能够接受和响应通过令牌对受保护的资源的请求。 客户端（client）： 代表资源所有者及其授权进行受保护资源请求的应用程序。术语“客户端”并不暗示任何特定的实现特征（例如，应用程序是在服务器，台式机还是其他设备上执行）。 授权服务器（authorization server）： 成功后，服务器向客户端发出访问令牌验证资源所有者并获得授权。 授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器可以是与资源服务器相同的服务器或单独的实体。单个授权服务器可以发出可以被多个资源服务器接受的访问令牌。 Oauth2的流程 Oauth2，根据RFC6749文档，大致的流程如下图所示 上图中的client就是第三方应用。可以看到，Oauth的大致思路是一个线性的流程。 第三方应用向资源持有者请求获取资源 资源持有者授权给予第三方应用一个许可 第三方应用将该许可给予认证服务器进行认证，如果认证成功，返回一个Access Token 第三方应用使用该access token到资源服务器处获取该access token对应的资源（也就是第一步中资源持有者自身的资源） …… 阅读全文

摘要：参考 在.net core 中使用AOP .NET Core中实现AOP编程--.NET西安社区 为AOP而生 — ASP.Net MVC默认的过滤器 AspNetCore 基于AOP实现Polly的使用 面向方面的编程 - 使用 RealProxy 类进行面向方面的编程 主要应用 日志记录 安全控制 性能统计 事务处理 异常处理 阅读全文

摘要：参考 C#执行异步操作的几种方式比较和总结 异步与多线程的区别(异步是目的，多线程是实现它的一种方式，异步的优先级有时候比主线程还高) - 子福当自强 - 博客园 c#异步编程 JavaScript异步机制与异步原理 异步编程的本质：绑定 - zzfx - 博客园 异步编程的本质:怎么处理异步请求(事件)与响应的关系 进阶篇：以IL为剑，直指async/await 官方文档 使用 Async 和 Await 的异步编程 .NET 异步详解 --能说清楚异步与多线程的区别，涉及到操作系统原理 await,async 我要把它翻个底朝天，这回你总该明白了吧 异步开发是什么 异步开发，就是利用线程技术,当执行一个占用时间长的任务时,不会阻止用户其它工作,而且其完成时会通知用户。 虽然是通过多线程来实现异步，但是因为一般异步时耗时的操作都不是针对CPU的，所以对CPU压力影响不大。 异步本质是通过线程池提高线程的利用率。 异步采用IO的DMA模式，不会消耗CPU资源。计算密集的工作，采用多线程。IO密集的工作，采用异步 举例：网络爬虫爬数据，如果数据很庞大，这个时候就需要使用异步了。 DMA：Direct Memory Access是IO的操作模式，可以直接访问内存，不经过CPU，不消耗CPU资源。 异步和多线程区别就是，充分利用DMA释放CPU压力。 异步实现方式：.net中实现异步的方式有定时器和多线程，一般都是使用多线程。 **使用场景：**要执行耗时且不需要立刻返回结果的操作，如：I/O操作、网络操作 争议： 有种说法是：异步是不阻塞当前主线程执行，通过子线程去执行，还有总说法刚好相反，具体参考：异步与线程阻塞 同步、异步、并行区别 同步：代码执行顺序默认是一行一行执行的，要等当前行的代码执行完后，才会执行下一行的代码。 异步：不用等当前行代码执行完毕就会执行下一行的代码。异步编程是一项关键技术，可以直接处理多个核心上的阻塞 I/O 和并发操作 并行：许多个人计算机和工作站都有多个 CPU 内核，以便多个线程能够同时执行。 为了利用硬件，你可以对代码进行并行化，以将工作分摊在多个处理器上。 并行和多线程、异步和多线程有啥关系？ 异步和多线程：多线程是创建多个线程，消耗的是CPU，异步呢？ 异步方法返回类型：void、Task、Task 异步编程模式： 基于…… 阅读全文

摘要：CPU是什么 我们都知道的定义是这样的：CPU又称中央处理器，它的英文全称为：Central Processing Unit，但同时如果你听到：Central Processor或者Main Processor往往同样也指的是CPU。 普通程序员开发的程序，其实绝大多数指的就是对中央处理器也就是CPU的编程。这句话也可能会被面试人员反着描述为，计算机的可编程性主要是指对中央处理器的编程。 在最初的时候，大约是1970年代以前，中央处理器由多个独立单元构成，后来才发展成集成电路，这些高度收缩的组件就是所谓的：微处理器。 另外，中央处理器广义上来说，是可以指代一系列可以执行复杂的计算机程序的逻辑机器。还记得三体中秦始皇嬴政派出无数士兵进行逻辑与或非运算吗？那样的场景，其实就是实现了广义上的中央处理器。 注意：ENIAC(Electronic Numerical Integrator And Computer)是世界上第一台”电子存储式可编程计算机”，但是由于他们也存在计算功能，而CPU的标准定义为：执行软件(计算机程序)的设备所以，ENIAC理论上不存在标准的CPU，但是最早于存储程序型计算机一通登场的设备是可以被称作CPU的，也就是说：CPU并不一定是微型的，早起的同步CPU是非常大的。直到1950~60年代的晶体管CPU时，CPU才慢慢变小。不再以体积庞大，不可靠与易碎的开关组件(继电器/真空管)组成或建造。 参考来自于维基百科，与哈佛计算机原理书籍，国内的一些小众参考资料与翻译是错误的，一定要注意。CPU并不小。尤其是百度百科，它所提供的参考资料只提及了”微”，但是万物相对论，没有相对何来形容词？从本段落开始，咱们只讨论：冯·诺依曼机，不讨论哈佛架构。 CPU的主要运作原理 CPU的主要运作原理很简单。不论其外观，都是执行存储与被称为”程序”里的一系列指令。所以说计算机是最愚蠢的傻子，没有码农他们就是一坨铁。 在冯诺依曼架构中，程序以一系列数字存储在计算机存储器中。 而只要是冯诺依曼机，CPU的运作原理就可以看成四个阶段：提取，解码，执行，回写。 提取：从程序内存中检索指令(程序内存，指的可不是你程序里面定义了一个int的这个内存，而是存储程序的内存)，由程序计数器指定程序存储器的位置，计数器保存供识别当前程序位置的数值(原始资料原文)。 拿人话说：程序计数…… 阅读全文

摘要：前面介绍了 DDD 分层架构，同时也提到了微服务架构模型其实还有好多种，不知道你注意到了没？这些架构模型在我们的实际应用中都具有很高的借鉴价值。 那么今天我们就把 DDD 分层架构、整洁架构、六边形架构这三种架构模型放到一起，对比分析，看看如何利用好它们，帮助我们设计出高内聚低耦合的中台以及微服务架构。 整洁架构 整洁架构又名“洋葱架构”。为什么叫它洋葱架构？看看下面这张图你就明白了。整洁架构的层就像洋葱片一样，它体现了分层的设计思想。 在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施。 整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。 在洋葱架构中，各层的职能是这样划分的： 领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则。领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。 领域服务实现涉及多个实体的复杂业务逻辑。 应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。 最外层主要提供适配的能力，适配能力分为主动适配和被动适配。主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。 红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。 六边形架构 六边形架构又名“端口适配器架构”。追溯微服务架构的渊源，一般都会涉及到六边形架构。 六边形架构的核心理念是：应用是通过端口与外部进行交互的。我想这也是微服务架构下API 网关盛行的主要原因吧。 也就是说，在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web应用以及数据库资源等）完全隔离，仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。 六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下： 红圈内的六边形实现应用的核心业务逻辑； 外六边形完成外部应用、…… 阅读全文

摘要：前面我们讲了 DDD 的一些重要概念以及领域模型的设计理念。 今天我们来聊聊“DDD 分层架构”。微服务架构模型有好多种，例如整洁架构、CQRS 和六边形架构等等。每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进。而 DDD 分层架构的出现，使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置。 那 DDD 分层架构到底长什么样？DDD 分层架构如何推动架构演进？我们该怎么转向 DDD 分层架构？这就是我们这一讲重点要解决的问题。 什么是 DDD 分层架构？ DDD 的分层架构在不断发展。最早是传统的四层架构；后来四层架构有了进一步的优化，实现了各层对基础层的解耦；再后来领域层和应用层之间增加了上下文环境（Context）层，五层架构（DCI）就此形成了。 我们看一下上面这张图，在最早的传统四层架构中，基础层是被其它层依赖的，它位于最核心的位置，那按照分层架构的思想，它应该就是核心，但实际上领域层才是软件的核心，所以这种依赖是有问题的。后来我们采用了依赖倒置（Dependencyinversion principle,DIP）的设计，优化了传统的四层架构，实现了各层对基础层的解耦。 我们今天讲的 DDD分层架构就是优化后的四层架构。在下面这张图中，从上到下依次是：用户接口层、应用层、领域层和基础层。那 DDD各层的主要职责是什么呢？下面我来逐一介绍一下。 1.用户接口层 用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。 2.应用层 应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。 此外，应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排。 这里我要提醒你一下：在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现。因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱。 另外，应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过A…… 阅读全文

摘要：在事件风暴（EventStorming）时，我们发现除了命令和操作等业务行为以外，还有一种非常重要的事件，这种事件发生后通常会导致进一步的业务操作，在 DDD中这种事件被称为领域事件。这只是最简单的定义，并不能让我们真正理解它。那到底什么是领域事件？领域事件的技术实现机制是怎样的？今天，我们就重点解决这两个大的问题。 领域事件 领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。 举例来说的话，领域事件可以是业务流程的一个步骤，比如投保业务缴费完成后，触发投保单转保单的动作；也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；或者一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。 那如何识别领域事件呢？ 很简单，和刚才讲的定义是强关联的。在做用户旅程或者场景分析时，我们要捕捉业务、需求人员或领域专家口中的关键词：“如果发生……，则……”“当做完……的时候，请通知……”“发生……时，则……”等。在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。 那领域事件为什么要用最终一致性，而不是传统SOA 的直接调用的方式呢？ 我们一起回顾一下之前讲到的聚合的一个设计原则：在边界之外使用最终一致性。一次事务最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的最终一致性。 领域事件驱动设计可以切断领域模型之间的强依赖关系，事件发布完成后，发布方不必关心后续订阅方事件处理是否成功，这样可以实现领域模型的解耦，维护领域模型的独立性和数据的一致性。在领域模型映射到微服务系统架构时，领域事件可以解耦微服务，微服务之间的数据不必要求强一致性，而是基于事件的最终一致性。 回到具体的业务场景，我们发现有的领域事件发生在微服务内的聚合之间，有的则发生在微服务之间，还有两者皆有的场景，一般来说跨微服务的领域事件处理居多。在微服务设计时不同领域事件的处理方式会不一样。 1.微服务内的领域事件 当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化，发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。 微服务内大部分事件的集成，都发…… 阅读全文