2.Demo代码

Startup服务注册：

public void ConfigureServices(IServiceCollection services)
  {
   services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
   services.AddScoped();
   services.AddScoped();
   services.AddScoped();
   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 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 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, IDisposable
  {
    private readonly ILogger _logger;
    private readonly IServiceProvider _serviceProvider;
    private readonly IService2 _service2;

    public SomeEventHandler(ILogger 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();
      //  await service2.Method();
      //}
    }
  }

然后，我们的入口Action：

[HttpGet("test")]
    public async Task> 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();
        await service2.Method();
      }
    }

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