做了个基于 VCommon 的 ASP.NET Core 项目案例
作者:V君 发布于:2021-7-19 15:11 Monday 分类:折腾手记
前言
这是啥?简单用一句话来讲这就是一个山寨(简化?)版的 ABP 项目,用来学习 WebAPI 后端的完整流程以及做些个人项目。这几天抽了许多时间来摸 ASP.NET Core 尝试把 VCommon 用起来。进展还算顺利,那就淡定地水一水吧。
TL;DR
源代码:[VcommonCore] [本项目]
快速上手:
1)将 VcommonCore 和本项目克隆到同一个文件夹,打开本项目尝试编译
2)在配置文件按实际情况配好 MySQL 和 Redis
3)在包控制台用 update-database 命令创建数据库
4)如果没有异常,那就可以按 F5 跑起来看 Swagger 了
x)目前只有 SaaS 的基础功能。
TL;DR之后就是折腾感想了,主要还是和传统 ASP.NET 的差别以及适配
感想其一:配置文件。传统的 ASP.NET 只要在 Web.Config 配了连接字符串或者 AppSetting 就可以在任意位置使用 ConfigurationManager 来获取。不过这一套在 Core 已经行不通了,于是我从 ABP 项目抄来读取配置文件的实现,顺利地兼容了 EFCore 命令行工具和 ASP.NET Core 环境。EFCore 的方式完全照搬,而 ASP.NET Core 环境就得自己实现任意位置访问了,把配置对象注册到 IoC 容器中去!
感想其二:中间件。由于一开始就想绕过 ASP.NET 繁琐的生命周期,于是选用了 HttpModule 来把请求按约定的路径拦截下来并做出处理。换到 Core 之后,它没有 HttpModule 了,咋办?咕狗呗,找到微软的迁移文档,给 VCommon.VOpenApi 做了个中间件,从而平滑过渡到 Core。
感想其三:HttpContext/Session/RequestScope。传统的 ASP.NET 可以从任意位置通过静态成员获取当前上下文,然鹅转换到 Core 之后 HttpContext 的静态成员 Current 没有了,咕狗回来发现大伙们都用依赖注入的方式把上下文注册到 IoC 容器中。由于 HTTP 的无状态性,直接把上下文注册到容器是会乱套的,这时候就需要改变 UnityContainer 的使用姿势,用起派生容器了。插一句,或许有的人看不起 UnityContainer 说其老旧性能低下,但它自带的接口拦截功能还是很香的,它不需要把业务方法定义成虚方法,性能也还可以接受。在 WebAPI 请求处理的中间件调用业务方法之前,从根容器派生出子容器,将其作为 RequestScope 来使用,把上下文以及依赖上下文的组件一起注册进去,这样就不会乱套了。
最后,埋个伏笔(?)啥时候不咕了,那就用 VCommon 来做一个自己的博客吧!
在 IIS 使用 web.config 配置域名端口跳转
作者:V君 发布于:2020-2-9 0:21 Sunday 分类:小服杂记
— TL;DR —
按需将以下配置节点添加到 web.config ,修改目标域名,完成。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<security>
<requestFiltering>
<fileExtensions allowUnlisted="true">
<remove fileExtension=".cs" />
</fileExtensions>
</requestFiltering>
</security>
<rewrite>
<rules>
<rule name="RedirectGogs" stopProcessing="true" enabled="true">
<match url="^gogs/(.*$)" />
<action type="Redirect" redirectType="Temporary" url="https://gogs.topcl.net:8443/{R:1}"/>
</rule>
<rule name="RedirectExaWww" stopProcessing="true" enabled="true">
<match url="^(?![\._].*$).*" />
<conditions>
<add input="{HTTP_HOST}" pattern="www\.example\.com" />
</conditions>
<action type="Redirect" redirectType="Temporary" url="https://blog.example.com:8443/{R:0}"/>
</rule>
<rule name="RedirectExa" stopProcessing="true" enabled="true">
<match url="^(?![\._].*$).*" />
<conditions>
<add input="{HTTP_HOST}" pattern="example\.com" />
</conditions>
<action type="Redirect" redirectType="Temporary" url="https://blog.example.com:8443/{R:0}"/>
</rule>
<rule name="DefultRedirectBlog" stopProcessing="true" enabled="true">
<match url="^(?![\._].*$).*" />
<action type="Redirect" redirectType="Temporary" url="https://blog.topcl.net:8443/{R:0}"/>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
— 听我扯扯 —
咋一看,不就是 rewrite + redirect (307) 不就好? 其实没有那么简单,比如源代码连接里以 .cs 后缀的代码文件 (例)就在跳转的时候被 IIS 拦下来 404 了,因此还得额外加白。你可能会担心安全风险,但我这个空间仅仅用来跳转,根目录下只有这个 web.config 文件。
二月份的文章也只能这么水了,因为疫情只能把自己关在家
— 更新 —
将正则表达式改为 ^(?![\._].*$).* 可以忽略以指定字符开头的路径,方便申请 Let's 证书和临时放些文件,使配置更灵活
— 更新Ⅱ —
使用 conditions 实现别名支持,使空间变跳转 hub,将其利用价值榨干
WebActivatorEx重复执行?不!那是作为使用者的我们傻逼!!
作者:V君 发布于:2018-6-15 22:42 Friday 分类:挖坑经验
TL;DR:
如果在发布新版本后出现疑似WebActivatorEx启动入口被执行多次的情况
首先检查bin里面是否有上个版本残留的DLL,干掉它们就解决了,然后把锅甩给运维。
那么,开始我的故事。
~前奏~
由于首次在正式项目引入git源代码管理体系,仓库结构设计的相当散乱。
这不赶上重组git仓库,重新建立了解决方案,命名空间和项目名称也重新规划了。
~嘣咧挫~
好不容易发布一个新版本到测试环境,运行起来出现致命错误的黄页。
连最开始的初始化都没完成,错误处理也措手不及,好久不见的黄页就这样呈现出来。
~扯一扯~¶
由于不喜欢Log4Net这种只能用配置文件的充满Java味道的东西。
现在项目中的日志组件是由我自己实现的,有以下特性:
- 由写入时间决定文件名
- 6个级别,外加可选启用的虚拟级别“ALL”将其他级别内容凑一起输出
- 按指定大小分文件
- 多次启停可续写
- 自动删除指定天数的旧文件
写入方式是基于线程安全的FileStream共享只读打开,方便边写边看。
内容格式是三行一空行的条目:
- 第一行写时间、级别、线程信息(如果有写程序集,也能快速发现这次的问题。之后补上吧)
- 第二行写摘要,由开使用者定义的简短摘要
- 第三行写详情的JSON,有日志位置堆栈,可以加入任意对象作为附加信息
在日志组件初始化之后,我通常会打一句“Logger Init”在日志中体现应用程序启动。
我们有为此专门做了个小工具来分析日志,用上了Chris Nielsen的JSON可视化界面实现。
~诊断~
打住,话题收回来,黄页的错误信息是“文件被占用”,堆栈显示正在打“Logger Init”时…
一开始的时候很有自信,以为自己写的实现没问题,可能被文件共享出来占用了。
用Procexp查文件句柄,一个都没查出…
但作为应用程序启动的体现“Logger Init”却被打进日志文件里…
老大的意思是想让我先把多节点负载均衡砍掉,以单节点跑起来,降低复杂度再诊断。
当时没辙只好听话照办喽,然并卯。
还是掏出诊断大杀器ProcMon看看“是谁动了我的奶酪”,看到结果时开始觉得自信不足了:
——真的是ASP.NET程序池进程访问的文件,而且是同一条原生线程访问了两次。
——第一次成功打开,第二次打开失败,最后还把文件关闭了——由CLR,程序都崩溃了嘛!
难道是自己的实现有问题,多线程竞态现象?
.NET的托管线程可能会复用原生线程,出现TID一样的情况也不能排除多线程。
在初始化的地方加了锁,然而问题依旧存在。其实并不是我的代码写的不严谨,这是后话。
咋办?
让文件打开的共享模式可读可写吧,想到了这样高风险的激进尝试。
然而——还是失败了,但仔细观察发现ProcMon监视条目详情有蹊跷:
第一次打开文件的共享模式是只读,第二次才是符合激进尝试的可读可写。
两次打开文件的原生堆栈有差异,很可惜看不到托管堆栈,如果能看到程序集就能解决问题了。
远程调试吧。没办法的办法了,在日志初始化的地方打个断点看看会不会两次命中。
调试结果令人十分失望,只命中了一次,打开失败的第二次。天知道第一次在哪儿打开?
这时猫同事建议我把“Logger Init”改一下,看看有没有打出来。这才恍然大悟。
我拒绝了建议,且断言上个版本残留程序集,去服务器bin看看,断言成立!
抓住运维的肩膀使劲晃,“你让我浪费了两天的时间排查” 乂目
~结语~
甩完锅之后还是要总结一下教训的,发布版本应该将之前的文件干掉,再把新的包部署上去。
ASP.NET WEB场:在使用StateServer站点集群节点之间共享会话
作者:V君 发布于:2018-3-22 17:31 Thursday 分类:挖坑经验
TL;DR
步骤1: 在每个节点部署的web.config里配置状态服务为StateServer,使用一致的主机和端口;
步骤2: 为每个节点IIS网站设置一致的ID.
扯一扯:
终于有机会接触ASP.NET的WEB负载均衡, 运维配置好测试环境之后开始捣腾.
按照公司沿袭下来的习惯,用的是歪门邪道的nginx反向代理实现请求分发.
说到会话,当然就是登录状态啦! 一上来就掉进坑里: 登录不了.
诊断下来发现, 原来死循环重定向了: 因为节点之间会话不通,
导致节点A处理完登录之后回到节点B处理的首页,节点B没有得到会话判定为未登录
接着又重定向到节点A处理的登录页面, 登录页面会把已登录的请求重定向回首页.
如此反复, 甚是尴尬.
经过一番咕狗,找到M$DN上的帮助文档(325056),开始按照文档操作(这里又一次自己跳坑里).
由于错误理解帮助文档中所指的路径,误以为是部署web站点的文件路径要求一致,
尝试了之后发现不行,又回来仔细读文档. 这才发现要一致的是网站ID.
0rz.
排查ASP.NET响应迟钝.用DebugDiag分析转储,再用WinDbg+sosex查看调用参数
作者:V君 发布于:2017-6-9 17:01 Friday 分类:填坑经验
WEB应用程序出现响应很慢甚至卡死的现象,
Server Admin 通过 DebugDiag 分析转储发现有个请求特别耗时间 (一个小时以上)
于是锅放到我这里辣.
DebugDiag得出堆栈已经显示具体代码位置了,
想知道哪些数据被操作,还需要知道传入了哪些参数,这时候必须请出WinDbg+sosex了.
参考其 sosex 的 readme.txt 或 MSDN文章 得知 !mk 命令可以查看当前线程调用堆栈
要切换当前线程 使用 ~*s 命令 (更多命令参见 windbg.info文章 )
搞起! 先 .load sosex 再 ~*s 然后 !mk 这样就可以看到刚才的堆栈了,确保没选错线程
然而参数还没出来... 别急,呔! !mdso 列出当前线程堆栈上下文对象值
这个命令支持使用参数 /t:类名 来筛选结果. 这次排查过程顺利得有些出乎意料哇 乂目.
blogger
Google Web Translator
热门日志
随机日志
最新日志
最新评论
- V君
@Quartz:(出现)... - Quartz
怎么不见人了呢... - V君
@Soar:DHCP 协议相... - V君
@Soar:当然是非... - Soar
@V君:谢谢 有空... - Soar
搞一个 1230v3+B85... - V君
@Soar:另外,也可... - V君
@Soar:iscsi服务端... - Soar
难怪这么卡,尤其... - Soar
clone了源码,提示...
分类
存档
- 2024年5月(1)
- 2023年7月(1)
- 2023年5月(1)
- 2022年11月(1)
- 2022年10月(1)
- 2022年9月(1)
- 2022年8月(1)
- 2022年7月(1)
- 2022年6月(1)
- 2022年5月(2)
- 2022年4月(1)
- 2022年3月(1)
- 2022年2月(1)
- 2022年1月(1)
- 2021年12月(1)
- 2021年11月(1)
- 2021年10月(1)
- 2021年9月(1)
- 2021年8月(1)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(1)
- 2021年4月(1)
- 2021年3月(1)
- 2021年2月(1)
- 2021年1月(1)
- 2020年12月(1)
- 2020年11月(1)
- 2020年10月(2)
- 2020年9月(1)
- 2020年8月(1)
- 2020年7月(1)
- 2020年6月(1)
- 2020年5月(1)
- 2020年4月(2)
- 2020年3月(3)
- 2020年2月(1)
- 2020年1月(1)
- 2019年12月(1)
- 2019年11月(1)
- 2019年10月(1)
- 2019年9月(1)
- 2019年8月(2)
- 2019年7月(1)
- 2019年6月(1)
- 2019年5月(1)
- 2019年4月(1)
- 2019年3月(1)
- 2019年2月(1)
- 2019年1月(2)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(3)
- 2018年9月(4)
- 2018年8月(6)
- 2018年7月(4)
- 2018年6月(1)
- 2018年5月(2)
- 2018年4月(2)
- 2018年3月(3)
- 2018年2月(1)
- 2018年1月(1)
- 2017年12月(1)
- 2017年10月(2)
- 2017年9月(1)
- 2017年8月(2)
- 2017年7月(1)
- 2017年6月(5)
- 2017年5月(2)
- 2017年4月(2)
- 2017年3月(3)
- 2017年2月(2)
- 2017年1月(2)
- 2016年12月(3)
- 2016年11月(2)
- 2016年10月(3)
- 2016年9月(4)
- 2016年8月(2)
- 2016年7月(4)
- 2016年6月(3)
- 2016年5月(1)
- 2016年4月(4)
- 2016年3月(3)
- 2016年2月(1)
- 2016年1月(5)
- 2015年12月(4)
- 2015年11月(5)
- 2015年10月(1)
- 2015年9月(6)
- 2015年8月(4)
- 2015年7月(1)
- 2015年6月(6)
- 2015年5月(3)
- 2015年4月(3)
- 2015年3月(2)
- 2015年2月(1)
- 2015年1月(3)
- 2014年12月(1)
- 2014年11月(1)
- 2014年10月(1)
- 2014年9月(3)
- 2014年8月(1)
- 2014年7月(1)
- 2014年6月(1)
- 2014年5月(3)
- 2014年4月(1)
- 2014年3月(1)
- 2014年2月(2)
- 2014年1月(1)
- 2013年12月(2)
- 2013年11月(2)
- 2013年10月(1)
- 2013年9月(3)
- 2013年8月(14)
- 2013年7月(7)
- 2013年4月(1)
- 2013年3月(4)
- 2013年2月(6)
- 2013年1月(6)
- 2012年12月(8)
- 2012年11月(6)