1、背景

  最近,一个工作了一个月的同事离职了,所做的东西怼了过来。一看代码,惨不忍睹,一个方法六七百行,啥也不说了吧,实在没法儿说。介绍下业务场景吧,一个公共操作A,业务中各个地方都会做A操作,正常人正常思维应该是把A操作提取出来封装,其他地方调用,可这哥们儿偏偏不这么干,代码到处复制。仔细分析了整个业务之后,发现是一个典型的事件/消息驱动型,或者叫发布/订阅型的业务逻辑。鉴于系统是单体的,所以想到利用进程内发布/订阅的解决方案。记得很久之前,做WPF时候,用过Prism的EventAggregator(是不是暴露年龄了。。。),那玩意儿不知道现在还在不在,支不支持core,目前流行的是MediatR,跟core的集成也好,于是决定采用MediatR。

2.Demo代码

Startup服务注册:

 public void ConfigureServices(IServiceCollection services)
{
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
services.AddScoped<IService1, Service1>();
services.AddScoped<IService2, Service2>();
services.AddScoped<IContext, Context>();
services.AddMediatR(typeof(SomeEventHandler).Assembly);
}

 服务1:

public class Service1 : IService1
{
private readonly ILogger _logger;
private readonly IMediator _mediator;
private readonly IContext _context;
private readonly IService2 _service2; public Service1(ILogger<Service1> logger,
IMediator mediator,
IContext context)
{
_logger = logger;
_mediator = mediator;
_context = context;
//_service2 = service2;
} public async Task Method()
{
_context.CurrentUser = "test";
//await _service2.Method();
//_service2.Method();
await _mediator.Publish(new SomeEvent());
//_mediator.Publish(new SomeEvent()); await Task.CompletedTask;
}
}

  可以看到,在服务1的method方法中,发布了SomeEvent事件消息。

服务2代码:

public class Service2 : IService2
{
private readonly ILogger _logger;
private readonly IContext _context; public Service2(ILogger<Service2> logger,
IContext context)
{
_logger = logger;
_context = context;
} public async Task Method()
{
_logger.LogDebug("当前用户:{0}", _context.CurrentUser);
await Task.Delay();
//_logger.LogDebug("当前用户:{0}", _context.CurrentUser);
_logger.LogDebug("Service2 Method at :{0}", DateTime.Now);
}
}

解释下,为啥服务2 Method方法中,要等待5秒,因为实际项目中,有这么一个操作,把一个压缩程序包传递到远端,然后在远端代码操作IIS创建站点,这玩意儿非常耗时,大概要1分多钟,这里我用5s模拟,意思意思。这个5s至关重要,待会儿会详述。

再看事件订阅Handler:

public class SomeEventHandler : INotificationHandler<SomeEvent>, IDisposable
{
private readonly ILogger _logger;
private readonly IServiceProvider _serviceProvider;
private readonly IService2 _service2; public SomeEventHandler(ILogger<SomeEventHandler> logger,
IServiceProvider serviceProvider,
IService2 service2)
{
_logger = logger;
_serviceProvider = serviceProvider;
_service2 = service2;
} public void Dispose()
{
_logger.LogDebug("Handler disposed at :{0}", DateTime.Now);
} public async Task Handle(SomeEvent notification, CancellationToken cancellationToken)
{
await _service2.Method();
//using (var scope = _serviceProvider.CreateScope())
//{
// var service2 = scope.ServiceProvider.GetService<IService2>();
// await service2.Method();
//}
}
}

然后,我们的入口Action:

[HttpGet("test")]
public async Task<ActionResult<string>> Test()
{
StringBuilder sb = new StringBuilder();
sb.AppendFormat("开始时间:{0}", DateTime.Now);
sb.AppendLine();
await _service1.Method();
sb.AppendFormat("结束时间:{0}", DateTime.Now);
sb.AppendLine(); return sb.ToString();
}

至此,Demo要干的事情,脉络应该很清晰了:控制器接收HTTP请求,然后调用Service1的Method,service1的Method又发布消息,消息处理器接收到消息,调用Service2的Method完成后续操作。我们运行起来看下:

  

http请求开始到结束,耗时5s,看似没问题。我们看系统输出日志:

Service2的Method方法也确实被订阅执行了。

3.问题

  上述一切的一切,看似没问题。运行成功没?成功了。对不对?好像也对。有没问题?大大的问题!HTTP从开始到结束,要耗时5s,实际项目中,那是一分钟,这整整一分钟,你要前端挂起等待么一直?理论上,这种耗时的后端操作,合理做法是HTTP迅速响应前端,并返给前端业务ID,前端根据此业务ID长轮询后端查询操作结果状态,直至此操作完成,决不能一直卡死的,否则交互效果不说,超过一定时间,HTTP请求会直接超时的!这就必须动刀子了,将Service2操作后台任务化且不等待。Service1的Method代码调整如下:

public async Task Method()
{
_context.CurrentUser = "test";
//await _service2.Method();
//_service2.Method();
//await _mediator.Publish(new SomeEvent());
_mediator.Publish(new SomeEvent()); await Task.CompletedTask;
}

见注释前后,改进地方只有一处,发布事件代码去掉了await,这样系统发布事件之后,便不会等待Service2而是继续运行并立刻响应HTTP请求。好,我们再来运行看下效果:

我们看到,系统立即响应了HTTP请求(22:40:15),5s之后,Service2才执行完成(22:40:20)。看似又没问题了。那是不是真的没问题呢?我们注意,Service1和Service2中,都注入了一个Context上下文对象,这个对象是我用来模拟一些Scope类型对象,例如DBContext的,代码如下:

public class Context : IContext, IDisposable
{
private bool _isDisposed = false; private string _currentUser;
public string CurrentUser
{
get
{
if (_isDisposed)
{
throw new Exception("Context disposed");
} return _currentUser;
}
set
{
if (_isDisposed)
{
throw new Exception("Context disposed");
} _currentUser = value;
}
} public void Dispose()
{
_isDisposed = true;
}
}

里边就一个属性,当前上下文用户,并实现了Dispose模式,并且当前上下文被释放时,对该上下文对象任何操作将引发异常。从上文的Service1及Service2截图中,我们看到了,两个服务均注入了这个context对象,Service1设置,Service2中获取。现在我们将Service2的Method方法稍作调整,如下:

public async Task Method()
{
//_logger.LogDebug("当前用户:{0}", _context.CurrentUser);
await Task.Delay();
_logger.LogDebug("当前用户:{0}", _context.CurrentUser);
_logger.LogDebug("Service2 Method at :{0}", DateTime.Now);
}

  调整只有一处,就是获取当前上下文用户的操作,从5s延时之前,放到了5s延时之后。我们再来看看效果:

http请求上看,貌似没问题,立即响应了,是吧。我们再看看程序日志输出:

WFT!Service2 Method没成功执行,给了我一个异常。我们看看这个异常:

Context dispose异常,就是说上下文这时候已经被释放掉,对它任何操作都无效并引发异常。很容易想到,这里就是为了模拟DBContext这种通常为Scope类型的对象生命周期,这种吊毛它就这样。为啥会释放?因为HTTP请求结束那会儿,core运行时就会Dispose相应scope类型对象(注意,释放,不一定是销毁,具体销毁时间不确定)。那么,怎么解决?如果对基于DI生命周期比较熟悉,就会知道,这儿应该基于HTTP 的Scope之外,单独起一个Scope了,两个scope互补影响,HTTP对应的scope结束,另外的照常运行。我们将Handler处调整如下:

public async Task Handle(SomeEvent notification, CancellationToken cancellationToken)
{
//await _service2.Method();
using (var scope = _serviceProvider.CreateScope())
{
var service2 = scope.ServiceProvider.GetService<IService2>();
await service2.Method();
}
}

  无非就是Handle中单独起了一个Scope。我们再看运行效果:

OK,HTTP请求23:02:58响应,Service2 Method 23:03:03执行完成。至此,问题才算得到解决。

顺便提一下,大家注意看截图,当前用户null,因为scope之后,原来的设置过CurrentUser的context已经释放掉了,新开的scope中注入的context是另外的,所以没任何信息。这里你可能会问了,那我确实需要传递上下文怎么办?答案是,订阅事件,本文中SomeEvent未定义任何信息,如果你需要传递,做对应调整即可,比较简单,也不是重点,不做赘述。

4、总结

  感觉,没什么好总结的。扎实,细心,实践,没什么解决不了的。

Asp.net core使用MediatR进程内发布/订阅的更多相关文章

  1. [06]ASP.NET Core中的进程内(InProcess)托管

    ASP.NET Core 进程内(InProcess)托管 本文作者:梁桐铭- 微软最有价值专家(Microsoft MVP) 文章会随着版本进行更新,关注我获取最新版本 本文出自<从零开始学 ...

  2. Asp.Net Core 使用 MediatR

    Asp.Net Core 使用 MediatR 项目中使用了CQRS读写分离,增删改 的地方使用了 MediatR ,将进程内消息的发送和处理进行解耦.于是便有了这篇文章,整理并记录一下自己的学习.遇 ...

  3. 翻译 Asp.Net Core 2.2.0-preview1已经发布

    Asp.Net Core 2.2.0-preview1已经发布 原文地址 ASP.NET Core 2.2.0-preview1 now available 今天我们很高兴地宣布,现在可以试用ASP. ...

  4. [翻译] ASP.NET Core 2.2 正式版发布

    本文为翻译,原文地址:https://blogs.msdn.microsoft.com/webdev/2018/12/04/asp-net-core-2-2-available-today/ 我(文章 ...

  5. ASP.NET Core部署系列一:发布到IIS上

    前言: 当构建一个ASP.NET Core应用程序并且计划将其运行在IIS中时,你会发现Core应用程序和之前版本的ASP.NET程序在IIS中的运行方式是完全不一样的.与ASP.NET时代不同,AS ...

  6. ASP.NET Core部署系列二:发布到CentOS上

    前言: 在上一节中,通过一系列的步骤,已经将项目部署到IIS上,虽然遇到了一些问题,但最终解决并成功运行了.而在这一节中,将尝试通过linux系统的环境下,部署项目,实现Net Core跨平台的亮点. ...

  7. 构建基于asp.net core 的docker应用并发布

    发布Docker镜像的方法有很多种,asp.net core的发布需要在windows系统中 开门见山,首先保证已经在Centos上安装好了Docker.创建一个asp.net core的webapi ...

  8. Linux+Nginx+Asp.net Core及守护进程部署

    上篇<Docker基础入门及示例>文章介绍了Docker部署,以及相关.net core 的打包示例.这篇文章我将以oss.offical.site站点为例,主要介绍下在linux机器下完 ...

  9. ASP.NET Core 1.0 安装并发布到Centos 7.2 使用jexus 5.8.2

    安装运行环境 sudoyuminstall libunwind libicu 下载.net core https://www.microsoft.com/net/download 下载完后上传文件 安 ...

随机推荐

  1. sysUpload.vue上传组件 的时候 看进度的时候 不要mock 注释掉 // if (process.env.NODE_ENV !== 'production') require('@/mock')

    上传组件 的时候 看进度的时候 不要mock 注释掉 // if (process.env.NODE_ENV !== 'production') require('@/mock') <!-- * ...

  2. JavaSE-29 Java8的Lambda表达式

    概念说明 Lambda表达式是Java8提供的新特性,支持将代码块作为方法的参数. Lambda表达式支持使用简洁的代码创建只有一个方法的接口(函数式接口). 只包含一个方法的接口也称为函数式接口. ...

  3. 第4节 hive调优:2、数据倾斜

    数据的倾斜: 主要就是合理的控制我们的map个数以及reduce个数 第一个问题:maptask的个数怎么定的???与我们文件的block块相关,默认一个block块就是对应一个maptask 第二个 ...

  4. vue在传值的时候经常遇到的问题

    在我用vue编写程序的时候,在传值的时候,经常会遇到些问题,像今天遇到了两个问题,在用父传子的方法去传值,当父组件中的要传的数据是for循环出来的或者是列表的时候,你想每次运行的事件,都去传某一行,或 ...

  5. 【简●解】[AHOI2009]中国象棋

    [题目大意] 叫你在\(n×m\)的棋盘上放若干个炮(可以是0个),使得没有一个炮可以攻击到另一个炮,问有多少种放置方法. [关键词] \(DP\) 分类讨论 乘法和加法原理 [分析] 仔细观察就会发 ...

  6. 「 Luogu P2420 」 让我们异或吧

    # 解题思路 两点之间的路径的话一定经过它们两个 LCA,这一点已经是显而易见的,那么再来看看异或的性质. $$a\ xor\ b\ xor\ b = a\\ a\ xor\ a=0\\ a\ xor ...

  7. vue 源码自问自答-响应式原理

    vue 源码自问自答-响应式原理 最近看了 Vue 源码和源码分析类的文章,感觉明白了很多,但是仔细想想却说不出个所以然. 所以打算把自己掌握的知识,试着组织成自己的语言表达出来 不打算平铺直叙的写清 ...

  8. redis异常信息:MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk.。。。。

    redis.exceptions.ResponseError: MISCONF Redis is configured to save RDB snapshots, but it is current ...

  9. Kubernetes集群中修复状态为NotReady的节点

    度个假回来发现自己集群中的节点都挂了,全部是NotReady状态 但是除了.10节点外,其他主机并没有挂,可以远程连接上, 那就考虑是kubernetes系统的问题 解决的方法是重启kube-prox ...

  10. BGP表

    BGP是一种基于策略的路由选择协议,让AS能够根据多种BGP属性来控制数据流的传输.运行BGP的路由器交换被称为路径矢量或者属性的NLRI.路径矢量信息中包含一个BGP-AS号列表称为AS-PATH属 ...