这两周做的事情比较杂，所以看代码的点也稍微有点分散，不过我尽量用手头的例子来把这些东西串起来。
做的事情还是上两周那件事：我想拦截ES的Request 和Response，统计我自己想要的指标并保存，那么需要完成以下3件事情：
- 怎么拦截
- 除了Request 和Response 外如何获取container 里的其他Service
- 如何去跑我自己的拦截代码的逻辑
怎么拦截
其实这个话题我在上一篇（Elasticsearch 5.x 源码分析（8）用plugin来拦截Request、Response 的可行性调研）已经详细介绍了，大家有兴趣可以往回翻一下看看就好了，只是这种办法最大的缺点就是不是很美观，埋的点也很多，甚至有时可能需要入侵ES的源代码，这几天捣鼓的是另外一个方法：AspectJ 拦截。
根据上一篇的思路，RestSearchTemplateAction 调用的是
channel -> client.execute(SearchTemplateAction.INSTANCE, searchTemplateRequest, new ActionListener<SearchTemplateResponse>()
而RestSearchAction调用的是
channel -> client.search(searchRequest, new ActionListener<SearchResponse>()
RestIndexAction调用的是
client.index(indexRequest, new ActionListener<IndexResponse>()
剩下RestBulkAction调用的是
channel -> client.bulk(bulkRequest, new ActionListener<BulkResponse>()
上面说到的最终会调用
public final <Request extends ActionRequest, Response extends ActionResponse, RequestBuilder extends ActionRequestBuilder<Request, Response, RequestBuilder>> void execute(
Action<Request, Response, RequestBuilder> action, Request request, ActionListener<Response> listener)
因此AspectJ的话只需要拦截这个方法即可
大致拦截语句如下
/**
* 拦截所有RestSearchAction , RestSearchTemplateAction , IndexAction 和 BulkAction 的请求
* @param pjp
* @throws Throwable
*/
@Around("execution(* org.elasticsearch.client.support.AbstractClient.execute(org.elasticsearch.action.Action, org.elasticsearch.action.ActionRequest, org.elasticsearch.action.ActionListener))")
public void doTrace(final ProceedingJoinPoint pjp) throws Throwable {
Object[] args = pjp.getArgs();
if(isWorking && args != null && args.length == 3) {
handleArg(args);
}
pjp.proceed(args);
}
如何获得ES的IoC 注入Service 类
好了，加了拦截点那么其实你可以为所欲为了，可是，当我仅仅只想拿到当前Elasticsearch 实例的clusterName的时候，却遇到麻烦了。
大家都知道ES为了效率和轻便，是用的是Google的 Guice 来实现依赖注入，可是Guice 的bind 同时需要一个Injector 实例才能完成getInstance，也就是说如果我需要拿到ES 的clusterService.getClusterName()方法，那么我首先要先想办法拿到clusterService所bind 的那个Injector 才行。
那首当其冲先看Node.java,其中注册Service的代码块在构造方法处
并且Node开放了一个API出来
OK ,那去找Node实例，往上找到Bootstrap.java 代码
这里持有了一个node实例，那就拿Bootstrap 实例好了，可惜不开放，此路不通！
接着换一种思路，找传进来的配置Settings不就可以了
那继续往上找，找到environment 的初始化
再去找Settings类，希望它内存保留一份副本，结果没卵用，好吧，ES的安全措施做的还是不错的，这种配置的东西基本不让外面调用或拦截有入侵的机会。那就是说如果我想拦截代码，想拿到ES的Service基本是不可能的。
如何去跑我的那段拦截代码
如果就一两行代码的话那就完全没必要这么复杂了，但是我拦截的逻辑比较重，依赖的包都十几个，这就有点尴尬了，最好的机制还是自己弄个classLoader 去加载我自己的依赖，这样的话也不至于和ES本身的代码会有冲突（logger 的API都好几个...)。
这里先抛个银子，话说上面那个问题，有些人也会想到说：其实你自己随便弄个plugin，然后把ES注入给我的Service我全部暴露出来不就行了？ 因此它偏偏就不行，原因就是，ES的plugin 和Modules 加载都是采用独自的classLoader实现的。
因此这里我遇到了新的问题：
- 我的拦截逻辑要么用ES 的classLoader 来加载，要么用我自己的classLoader加载，但是无论如何我都无法读取到plugin 里面的类
- 像RestSearchTemplateAction，SearchTemplateRequest，SearchTemplateResponse这些类都是打在 lang-mustashe.jar 里面的，是属于module plugin 存在，因此无论我是哪种classLoader加载，我都是无法拦截并强转成这些对象来做文章。
那么我想到的办法只能是反射了，比如这样
至于说是否需要用到自己的classLoader ，那就视乎你自己的逻辑复杂程度，像我的话就是把所有的逻辑都封装出去，然后用独自的classLoader来加载，避免重读，自己搞classLoader的话就切记注意一点，千万要catch所有的throwable，避免JVM 挂了。
