XIAOSUO 记录个人学习的足迹

摘要：基于原始SQL查询创建LINQ查询，代替旧版的FromSql、SqlQuery 基本原生 SQL 查询 在版本.net core 2.0 中，我们引入了一种在依赖关系注入中注册自定义 DbContext 类型的新方法，即以透明形式引入可重用 DbContext 实例的池。 要使用 DbContext 池，请在服务注册期间使用 `AddDbContextPool` 而不是 `AddDbContext`：services.AddDbContextPool<BloggingContext>( options => options.UseSqlServer(connectionString)); 如果使用此方法，那么在控制器请求 DbContext 实例时，我们会首先检查池中有无可用的实例。 请求处理完成后，实例的任何状态都将被重置，并且实例本身会返回池中。 从概念上讲，此方法类似于连接池在 ADO.NET 提供程序中的运行原理，并具有节约 DbContext 实例初始化成本的优势。 阅读全文

摘要：需求背景 假设，你正在参与开发一个微服务。微服务通过 HTTP 协议暴露接口给其他系统调用，说直白点就是，其他系统通过 URL 来调用微服务的接口。有一天，你的 leader 找到你说，“为了保证接口调用的安全性，我们希望设计实现一个接口调用鉴权功能，只有经过认证之后的系统才能调用我们的接口，没有认证过的系统调用我们的接口会被拒绝。我希望由你来负责这个任务的开发，争取尽快上线。” 需求分析 1. 第一轮基础分析 对于如何做鉴权这样一个问题，最简单的解决方案就是，通过用户名加密码来做认证。我们给每个允许访问我们服务的调用方，派发一个应用名（或者叫应用 ID、AppID）和一个对应的密码（或者叫秘钥）。调用方每次进行接口请求的时候，都携带自己的 AppID 和密码。微服务在接收到接口调用请求之后，会解析出 AppID 和密码，跟存储在微服务端的 AppID 和密码进行比对。如果一致，说明认证成功，则允许接口调用请求；否则，就拒绝接口调用请求。 2. 第二轮分析优化 不过，这样的验证方式，每次都要明文传输密码。密码很容易被截获，是不安全的。那如果我们借助加密算法（比如 SHA），对密码进行加密之后，再传递到微服务端验证，是不是就可以了呢？实际上，这样也是不安全的，因为加密之后的密码及 AppID，照样可以被未认证系统（或者说黑客）截获，未认证系统可以携带这个加密之后的密码以及对应的 AppID，伪装成已认证系统来访问我们的接口。 这就是典型的“重放攻击” 。 提出问题，然后再解决问题，是一个非常好的迭代优化方法。对于这个问题，我们可以借助 OAuth 的验证思路来解决。调用方将请求接口的 URL 跟 AppID、密码拼接在一起，然后进行加密，生成一个 token。调用方在进行接口请求的的时候，将这个 token 及 AppID，随 URL 一块传递给微服务端。微服务端接收到这些数据之后，根据 AppID 从数据库中取出对应的密码，并通过同样的 token 生成算法，生成另外一个 token。用这个新生成的 token 跟调用方传递过来的 token 对比。如果一致，则允许接口调用请求；否则，就拒绝接口调用请求。 3. 第三轮分析优化 不过，这样的设计仍然存在重放攻击的风险，还是不够安全。每个 URL 拼接上 AppID、密码生成的 token 都是固定的。未认证系统截…… 阅读全文

摘要：概念------为什么-----如何使用----运行原理------熔断-----降级-----超时------重试----封装 -----consul和polly整合到项目中 首先我们来明确一下，微服务架构的基本单位是微服务，也就主体是微服务----同时每一个微服务都有自己的结构。这些结构组合成了一个微服务（这属于文件夹分层发）这个时候，那么每一个微服务都会出现相同的结构。这个时候很多同学会有疑问，为什么各个微服务之间这些相同的文件不能够进行通用呢,反而会出现这么多冗余。这样做的原因，1、保证微服务的独立性，2、保证微服务的稳定。我举个例子：微服务就好比我们每一个人，我们每一个人就组成了一个社会架构，微服务和这种场景是类似的。大家都知道，每个人的结构都是一样的。如果每个人结构都全部集中到一起。会出现什么问题，大家可以想象一下。全部乱套了。同理，微服务也是一样。所有微服务的第一要务就是保证独立性。所以我这里对微服务采用文件夹分层法。 对于什么时候用程序集分层。先明白一下，每一个微服务都有自己的领域模型（也就是我们昨天说的问题和问题边界）。如果多个微服务之间。存在不得不共享资源，共享资源是不易变化，且变化不影响每一个微服务的逻辑的时候。那么我们就把这通用的逻辑抽取出来，用dll来分层进行引用，例如：微服务之间都需要通信，需要认证，需要限流，负载均衡等等。那么咱们就把这一层称作为工具层。 什么是熔断 熔断就是在被调用端出现宕机，和超时两种情况出现的一种策略应对机制。 熔断就好比保险丝，我们先来看一看保险丝的情况 为什么要使用熔断 服务调用出现异常(包括超时和宕机两种情况) 如果服务连续几次都出现异常，那么就将服务进行熔断一段时间， 服务调用出现异常(包括超时和宕机两种情况) 如果服务连续几次都出现异常，那么就将服务进行熔断一段时间 服务调用出现异常(包括超时和宕机两种情况) 如果服务连续几次都出现异常，那么就将服务进行熔断一段时间 什么是降级 为什么要使用降级 服务主动降级（选择性放弃） 主动将服务进行进行异常返回 服务异常降级 如果服务调用出现超时或者宕机的情况，就按照自定义的策略进行返回。 服务主动降级（选择性放弃） 主动将服务进行进行异常返回 服务异常降级 如果服务调用出现超时或者宕机的情况，就按照自定义的策略进行返回。 服务主动降…… 阅读全文

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

摘要：什么是托管代码(managed code) 　 托管代码(Managed Code)就是中间语言(IL)代码，在公共语言运行库(CLR)中运行。编译器把代码编译成中间语言，当方法被调用时，CLR把具体的方法编译成适合本地计算机运行的机器码，并且将编译好的机器码缓存起来，以备下次调用使用。随着程序集的运行，CLR提供各种服务：内存管理，安全管理，线程管理，垃圾回收，类型检查等等。 　　托管代码是一microsoft的中间语言(IL)，他主要的作用是在.NET FRAMEWORK的公共语言运行库(CLR)执行代码前去编译源代码，也就是说托管代码充当着翻译的作用，源代码在运行时分为两个阶段： 源代码编译为托管代码,（所以源代码可以有很多种，如VB,C#,J#) 托管代码编译为microsoft的平台专用语言 　　编译器把代码编译成中间语言(IL)，而不是能直接在你的电脑上运行的机器码。中间语言被封装在一个叫程序集(assembly)的文件中，程序集中包含了描述你所创建的类，方法和属性(例如安全需求)的所有元数据。你可以拷贝这个程序集到另一台服务器上部署它。 　　托管代码在公共语言运行库(CLR)中运行。这个运行库给你的运行代码提供各种各样的服务，通常来说，他会加载和验证程序集，以此来保证中间语言的正确性。当某些方法被调用的时候，运行库把具体的方法编译成适合本地计算机运行的机械码，然后会把编译好的机械码缓存起来，以备下次调用。(这就是即时编译)随着程序集的运行，运行库会持续地提供各种服务，例如自动垃圾回收、运行库类型检查和安全支持等。这些服务帮助提供独立于平台和语言的、统一的托管代码应用程序行为。 　　Visual Basic .NET和C#只能产生托管代码。如果你用这类语言写程序，那么所产生的代码就是托管代码。如果你愿意，Visual C++ .NET可以生成托管代码。当你创建一个项目的时候，选择名字是以.Managed开头的项目类型。例如.Managed C++ application。 什么是非托管代码(unmanaged code) 　　非托管代码，直接编译成目标计算机码，在公共语言运行库环境的外部，由操作系统直接执行的代码，代码必须自己提供垃圾回收，类型检查，安全支持等服务。如需要内存管理等服务，必须显示调用操作系统的接口，通常调用Windows SDK…… 阅读全文