- 在使用soul将我们编写的controller接口注册到网关,由网关统一代理时,一般情况,http方式,我们只需要使用@SoulSpringMvcClient注解标注在对应的接口上就行了,那么,我们使用了注解之后,soul是如何将我们的接口注册到网关的呢
先看看注解在哪些地方被使用了
我们进到这个类里面,使用了spring的bean实例化里面的后置处理器机制进行了具体处理。
1 | @Slf4j |
- 看看具体RegisterUtils.doRegister()方法
1 | public static void doRegister(final String json, final String url, final RpcTypeEnum rpcTypeEnum) { |
- doRegister唯一作用就是发起一个向soul-admin对应接口的http调用,那我们看看soul-admin
- 也是一个很常规的controller接口,成功调用到了
- 里面有两个方法handlerSpringMvcSelector和handlerSpringMvcRule, 我们看看这两个方法具体干了什么
- selector:
1 | private String handlerSpringMvcSelector(final SpringMvcRegisterDTO dto) { |
- rule:
1 | public String register(final RuleDTO ruleDTO) { |
- 只是简单的入库保存配置,然后通过监听,发布更改事件,那就要看看发布的监听具体内容了。
1 | @Component |
- 匹配到对应的类型时,走了具体的监听事件,以selector的为例子,listener.onSelectorChanged,因为soul的数据同步,默认使用的时http长轮询来进行的,最终定位到了AbstractDataChangedListener.onSelectorChanged方法
1 | @Override |
- 这个afterSelectorChanged的方法默认是个空的实现,往下看具体实现,发现只有一个,就是HttpLongPollingDataChangedListener,实际执行长轮询同步数据的类(模版模式的再一次应用)。
1 | protected void afterSelectorChanged(final List<SelectorData> changed, final DataEventTypeEnum eventType) { |
- 看看这个实现了Runnable的DataChangeTask中的run方法干了什么,结合官方文档解释,长轮询策略下,soul-web请求admin,admin会将数据同步请求放入阻塞队列中延迟处理,如果60秒没有配置更新请求,会触发一次将队列头部元素出队进行处理,然后返回响应,如果有配置修改请求发生,会将队列中的所有请求出队依次处理响应给soul-web。
1 | @Override |
- 同样的,LongPollingClient也是个实现runnable的方法
1 | @Override |
- 因为我们在使用@SoulSpringMvcClient注册我们的接口的时候,项目启动不需要进行同步操作,所以这里复用了响应方法,响应在一开始说的doRegister方法发出的请求。至此,项目启动时利用@SoulSpringMvcClient向网关注册接口的流程就走完了。