最近这段时间在使用Zuul,顺便简单阅读了一下源码。本文旨在对自己阅读到的源码做一点小结,以后日后回顾。不追求面面俱到,细致入微,看到哪里写到哪里吧
关于Zuul的介绍及基本使用就不在此赘述了,网上有很多这方面的文章
入口:
系统启动时处理@EnableZuulProxy,重点是其中的ZuulProxyConfiguration.class
底层http库:
ZuulProxyConfiguration.class又额外引入下面3个class,说明zuul支持以下3种方式作为底层http库
1. RestClientRibbonConfiguration.class,底层是Jersey client,具体没研究,并且已经标记为过时
2. OkHttpRibbonConfiguration.class,底层是OkHttp,安卓上用的较多,服务端使用情况未知
3. HttpClientRibbonConfiguration.class,底层是HttpClient,都比较熟了不多说
那么具体使用哪一种方式?我们以HttpClient举例,看下图源码,通过ribbon.httpclient.enabled激活,并且matchIfMissing=true,说明不配置的时候作为默认激活项;其他两种方式配置也是类似,但是不作为默认激活
从源码看,没有RestTemplate方式,细想一下确实也没必要,因为RestTemplate也只是一种门面,以统一的方式调用底层http库,优点就是对于使用者API更简单和统一,既然不需要直接调用,也就不需要RestTemplate了
RouteLocator:
我们继续来看ZuulProxyConfiguration.class,发现个DiscoveryClientRouteLocator.class
RouteLocator作用是什么?很可惜在RouteLocator.class源码中并没有一个整体的说明,不过从其中定义的3个方法中可以看出些端倪,其实就是维护路由信息
知道了大致的地位,我们再来看一下RouteLocator这个家族的势力
1. RouteLocator是其鼻祖,其中定义了三个与路由相关的基本方法:获取忽略的path集合、获取路由列表、根据path获取路由信息
2. SimpleRouteLocator实现了RouteLocator及Ordered,看其描述,主要负责维护配置文件中的路由配置,配置文件中的路由配置会被转化后存储在一个map中,其中key为配置的path
3. RefreshableRouteLocator继承自RouteLocator,额外提供了对于路由刷新方面的定义,refresh方法会结合spring的ApplicationEvent,实现基于事件的路由刷新机制,具体可以参看ZuulDiscoveryRefreshListener源码