以前我主管經常跟我們說，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等），搜索結果轉換（後續有例案）。