ASP.NET Core

背景 相信前面几篇关于微服务的文章也介绍了那么多了，在构建微服务的过程中确实需要这么一个东西，即便不是在构建微服务，那么在构建分布式应用的过程中也会遇到分布式事务的问题，那么 CAP 就是在这样的背景下诞生的。 最初打算做这个东西是在去年（2016）年底，最初是为了解决分布式系统中的分布式事务的问题，然后当时有了一个大概的概念轮廓，当时我对于前面两篇文章中关于异步消息和微服务之间通讯还不是太了解，只是觉得这样能够解决这一系列的问题，然后就着手做了，最后发现和这些概念竟然不谋而合。 经过大半年的不断重构以及修改，最终 CAP 1.0 版本发布了。作为一个开源项目，最初项目是在我的个人Github下，然后于上个月已经贡献给了 .NET China Foundation 组织，目前该项目由我和 DotNetCore 项目组共同维护。 CAP 介绍 Github： https://github.com/dotnetcore/CAP 开源协议：MIT CAP 是一个在分布式系统中（SOA，MicroService）实现事件总线及最终一致性（分布式事务）的一个开源的 C# 库，她具有轻量级，高性能，易使用等特点。 你可以轻松的在基于 .NET Core 技术的分布式系统中引入CAP，包括但限于 ASP.NET Core 和 ASP.NET Core on .NET Framework。 CAP

‍ 最近一直在录 Blog.Core 相关的操作视频，也没有研究过什么新的东西，公司也各种项目迭代，特别是从Fwk迁移到NetCore，真的是不是一个容易的事，闲的时候，为了歇歇脑子，就抽出时间简单看了看又有哪些新技术，最近聊的挺多的就是Blazor了吧，所以我也看了看，这里声明一点，我并 不 打算出一个完整的Blazor系列教程（最近老有人让我出系列教程????），只是走马观花的过一遍，看看这个到底是一个什么东西，感兴趣的自己可以去深入学习下，毕竟现在的资料还不是最多的，可以锻炼下自己，而且也算是一个吃螃蟹的人，毕竟有历史价值，好啦，废话不多说，直接开整。 1、这个项目的立项初衷 可能还有一部分小伙伴不太了解，我年初申请上了微软的MVP，我也没有过多的宣传，毕竟这只是一个鼓励而已，平时该解答的我还是会解答。MVP呢，每次只有一年的有效期，所以每个新的一年都还需要风雨兼程的往前走，还是需要传递知识，那就少不了将自己做过的，写过的，分享过的东西给列出来（ 注意：这里可能有转载别人的文章 ），作为一个展示，所以呢，我就想着自己写个小的Portal吧，把 自己整理的东西给放出来，多半是微信公众号的 ，也可以给大家做一个方便查找和学习的列表。 但是在项目选型的时候，我犹豫了好几天，用什么呢，ASP.NET Core MVC么，其实我已经写了好多个了，公司的小项目也一直在使用，所以不想写了

背景 相信前面几篇关于微服务的文章也介绍了那么多了，在构建微服务的过程中确实需要这么一个东西，即便不是在构建微服务，那么在构建分布式应用的过程中也会遇到分布式事务的问题，那么 CAP 就是在这样的背景下诞生的。 最初打算做这个东西是在去年（2016）年底，最初是为了解决分布式系统中的分布式事务的问题，然后当时有了一个大概的概念轮廓，当时我对于前面两篇文章中关于异步消息和微服务之间通讯还不是太了解，只是觉得这样能够解决这一系列的问题，然后就着手做了，最后发现和这些概念竟然不谋而合。 经过大半年的不断重构以及修改，最终 CAP 1.0 版本发布了。作为一个开源项目，最初项目是在我的个人Github下，然后于上个月已经贡献给了 .NET China Foundation 组织，目前该项目由我和 DotNetCore 项目组共同维护。 CAP 介绍 Github： https://github.com/dotnetcore/CAP 开源协议：MIT CAP 是一个在分布式系统中（SOA，MicroService）实现事件总线及最终一致性（分布式事务）的一个开源的 C# 库，她具有轻量级，高性能，易使用等特点。 你可以轻松的在基于 .NET Core 技术的分布式系统中引入CAP，包括但限于 ASP.NET Core 和 ASP.NET Core on .NET Framework。 CAP

用文件模型绑定接口：IFormFile (小文件上传) 当你使用IFormFile接口来上传文件的时候，一定要注意，IFormFile会将一个Http请求中的所有文件都读取到服务器内存后，才会触发ASP.NET Core MVC的Controller中的Action方法。这种情况下，如果上传一些小文件是没问题的，但是如果上传大文件，势必会造成服务器内存大量被占用甚至溢出，所以IFormFile接口只适合小文件上传。 一个文件上传页面的Html代码一般如下所示： < form method ="post" enctype ="multipart/form-data" action ="/Upload" > < div > < p > Upload one or more files using this form: </ p > < input type ="file" name ="files" /> </ div > < div > < input type ="submit" value ="Upload" /> </ div > </ form > 为了支持文件上传，form标签上一定要记得声明属性enctype="multipart/form-data"，否则你会发现ASP.NET Core MVC的Controller中死活都读不到任何文件。Input type=

以ASP.NET Core WebAPI 作后端 API ，用 Vue 构建前端页面，用 Axios 从前端访问后端 API ,包括文件的上传和下载。 准备文件上传的API #region 文件上传 可以带参数 [HttpPost("upload")] public JsonResult uploadProject(IFormFile file, string userId) { if (file != null) { var fileDir = "D:\\aaa"; if (!Directory.Exists(fileDir)) { Directory.CreateDirectory(fileDir); } //文件名称 string projectFileName = file.FileName; //上传的文件的路径 string filePath = fileDir + $@"\{projectFileName}"; using (FileStream fs = System.IO.File.Create(filePath)) { file.CopyTo(fs); fs.Flush(); } return Json("ok"); }else{ return Json("no"); } } #endregion 前端vue上传组件 ( 利用Form表单上传 )

文章名称： 如何在ASP.NET Core自定义中间件读取Request.Body和Response.Body的内容？ 作者： Lamond Lu 地址： https://www.cnblogs.com/lwqlun/p/10954936.html 源代码： https://github.com/lamondlu/webapi-logger 背景 最近在徒手造轮子，编写一个ASP.NET Core的日志监控器，其中用到了自定义中间件读取Request.Body和Response.Body的内容，但是编写过程，并不像想象中的一帆风顺，ASP.NET Core针对Request.Body和Response.Body的几个特殊设计，导致了完成以上功能需要绕一些弯路。 原始代码 为了读取Request.Body和Response.Body的内容，我的实现思路如下： 创建一个LoggerMiddleware的中间件，将它放置在项目中间件管道的头部。因为根据ASP.NET Core的中间件管道设计，只有第一个中间件才能获取到原始的请求信息和最终的响应信息。 Request.Body和Response.Body属性都是Steram类型， 在LoggerMiddleware中间件的 InvokeAsync 方法中，我们可以分别使用 StreamReader 读取Request

网上这部分的文章和资料很多，有一篇非常不错的文章（《 Net Core 基于Ocelot＋IdentityServer4＋Eureka的搭建高性能网关介绍 》），也介绍了这个内容，我也是参考了其中的某些步骤，一步一步演练下来，感觉.NET Core在微服务生态方面也是越来越成熟，功能也越来越强大。因此，我也撰写记录一下整个步骤，通过Step by Step的形式，加上一些注解，以及对于一些遇到的坑的描述，将整个实践过程记录下来，以便帮到有需要的读者，也为自己的学习做个记录。我不会再在概念性的问题上多费笔墨，比如什么是API网关、Ocelot、IdentityServer4、Eureka又是什么之类的问题，我不会做过多的说明，我会争取用最简单快捷的方式，将相关的实践内容描述清楚，虽然本文的标题后面加了一个“（一）”的字样，代表还会有后续的文章，因为我觉得一篇估计讲不完。 案例场景 在我之前写的《 .NET Core中Ocelot的使用 》系列文章中，我设计了一个场景，同时涉及了两个微服务的RESTful API，当时使用两个微服务，不仅是为了介绍API网关的主要功能，而且还引入了服务发现的内容，因此，使用两个微服务来演示会比较合理。当然，今天我们已经学习过API网关和服务发现的基本知识了，我就进一步将案例场景简化，我们只做一个API：Countries API，在这个API中

这个问题是使用 docker 生成了 asp.net core 网站镜像，在使用 nginx 指向此镜像容器后，用的子路径虚拟路径，但是因为反向代理，asp.net core 并不认为是从子路径过来的，直接访问 controller 的 action 方法没问题，但是如果生成 view 内容时，view 再引用的资源路径就会错误。 在 nginx 中的配置： location /backstage/web/ { proxy_pass http://web-backstage/ ; proxy_set_header X_Real_IP $remote_addr ; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ; proxy_set_header Host $host ; proxy_connect_timeout 600 ; proxy_send_timeout 600 ; proxy_read_timeout 600 ; send_timeout 600 ; } 解决方法（环境：.net core 3.1），修改 Startup.cs 配置： public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { var

　　在写这篇博客的时候，因为新冠肺炎疫情影响本人已经在湖北老家隔离一个多月了，当然这一个多月以来心中也是各种滋味，五味杂陈，生活中总是有太多的困难在考验着我们，但总归要去面对，并一步步去把困难踩在脚下，闲暇之余也是该对过去的2019年来做一个系统性的梳理工作了，只有不断去总结才能明得失，然后找到自己的不足，并在新的一年去努力探寻解决方案，最后才能不断取得进步，不辜负光阴，最终实现自己的人生价值。 　　还是和往常一样，主要是从纯技术上和生活中对过去的一年进行一个细致的总结，2019年是自己来上海的第五个年头，也是自己进行Asp.Net Core进行开发的第二年，这一年对技术和生活上上的理解有了更多的理解，经历过很多东西，感觉也是自己快速成长的阶段，说真的这一年真的也是非常辛苦，无论是业务设计团队、软件开发团队、BA、QA、运维......每一个团队都在为奇瑞的整个售后管理DMS软件系统贡献着自己的力量，从整个系统3家经销商试用，到后面增加到50家，再到最后100家......每一次成倍地增加经销商都是对整个系统并发性的一个巨大的挑战，每一个Sprint迭代都是对整个团队的巨大考验，因为越到后面每一次需求的变更都是对整个系统的一次巨大考验。最后一块报表的开发更考验对整个业务系统的熟练程度的掌控力，这里面遇到过很多的困难，好在整个团队克服了种种困难，最终都很好完成了这一切

本系列相关文章： 《ASP.NET Core中Ocelot的使用：API网关的应用》 《ASP.NET Core中Ocelot的使用：基于Spring Clound Netflix Eureka的动态路由》 本文将基于前两篇文章所述内容，继续介绍如何在服务发现和动态路由的基础上，使用Ocelot实现负载均衡。Ocelot本身是带有负载均衡功能的，这一点其实跟Nginx提供的 HTTP load balancer 是类似的功能（我觉得整个Ocelot提供的功能，通过Nginx也都可以实现，不过Ocelot更加.NET化，对于.NET开发人员来说更为简单和容易接受）。根据官方文档，Ocelot支持如下几种负载均衡策略： LeastConnection：根据服务当前正在处理的请求个数来决定将使用哪个服务来处理新接收到的请求，将请求转发给当前连接数最少的服务 RoundRobin：经典模式，轮询法，逐个选择可用的服务来处理接收到的请求 NoLoadBalancer：仅使用第一个可用的服务来处理接收到的请求 CookieStickySessions：通过使用Cookie，确保特定的请求能够被分配到特定的服务上进行处理 今天我们选择RoundRobin来看看如何基于服务发现来实现负载均衡。同样，首先需要对架构进行调整。 调整架构 与上文中的架构相比，这里不会引入新的服务