Elasticsearch（ES）是一款基于Lucene的开源分布式搜索引擎。由于其稳定、可靠、快速、安装使用方便等优良特性，目前在业界已广泛使用。ES用途主要分两个方向：分布式实时文件存储 以及 分布式实时分析搜索引擎。
一、为什么需要查询代理
屏蔽复杂的DSL
某二手交易平台使用ES，主要用来支持商品、用户等(以下统称文档)的搜索和分析。
ES为查询功能提供了基于Json的完整Query DSL，功能非常强大，但同时也略显复杂，学习成本不低。
以搜索昵称为化仁的用户为例，DSL大致如下：
json {"from" : 0, "size" : 20, "query" : {"bool" : { "must" : { "multi_match" : {"query" : "化仁", "fields": [ "nickname", "nickname.pinyin" ], "type" :"best_fields", "operator" : "OR","minimum_should_match" : "1", "tie_breaker" : 1.0} }, "filter" : { "term" : { "del" : 0 } } } } }
如果让每个业务方根据需要编写DSL实现相应功能，工作量及维护复杂程度可想而知！
避免依赖限制扩散
· ES要求客户端和服务端JDK版本尽量保持一致
· ES2.x要求JDK7以上
· ES5.x要求JDK8以上
· 大量Jar包依赖
· 其它可能出现的限制
使用查询代理之后，各业务方无需引入上述依赖和限制
松耦合及管控
屏蔽底层引擎变动对线上业务的影响，例如底层引擎偶尔需要升级或重启，此时，只需查询代理层实现主从切换等机制，引擎的升级可做到对线上业务完全透明。
此外，查询代理还可以屏蔽业务方错误的危险操作，防止集群直接暴露给各业务方，从而降低不确定因素对系统的影响。
二、查询代理层实现
业界做法
业界有将SQL作为代理层语言，实现一套SQL转DSL的解析器，这种方式针对将ES作为DB使用的情况非常合适。但是，前面提到过，某二手交易平台的使用场景是文档的搜索，其中涉及到文档的复杂排序，SQL无法完整实现目标需求，而且文档属性非常多的情况下，容易产生语句过于复杂的问题。
方案
种种因果，我们最终的实现方案如下：
请求语法
· 语句分为query域和param域，query域为筛选召回条件，param域为排序参数；
· 域为属性字段的组合；
· 域使用URL参数语法表述；
还以搜索昵称为化仁的用户为例，请求如下：
query:from=1&size=10&nickname=化仁 param: null 请求会自动转换成前面提到的DSL例子。可以看到，相比之下还是非常简单的。
实现逻辑
补充说明：
· 根据解析方式，字段大致分为：内置字段 (起始位置、获取数量、排序策略等) 和 配置字段 (字符串、数值、日期、经纬度等，会解析成对应ES支持的索引字段类型)
· 配置字段根据使用场景分为：匹配筛选型、排序参数型、字段排序型、排序打分型、二次打分型等
· 各种类型的配置字段配有配置解析器和请求处理器
· 处理过程中会做诸如字段默认值、非法字段过滤等处理
· 处理过程生成query的梗概信息作为外部缓存的key值，减轻ES集群压力
· 请求经过校验、解析、处理后拼装成ES的DSL，请求发送到系统分配ES集群
配置样例：
yml entry.user:index: user type: user query_fields: - { face: id, type: Number, class: Long }- { face: nickname, type: StringMultiMatch, fieldName:"nickname,nickname.pinyin", _tie_breaker: 1 } order_strategys:default: boostMode: multiply scores: - type: NumberTermsFilter fieldName: label_idclass: Long values: "1141730738345" weight: 2
三、总结
本文从ES查询接口的必要性出发，主要讲述了某二手交易平台ES查询接口的语法设计和实现逻辑及简要说明。其中有不合理之处，欢迎指正交流。
