前面讲到要使自定义注解生效需要写一段驱动代码,居然监听那驱动代码什么开始执行比较合适呢?可样大家可能知道答案:应用启动的时候。
回到具体的居然监听代码实现中,假设应用程序(客户端或服务端)依赖了 RPC框架并且使用了Spring环境,可样对Spring比较熟悉的居然监听小伙伴应该知道,Spring在启动的可样过程中会初始化bean,那是居然监听不是可以在初始化bean之后去执行这段驱动代码呢?答案是肯定的。
查阅相关资料后,可样Spring 监听器可以实现上面这个诉求。居然监听
监听器在使用过程中可以监听某些感兴趣的可样事件,监听到事件来临时可以做出响应处理。居然监听
Spring事件监听体系包括三大核心组件:事件监听器、可样事件、居然监听事件广播器,可样如下图:

事件广播器或者叫事件多播器负责广播发生的居然监听事件并通知所有监听器,所有的事件监听器都会提前注册在事件广播器中。
事件所有的动作都可能被定义为一个事件,事件发生后事件广播器通知所有的监听器,监听器根据情况做出响应。
Spring 定义了一个事件基类:ApplicationEvent,看一下源码:
复制public abstract class ApplicationEvent extends EventObject { /** 事件发生的免费源码下载时间 */ private final long timestamp; /** * 创建一个实例 * @param source 事件来源 */ public ApplicationEvent(Object source){ super(source); this.timestamp = System.currentTimeMillis(); }……省略其他代码
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.ApplicationEvent 继承 JDK 定义的事件基类:EventObject,
复制public class EventObject implements java.io.Serializable { /** * The object on which the Event initially occurred. */ protected transient Object source;……省略其他代码
}1.2.3.4.5.6.7.ApplicationEvent 是一个抽象类,如果需要自定义事件需要继承这个类:
复制public class MyEvent extends ApplicationEvent {……省略其他代码
}1.2.3.当然 Spring 自身已经定义了非常多的事件:
ContextRefreshedEvent:ApplicationContext 被初始化或刷新时,该事件被发布。初始化是指所有的Bean被成功装载,后处理Bean被检测并激活,所有Singleton Bean 被预实例化,ApplicationContext容器已就绪可用。ContextStartedEvent:ApplicationContext 启动后,该事件被发布。ContextStoppedEvent:ApplicationContext 停止后,该事件被发布。ContextClosedEvent:ApplicationContext 关闭后,该事件被发布。以上仅仅列举了几个常用的 Spring 事件。
根据前面分析的业务诉求,我们期望所有的bean初始化完之后开始执行自定义注解的驱动代码,所以ContextRefreshedEvent这个事件才是我们感兴趣的,看一下源码:
复制public class ContextRefreshedEvent extends ApplicationContextEvent { public ContextRefreshedEvent(ApplicationContext source){ super(source); }}1.2.3.4.5.看起来非常简单,继承了ApplicationContextEvent,继续跟一下源码可以发现ApplicationContextEvent继承了我们上面讲的ApplicationEvent。高防服务器
事件监听器所有的事件监听器都注册在事件广播器中,这好比观察者模式中的观察者。
在 Spring 中ApplicationListener是事件监听器的顶层接口,继承自 JDK 的EventListener,所有的监听器都必须实现这个接口。
复制public interface ApplicationListener<E extends ApplicationEvent> extends EventListener { /** * 处理事件 * @param event 待响应的事件 */ void onApplicationEvent(E event); //……省略其他代码
}1.2.3.4.5.6.7.8.9.定义了一个onApplicationEvent方法,当有感兴趣的事件发生后就会执行这个方法进行处理。
上面介绍了 Spring 监听体系的一些基础知识,并通过一些源码进行辅助介绍,这些代码都不是 RPC 框架要写的,RPC 框架当前要做的是实现一个自定义监听器监听感兴趣的事件。
通过结合业务诉求分析出:自定义一个监听器用来监听 Spring 内置ContextRefreshedEvent事件。
复制public class DefaultRpcListener implements ApplicationListener<ContextRefreshedEvent> { public DefaultRpcListener(){ }@Override
public void onApplicationEvent(ContextRefreshedEvent event){ //TODO 实现业务逻辑
// 1服务端逻辑处理
// 2客户端逻辑处理
}}1.2.3.4.5.6.7.8.9.10.11.自定义的监听器实现了ApplicationListener接口,并重写onApplicationEvent方法,方法中待实现的业务逻辑是重中之重。
待实现的源码下载业务逻辑中需要对@ServiceExpose和@ServiceReference这两个注解进行处理,@ServiceExpose对应服务端,@ServiceReference对应客户端,所以基本就是两大块:服务端逻辑处理和客户端逻辑处理。
注意一下,文中提到的服务端或客户端是站在功能角度上看的,不能片面理解,一个应用程序(服务或微服务)既可能是服务端也可能是客户端:

Spring 监听器-第 2 页
如上图,微服务 A 调用微服务 B,微服务 B 又调用微服务 C,微服务 B 在整个调用链中既是客户端又是服务端。
自定义监听器DefaultRpcListener放在 listener 包下,目前 RPC 框架代码工程结构如下:
复制├── easy-rpc-spring-boot-starter
├── pom.xml├── src
│ └── main
│ ├── java
│ │ └── com
│ │ └── leixiaoshuai
│ │ └── easyrpc
│ │ ├── annotation
│ │ │ ├── ServiceExpose.java │ │ │ └── ServiceReference.java│ │ └── listener
│ │ └── DefaultRpcListener.java│ └── resources
└── target1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.本小节首先学习了Spring 监听的基本机制,了解到监听体系有三大关键要素:事件监听器、事件、事件广播器,事件监听器会提前注册到事件广播器中,当感兴趣的事件发生后事件广播器会通知到事件监听器,这样事件监听器就可以根据业务场景进行响应。
Spring 提供了事件的基类,大家可以自定义事件,当然也可以直接使用 Spring 内置的事件,结合 RPC 框架的业务特点我们发现ContextRefreshedEvent事件比较符合我们的诉求。
Spring 定义了事件监听器ApplicationListener顶层接口,我们只需要实现该接口就可以自定义一个监听器,在监听器中重写onApplicationEvent方法实现相应的业务逻辑。
自定义监听器主要的业务逻辑包括两大块:服务端和客户端,服务端逻辑主要处理@ServiceExpose注解,客户端逻辑主要处理@ServiceReferece注解。关于注解处理的逻辑我们下一小节详细讲解。
相关文章:
相关推荐: