Solr/SolrCloud 简述搜索请求过程

以前我主管经常跟我们说，SolrCloud可以当成一个很非常好的MVC框架来用，天生自带LoadBalance特征。所以，我们很多Http服务都被通过SolrCloud对外提供服务。

其实，这里讲不只是搜索请求过程，应该是Solr所有请求的基本流程都是如此。

开始之前，我们先来看看大家所熟悉的MVC框架–Struts的主要组件架构图。

即一个HttpServletRequest到了Http服务器之后，被FilterDispatcher拦截下来。通过对Request的解析之后，寻到对应的ActionProxy。如果Action配置了Interception则需要先经过所有Interception处理之后，才调用Action。最后拿到Action执行结果之后，把结果原路走一遍Interception。

接下来再看看Solr组件架构图，你会发现有很多相似之处。

都是接一个HttpServletRequest之后，对HttpServletRequest解析，重封装成一个内部的Request之后继续流程的流转。SolrDispatchFilter通过一定规则把Request分发到对应的SolrRequestHandler(Handler)完成逻辑处理，最终返回结果。然后SearchComponent就像Interception一样，完成对请求做预处理，对响应结果进行转换。

不同的是，Struts通过代理生成一个ActionProxy来调用Action的方法（太久没接触这一块，具体记不清楚了）。而Solr不是，Solr的Handler设计遵循单一职责原则。所有Handler都继承自 SolrRequestHandler，同时实现了 handleRequest 方法。所以，对于Solr来说，只需要直接操作SolrRequestHandler即可。当然 Class.newInstance 也是反射。我只是说在调过程不需要用到反射，用的是动态绑定技术。

其次，SearchComponent与Interception虽然也是十分相似，但它们执行路径是不一样，语义也不尽相同。

最后，我们对Solr对HttpRequest处理流程重新梳理一下。

（注：只有SearchHandler有SearchComponent；SearchComponent的活动远比这个复杂）
1. SolrDispatchFilter : 顾名思义，Solr调度器，把任务分到对应的处理器处理。在Solr/SolrCloud中充当十分重要的角色。今后，若我还继续写博客的话，一定会经常提及它的了。基本跟Struts的FilterDispatcher功能十分相似，完成框架的初化并启动，管理着框架的生命周期。同时还负责请求的分发。
2. SolrRequestHandler : 近似于Struts2中的Action吧。所有的SolrRequestHandler都注册在SolrCore上，分别负责更新，搜索和Collection管理等。
3. SearchComponent : 顾名思义，查询组件，因此只有查询的处理器中才有。近似于Struts2中的Interception。它三大功能，搜索请求预处理（比如，改写查询条件），搜索逻辑处理（QueryComponent,SuggestComponent等），搜索结果转换（后续有例案）。