.NET Core

最近GRPC很火，感觉整RPC不用GRPC都快跟不上时髦了。 gRPC设计 gRPC是一种与语言无关的高性能远程过程调用 (RPC) 框架。刚好需要使用一个的RPC应用系统，自然而然就盯上了它，但是它真能够解决所有问题吗？不见得，先看看他的优点： gRPC的主要优点： 现代高性能轻量级 RPC 框架。 协定优先 API 开发，默认使用协议缓冲区，允许与语言无关的实现。 可用于多种语言的工具，以生成强类型服务器和客户端。 支持客户端、服务器和双向流式处理调用。 使用 Protobuf 二进制序列化减少对网络的使用。 对应的适用场景： 微服务 ：gRPC 设计用于低延迟和高吞吐量通信。 gRPC 对于效率至关重要的轻量级微服务非常有用。 点对点实时通信 ：gRPC 对双向流式传输提供出色的支持。 gRPC 服务可以实时推送消息而无需轮询。 多语言环境 ：gRPC 工具支持所有常用的开发语言，因此，gRPC 是多语言环境的理想选择。 网络受限环境 ：gRPC 消息使用 Protobuf（一种轻量级消息格式）进行序列化。 gRPC 消息始终小于等效的 JSON 消息。 gRPC还是有缺点的： 浏览器支持受限 ：绝大数浏览器不支持 HTTP/2 非人工可读取 ：proto文件规定的格式在通讯中会序列化成二进制数据，人工解析较为困难。 不适用的场景与替代： 浏览器可访问的API ：gRPC

国产龙芯的软件生态之中.NET不会缺席，毕竟 C# 与 .NetCore/Mono 也是全球几大主流的编程语言和运行平台之一，最近一段时间听到太多的鼓吹政务领域不支持.NET， 大家都明白这是某些人为了自己的利益打压使用.NET技术的公司，我今天写这篇文章就是想通过龙芯团队的行动告诉更多人一起来推动.NET技术在中国的发展。希望龙芯厂商、支持龙芯的国产操作系统厂商能高度重视这个问题，主动加入 .Net Core 社区，加入.NET基金会，积极贡献代码，尽快做好适配工作。 龙芯团队一直在做net core的mips64移植工作，2020年6月18日完成了里程碑性的工作，在.NET Core 3.1分支上完成了MIPS64 的移植工作，目前已经在github上开源，开源地址： https://github.com/gsvm/coreclr 。具体说明可以参见 https://github.com/dotnet/runtime/issues/38069 。 龙芯团队正在做移植后的测试工作，已经完成了 9500 多项测试，ASP.NET Core示例程序 FlightFinder 已经可以在MIPS64 上正常运行，具体可以参看 https://github.com/dotnet/runtime/issues/4234 。 龙芯团队还在github上面为龙芯.NET 建立了一个仓库

前言 .NET 中GC管理你服务的内存分配和释放,GC是运行公共语言运行时(CLR Common Language Runtime)中,GC可以帮助开发人员有效的分配内存和和释放内存,大多数情况下是不需要去担心的,但是有时候服务总是是出现莫名的问题，所以还是有必要了解一下GC的基础知识的。这里就不介绍内存方面的知识了。 GC回收过程 GC 将对象分为大对象和小对象，如果对象的大小大于或者等于 85000byte 将被视为大对象，大对象会被分配到到 (LOH) Large Object Heap 中去。 GC 有一个代数的概念 Generation ,分为三代 Generation 0 : 0代，这里面都是生命周期很短的对象，比如临时变量，当你new一个对象的时候该对象都会在 Generation 0 中，这里的对象将很快的被GC回收，但是当你new的是一个大对象的时候它会直接进去大对象堆(LOH) Generation 1 : 1代，这一代包含的也基本是生命周期很短的对象。它是短期对象和长期对象之间的缓冲区。 Generation 2 : 2代，这一代包含的都是生命周期长的对象，它们都是从1代和2代中选拔出来的， LOH 属于2代。 当分配的对象使用的内存超出了 GC 的阈值时回收就会开始。阈值是随着服务的运行 GC 自己调整的。或者直接调用 GC.Collect

一次依赖注入不慎引发的一连串事故 起因和现象 偶尔会看到线上服务启动的时候第一波流量进来之后， 迟迟没有任何的响应，同时服务的监控检查接口正常， 所以 K8S 集群认为服务正常，继续放入流量。 查看日志基本如下： [2020-06-05T13:00:30.7080743+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test [2020-06-05T13:00:30.7081525+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-balance does not match a supported file type [2020-06-05T13:00:31.7074253+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR21" started. [2020-06-05T13:00:31.7077051+00:00 Microsoft.AspNetCore

还记得 .NET Framework 的 ASP.NET WebForm 吗？那个年代如果要在 Web 层做单元测试简直就是灾难啊。.NET Core 吸取教训，在设计上考虑到了可测试性，就连 ASP.NET Core 这种 Web 或 API 应用要做单元测试也是很方便的。其中面向接口和依赖注入在这方面起到了非常重要的作用。 本文就来手把手教你如何用 xUnit 对 ASP.NET Core 应用做单元测试。.NET Core 常用的测试工具还有 NUnit 和 MSTest，我本人习惯用 xUnit 作为测试工具，所以本文用的是 xUnit。 创建示例项目 先用 ASP.NET Core API 模板建一个应用。 模板为我们自动创建了一个 ValuesController，为了方便演示，我们只留其中一个 Get 方法： public class ValuesController : ControllerBase { // GET api/values/5 [HttpGet( "{id}" )] public ActionResult< string > Get ( int id) { return "value" ; } } 然后再添加一个 xUnit 单元测试项目： 模板自动为我们添加好了 xUnit 引用： < ItemGroup > < PackageReference

nginx大家如果没用过那或多或少都应该听过，vue的部署、反向代理、负载均衡nginx都能帮你做到。 今天主要说一下nginx负载均衡我们的项目，如下图所示,请求到达nginx，nginx再帮我们转发。 首先使用Docker安装nginx. docker pull nginx:latest 运行容器，将本地的8080端口映射到容器内部的 80 端口. docker run --name nginx -p 8080 : 80 -d nginx 查看nginx容器,如果有错请看日志. 浏览器中访问一下 ok,到此我们的nginx就已安装完成。 我们准备好3个以上的webapi的项目并发布。 进入nginx容器 Docker exec -it nginx bash 找到nginx.conf文件并作修改，nginx.conf分为http块、events块和server块,此次主要在server块中做更改. 此时在nginx容器里面使用vi或者vim没有用，需要依次执行如下两条命令 apt- get update apt - get install vim 进入文件内,末尾处指向了另一个文件,没错这个文件里就是放server块配置内容 进入etc/nginx/conf.d/default.conf文件中并做修改 upstream ServiceInstance{

ASP.Net Core 3.1 With Autofac ConfigureServices returning an System.IServiceProvider isn't supported. 前言 Autofac在ASP.Net Core3.0以后，集成方式有所调整。在ASP.Net Core2中我们一般是把 Startup 的 ConfigureServices 方法返回值类型改为 IServiceProvider 。我们可以先看一下部分代码： public IServiceProvider ConfigureServices(IServiceCollection services) { services.AddMvc(); //xxxxxx你的其他代码 省略........... //用Autofac来替换IOC容器 返回值由 void 修改为 IServiceProvider var containerBuilder = new ContainerBuilder(); containerBuilder.RegisterModule<CustomAutofacModule>(); containerBuilder.Populate(services); var container = containerBuilder.Build(); //将当前的容器保存起来

应用场景 1.公司电脑与家中电脑的 远程控制 ，一般通过teamview、向日葵等软件，端口互通后，可以使用电脑自带的远程桌面 2.家中电脑搭建 SVN、git仓库 ，在外网或者内网访问，一般使用云服务器，端口互通后，可以部署在任意电脑 3.家中电脑搭建 数据库 、 web服务 以及 其他基于TCP协议的服务 ，端口互通后，可以部署在任意电脑 注意：并不是说就不需要购买云服务器了，而是运行的服务可以部署在任意电脑，云服务器仍是必须的，但是可以买最便宜的服务器以达到省钱的目的 技术原理 模式一 服务器中转： 　　场景：我们有电脑A和电脑B，他们在不同的局域网，现在我们需要在电脑A访问电脑B的web服务（端口是80） 　　原理：我们通过监听电脑A的端口80，当此端口接收到http请求的时候，程序将通过一些操作，在电脑A、服务器以及电脑B中建立一条专用TCP链接，然后电脑A将80端口接收到的数据转发到服务器中，然后服务器再把数据发送给电脑B的80端口，从而实现访问电脑B的web服务的目的。 模式二 直接连接： 　　场景：我们有电脑A和电脑B，他们在不同的局域网，现在我们需要在电脑A访问电脑B的web服务（端口是80） 　　原理：我们通过监听电脑A的端80，当此端口接收到http请求的时候，程序将通过一些操作，在电脑A与电脑B中建立一条直连的TCP连接

2020/01/29, ASP.NET Core 3.1, VS2019, EntityFrameworkCore 3.1.1, Microsoft.Extensions.Logging.Console 3.1.1, Microsoft.Extensions.Logging.Debug 3.1.1 摘要：基于ASP.NET Core 3.1 WebApi搭建后端多层网站架构【5-网站数据库实体设计及映射配置】 网站数据库实体设计，使用EntityFrameworkCore 3.1 FluentAPI映射配置实体，网站启动时创建数据库并添加种子数据，开发调试时可以看到执行的具体sql语句 文章目录 此分支项目代码 本章节介绍后台管理的网站数据库实体设计，使用FluentAPI方式配置数据库字段映射，网站启动时创建数据库并添加种子数据 需求分析 首先要实现的功能有用户登录、角色管理、日志记录 大概有四张表：用户表、密码表、角色表、日志表 日志表： 用户表： 密码表： 角色表： 好像博客园md不支持表格功能？所以只能截图展示，excel表格上传至项目docs文件夹中 字段设计说明 日志表主键Id是数据库自增的，也就是在向数据库插入日志时，不用管Id，往里写入就行 用户表、角色表的Id都是long类型的，也就是使用雪花算法生成的Id 密码表的主键是Account，UserId是用户表外键

一，引言 前天我们将到使用Azure的 Pass 服务 “Web App” 去部署我们的.NET Core Web项目，也同时有介绍到如何在VS中配置登陆中国区的Azure账号，今天接着讲，我们部署完我们的Web服务，进行完测试后，肯定是要发布到生产环境，但是我们不可能再去创建一个相同的Web App，配置上生产环境的域名，配置上生产环境的数据库连接字符串等等，而 Azure 的 Web App是可以通过自己的一个叫 “Deployment slots（部署槽）”的功能进行切换。我们来看一下微软给出的使用部署槽的优点，以下是微软的官方文档提到的优势 将应用程序部署到非生产槽具有以下优点： 可以在分阶段部署槽中验证应用更改，并将其与生产槽交换。 首先将应用部署到槽，然后将其交换到生产，这确保槽的所有实例都已准备好，然后交换到生产。 部署应用时，这样可避免停机。 流量重定向是无缝的，且不会因交换操作而删除任何请求。 当不需要预交换验证时，可以通过配置自动交换来自动化这整个工作流。 交换后，具有以前分阶段应用的槽现在具有以前的生产应用。 如果交换到生产槽的更改与预期不同，可以立即执行同一交换来收回“上一已知的良好站点”。 下面，我们正式开始今天的分享。 ----------我是分割线---------- Azure Web App 部署系列： 1，Azure Web App（一