dapper

目录 文章目录 目录 微服务架构的问题 如何拆分服务 服务间如何通信 微服务框架 API 网关 配置中心 Service Mesh 文档 微服务治理 监控 链路跟踪 日志分析 服务中心 熔断、服务降级、限流 微服务框架 Service Mesh 流量治理 微服务架构的问题 微服务架构中，服务之间会有错综复杂的依赖关系，例如：一个前端请求一般会依赖于多个后端服务，称为 “1=>N 扇出”。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源（线程，队列等）被耗尽，造成所谓的雪崩效应（Cascading Failure），严重时可致整个网站瘫痪。另外，微服务架构整个应用分散成多个服务，定位故障点非常困难。 服务组合 服务依赖： 微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。在解决了旧问题，也引入了新的问题： 微服务架构整个应用分散成多个服务，定位故障点非常困难。 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。 服务数量非常多，部署、管理的工作量很大。 开发方面

前言：sqlSugar出生已经有3年之久了，从1.0到现在的4.x的版本，为了以后方便使用SqlSugar,所以特意花了2个小时来叙述它。 关于SqlSugar 性能：性能最好的ORM之一,具有超越Dapper的性能 ，走的是EMIT够构中间语言动态编译到程序集，完成高性能的实体绑定，达到原生水平。 功能：支持 DbFirst、CodeFirst、数据库维护、链式查询、链式更新、链式删除、链式插入、实体属性、复杂模型的查询、ADO.NET。特别是批量等功能都是货真价实的并非循环操作。 兼容性：支持多种数据库,具体就是SqlSugar的DbType枚举中有MySql、Oracle、SqlLite、SqlServer、PostgreSQL 入门使用 以下代码是创建连接，其中属性构造器的四个值分别为连接字符串、数据库类型、是否自动销毁连接、获取自增列主键信息。 SqlSugarClient db = new SqlSugarClient(new ConnectionConfig() { ConnectionString = "Data Source=DESKTOP-OEJGKOO;Initial Catalog=TextInfo;Integrated Security=True", DbType = SqlSugar.DbType.SqlServer,

0. 前言 在前一篇中我们讲到了Dapper的应用，但是给我们的感觉Dapper不像个ORM更像一个IDbConnection的扩展。是的，没错。在实际开发中我们经常用Dapper作为对EF Core的补充。当然了Dapper并不仅仅只有这些，就让我们通过这一篇文章去让Dapper更像一个ORM吧。 1. Dapper Contrib Dapper Contrib 扩展了Dapper对于实体类的CRUD方法： 安装方法： 命令行： dotnet add package Dapper.Contrib NuGet： Install-Package Dapper.Contrib 使用： using Dapper.Contrib.Extensions; 这个是一个使得Dapper功能更强大的扩展包，因为支持了CRUD，所以需要对实体类添加配置，该扩展包使用Attribute作为依据进行相关映射配置： [Table("Model")] public class Model { [Key] [ExplicitKey] public int Id{get;set;} [Computed] public int Count {get;set;} [Write] public String Name{get;set;} } 这是所有的配置，Table用来声明是一个表，必须指定表名

目录 一，为什么选择SqlSugar？ 在.net core ORM框架中，能选择的方案其实有很多，包括以下方案： 1，EF-Core 2，Dapper 3，FreeSql 4，SqlSugar 为什么最后选择了Sqlsugar 呢？ 一个个来说， 首先是: EF-core 。 EF-core 一开始想法也是担心性能问题，大概在7年前 有尝试过一次EF，深深被EF的性能所折服 实在是太慢了，当然做一些小型项目，EF当然是体现不出性能差距的，但是谁又知道自己的“小项目”哪天不会随着 业务的发展变成“大项目” 呢？ 所以，一开始对EF 以及EF-Core 没有好感，不过后来看了，EF-Core的官网介绍， 感观上发生了很大的变化， 总的来说就是： EF 和 EF-Core 完全是两个东西。 更准确的说是：.net Core 和 .net Famework 完全是两个东西。 这么说吧, .net Core在性能上完全不怂 java，go，python，php 任何一种语言，再说.net 性能不好的，可以啪啪打脸了。 但是，我还是首先淘汰了，EF-Core。原因是，查百度各种ORM都拿EF-core 做性能测试，可以参考以下连接： 参考： https://www.cnblogs.com/kellynic/p/10557882.html 虽然，EF-Core 性能跟EF 不能同日而语，但是

十年河东，十年河西，莫欺少年穷 学无止境，精益求精 开发过.NetCore 的都知道，微软的EF框架EFCore对DataTable并不是特别友好，在整个EFCore框架中，直接写SQL语句似乎不太行，因此，在我们的项目中就有必要对数据库操作进行扩展。 自上篇博客 netCore 引用第三方ORM中间件-Dapper 后，我在项目架构时将Dapper引入到数据库操作层，使用后，我发现Dapper对 IQueryable 的支持几乎没有，【也可能有，但是我没发现】，这对于追求性能的开发人员来说难以接受，因此，今天引入sqlSugar。 Dapper的查询方法： 由上图可知，Dapper 支持IEnumerable ，IEnumerable 和 IQueryable 的区别是前者将数据全部加载到内存，后者是将需要的数据加载到内存。因此，IE比较浪费内存，IQ相对而言是按需开辟内存，因此，我选择IQ，虽说IQ在某些性能方面比不上IE，但现在的系统，大多都是数据量庞大的。 现在进入正题，sqlSugar的搭建。 俗话说：工欲善其事必先利其器，因此，在项目搭建之前，我们需要准备一个小的数据库。 简单的数据库，只有两张表， 1、打开VS，新建一个netCore3.1的控制台程序，并新增两个类库，如下： 2、SugarEntity为实体层，实体层代码有项目或工具生成，当然，也可以手写。注

十年河东，十年河西，莫欺少年穷 学无止境，精益求精 可恶的NetCore对DataTable支持的不好，这对于喜欢直接写SQL的童鞋来说非常难受，因此，在NetCore项目中有必要引入优秀的第三方数据库中间件，目前市场上比较优秀的第三方EF框架有很多，例如： Sqlsugar 、 Dapper 、 FreeSql 等，当然，微软也有自己的一套EF框架，EntityFrm 和 EfCore，就效率而言，第三方的框架要完胜微软的EF框架，真不知道微软是干啥吃的、 今天，我们使用Dapper这个轻量级的第三方EF框架。 1.安装Dapper 　　这里直接使用Nuget安装。 安装完成后，我们需要对Dapper进行扩展，如下： using Microsoft.Extensions.Configuration; using System; using System.Data; using System.Data.SqlClient; using WuAnCommon; namespace WuAnSqlService { public class DapperHelper { /// 获取连接字符串 private static string Connection= ConfigCommon.Get( " WuAnDBContext " ); /// 返回连接实例 private

服务调用链路追踪 　　微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。 　　举个例子，在微服务系统中，一个来自用户的请求，请求先达到前端A（如前端界面），然后通过远程调用，达到系统的中间件B、C（如负载均衡、网关等），最后达到后端服务D、E，后端经过一系列的业务逻辑计算最后将数据返回给用户。对于这样一个请求，经历了这么多个服务，怎么样将它的请求过程的数据记录下来呢？这就需要用到服务链路追踪。 　　Google开源的 Dapper链路追踪组件，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。　　 　　常见的业界开源解决方案 　　1、Dapper（谷歌） 　　2、Zikpin，与Spring Cloud Sleuth结合的比较好 　　3、Eagleeye（阿里） 　　4