Zuul源码解读

最近这段时间在使用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源码