现象:
系统部署在iis,是一款小程序,当操作小程序的时候,突然就出现加载很久的问题,后来发现是接口卡了。
排查过程:
刚开始第一反应是网络问题,最近又刚好遇上华为云(挂在华为云)不稳定,所以一段时间认为是华为云的问题
接着发现很有规律,就操作那几个接口的时候出问题,而那几个接口的共性是使用了 DotNetCore.CAP,考虑是否是该组件不支持net6
遂换为MassTransit,但是问题依旧
接着定位到MassTransit实际执行的过程中,一个是发送短信,一个是发送公众号模板消息
逐个去除测试,最终确认为发送了公众号模板消息,每次发送都会出现卡住问题(系统表现为出现windows问题反馈的进程,以及在系统事件中出现restart 程序的问题)
使用的是Senparc.Weixin,按理说不应该,这个已经使用了好多年,看源代码,也没什么会出现死循环的,但是这个问题有人提出,官方只是说不是他们触发的
怀疑是windows server 2019 系统的问题
网上搜索也确实有很多相关的,有更新系统的,有安装缺失vc++的,但是问题没解决
只能换了操作系统,使用linux
当部署好之后,运行,问题依旧
查看执行日志(iis中不好查看),发现在处理微信事件的时候,出现了死循环
问题解决
总结
要非常注意Senparc.Weixin的默认消息处理DefaultResponseMessage,它父类方法是abstract的,当你不想输出任何东西的时候,按正常逻辑,很容易就写成如下,编译没问题,实际是个死循环:
public override IResponseMessageBase DefaultResponseMessage(IRequestMessageBase requestMessage)
{
/* 所有没有被处理的消息会默认返回这里的结果,
* 因此,如果想把整个微信请求委托出去(例如需要使用分布式或从其他服务器获取请求),
* 只需要在这里统一发出委托请求,如:
* var responseMessage = MessageAgent.RequestResponseMessage(agentUrl, agentToken, RequestDocument.ToString());
* return responseMessage;
*/
DefaultResponseMessage(requestMessage);
}
实际应该如下
public override IResponseMessageBase DefaultResponseMessage(IRequestMessageBase requestMessage)
{
/* 所有没有被处理的消息会默认返回这里的结果,
* 因此,如果想把整个微信请求委托出去(例如需要使用分布式或从其他服务器获取请求),
* 只需要在这里统一发出委托请求,如:
* var responseMessage = MessageAgent.RequestResponseMessage(agentUrl, agentToken, RequestDocument.ToString());
* return responseMessage;
*/
return new SuccessResponseMessage();
}