Asp.net core使用MediatR进程内发布/订阅

一、背景

　　最近，一个工做了一个月的同事离职了，所作的东西怼了过来。一看代码，惨不忍睹，一个方法六七百行，啥也不说了吧，实在无法儿说。介绍下业务场景吧，一个公共操做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(5000);
            //_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(5000);
            _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未定义任何信息，若是你须要传递，作对应调整便可，比较简单，也不是重点，不作赘述。

 

四、总结

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