asp.net web开发 ASP.NET Core Web API下事件驱动型架构的实(6)

从上面的日志内容可以看到，在Web API的整个运行期间，CustomerCreatedEventHandler仅被构造了一次，而且在每次处理CustomerCreatedEvent事件的时候，都是使用同一个DapperEventStore实例来保存事件数据。也就是说，CustomerCreatedEventHandler和DapperEventStore在整个Web API服务的生命周期中，有且仅有一个实例，它们是Singleton的！然而，在进行系统架构的时候，我们应该尽量保证较短的对象生命周期，以免因为状态的不一致性导致不可回滚的错误出现，这也是架构设计中的一种最佳实践。虽然目前我们的DapperEventStore在程序正常退出的时候能够被Dispose掉，但如果DapperEventStore使用了非托管资源，并且非托管资源并没有很好地管理自己的内存呢？久而久之，DapperEventStore就产生了内存泄漏点，慢慢地，Web API就会出现内存泄漏，系统资源将被耗尽。假如Web API被部署在云中，应用程序监控装置（比如AWS的Cloud Watch）就会持续报警，并强制服务断线，整个系统的可用性就无法得到保障。所以，我们更期望DapperEventStore能够正确地实现C#的Dispose模式，在Dispose方法中合理地释放资源，并且仅在需要使用DapperEventStore时候才去构建它，用完就及时Dispose，以保证资源的合理使用。这也就是为什么我们使用services.AddTransient方法来注册CustomerCreatedEventHandler以及DapperEventStore的原因。

然而，事实却并非如此。究其原因，就是因为PassThroughEventBus是单例实例，它的生命周期是整个Web API服务。而在PassThroughEventBus的构造函数中，CustomerCreatedEventHandler被作为参数传入，于是，PassThroughEventBus产生了对CustomerCreatedEventHandler的依赖，而连带地也产生了对DapperEventStore的依赖。换句话说，在整个应用程序运行的过程中，IoC框架完全没有理由再去创建新的CustomerCreatedEventHandler以及DapperEventStore的实例，因为事件处理器作为强引用被注册到PassThroughEventBus中，而PassThroughEventBus至始至终没有变过！

Note：为什么PassThroughEventBus可以作为单例注册到IoC容器中？因为它提供了无状态的全局性的基础结构层服务：事件总线。在PassThroughEventBus的实现中，这种全局性体现得不明显，我们当然可以每一次HTTP请求都创建一个新的PassThroughEventBus来转发事件消息并作处理。然而，在今后我们要实现的基于RabbitMQ的事件总线中，如果我们还是每次HTTP请求都创建一个新的消息队列，不仅性能得不到保证，而且消息并不能路由到新创建的channel上。注意：我们将其注册成单例，一个很重要的依据是由于它是无状态的，但即使如此，我们也要注意在应用程序退出的时候，合理Dispose掉它所占用的资源。当然，在这里，ASP.NET Core的IoC机制会帮我们解决这个问题（因为我注册了PassThroughEventBus，但我没有显式调用Dispose方法，我仍然能从日志中看到“PassThroughEventBus已经被Dispose”的字样），然而有些情况下，ASP.NET Core不会帮我们做这些，就需要我们自己手工完成。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-60185-6.html