后台管理系统模板网络营销郑州优化推广公司

前言

最近看到了一些tigase关于异步事件解耦的地方的设计，做一个笔记记录一下。什么是事件总线，我自己对于事件总线的理解是，事件总线是一个对事件（Event）进行集中处理的基于发布订阅模式的一种处理机制。个人拙见，认为tigase的事件总线设计设计的其实并不是特别的好，所以我特意对比了一下Google大佬设计Guava的事件总线设计。

tigase事件总线类结构设计

上面是是一个tigase事件总线设计的一个简化版的类图（其中还有一些工厂类没有画），总体的设计思路，tigase还是基于高度抽象设计的一个设计思路，核心是事件总线接口EventBus，接口中声明了添加监听、事件发布等方法用于对监听者的维护和事件发布等操作。EventBusFactory是EventBus的工厂类。EventBusImplementation是EventBus的实现，核心逻辑全在这个类中实现。其他一些类是tigase特有的一些业务逻辑相关的类。EventsRegistrar用于维护注册的事件，tigase中没有注册的事件有检查报错的逻辑。EventRoutedTransientFiller、EventRoutingSelector是对tigase事件过滤和监听者过滤的一个抽象，EventRoutedTransientFiller作用是过滤器事件消息（Event）、EventRoutingSelector是过滤监听者的一个过滤器。用户可以通过自定义类，对事件消息和监听者进行过滤。

guava事件总线类结构设计

上图是Guava时间总线的设计。主要的类是EventBus事件总线类，事件总线类由核心的register、unregister维护订阅者，post发布消息。EventBus分别依赖事件分派器Dispatcher和订阅者集合类SubscriberRegistry，订阅者集合类维护一个由事件类型为Key，订阅者集合的一个Map类。Subscriber就是订阅者类。设计上简洁，map基于事件类型，将订阅者分组，通过事件类型能快速筛选到事件的订阅者集合

tigase&&guava事件总线流程设计

tigase事件总线流程设计图

guava事件总线流程设计图

tigase和guava事件总线流程设计大致都基本相同，只是guava设计有一个个人觉得比较好的亮点，想必大家看图也能直观的看出，guava的设计多了一个SubscriberRegistry的抽象，很好的解耦了订阅者的设计，不再是全部代码耦合到EventBus或者EventBus的子类中。

关于tigase过滤器和选择器设计

private void fireEventLocally(final EventName name, final Element event) {Object obj = deserialize(event);if (obj == null) {obj = event;} else {boolean ready = true;Collection<EventRoutedTransientFiller> fillers = localEventBus.getEventRoutedTransientFillers(obj.getClass());//过滤器的处理逻辑if (fillers != null) {for (EventRoutedTransientFiller f : fillers) {ready &= f.fillEvent(obj);}}if (!ready) {return;}}localEventBus.fire(obj, this, true);}

以上是处理事件发布的消息逻辑，对于自定义选择器和过滤器的设计，我不清楚当初作为为何这样设计，也许是为了更好的扩展，但是我个人认为这样的设计其实有点过度设计的嫌疑（欢迎大家质疑和讨论，可以在评论下留下自己的高见），消息处理器的设计都是只关注特定的事件消息，在实现消息处理器的时候，都应该明白自己需要且想要处理什么类型的消息，不需要关注的消息类型直接不处理就行了，如果有特殊的业务处理的话，这样的特殊业务逻辑的处理个人觉得应该下沉到订阅者实际的handle方法中进行特殊的实现，这样设计的话就会简洁很多。

小结

通过学习两款优秀的事件总线设计，更好帮我理解事件总线订阅发布的设计思路，但是对比起来，我更喜欢guava的设计，在设计上比较简洁。