Elasticsearch内部探秘

Neil Zhu,ID Not_GOD,University AI 创始人 & Chief Scientist,致力于推进世界人工智能化进程。制定并实施 UAI 中长期增长战略和目标,带领团队快速成长为人工智能领域最专业的力量。
作为行业领导者,他和UAI一起在2014年创建了TASA(中国最早的人工智能社团), DL Center(深度学习知识中心全球价值网络),AI growth(行业智库培训)等,为中国的人工智能人才建设输送了大量的血液和养分。此外,他还参与或者举办过各类国际性的人工智能峰会和活动,产生了巨大的影响力,书写了60万字的人工智能精品技术内容,生产翻译了全球第一本深度学习入门书《神经网络与深度学习》,生产的内容被大量的专业垂直公众号和媒体转载与连载。曾经受邀为国内顶尖大学制定人工智能学习规划和教授人工智能前沿课程,均受学生和老师好评。

Elasticsearch内部探秘

by Njal Karevoll

什么是module?

ES中的module是一个Guice Module部件完成配置信息和绑定ES各类接口的特定实现。

Guice: lightweight dependency injection framework for Java 5 and above, brought to you by Google.

不含任何插件的标准的ES服务器拥有超过112个模块:(原文100,最新数据112个模块)

➜  elasticsearch git:(master) find src/main -name \*Module\* | grep -v common | wc -l
     112

ES在启动时,基于其配置文件和运行时环境来搜集不同模块,并创建一个称为Injector的东西。简单说,Injector就是一个不需要提供构建参数可以构建类的实例的对象。Injector将会使用它的配置完的模块来定位所有请求的依赖,并以一种拓扑顺序来为我们创建出这些实例。这样的做法为我们节约了大量时间,并帮助我们创建出来一个可复合的模块系统。这样的系统ES所需的规模需要可控。

用更加专业的术语,这就是一个依赖注入(dependency injection),用James Shore的话说就是:

Dependency injection means giving an object its instance variables

本文后面将解释为何ES如此易插件化和可扩展。我们首先看看ES的HTTP部分来弄清Guice和依赖注入是如何运作的。

HTTP服务模块

ES抽象为一个HttpServer类,在构建期间获得一个HttpServerTransport,这默认绑定在一个称为NettyHttpServerTransport的具体实现上。换句话说,HttpServer不清楚请求或者响应是如何接受和发送的,它只需要处理应用逻辑(application logic)(i.e. 帮助到来的请求找到一个合适的请求处理者)。

如果,由于某些原因(如性能,安全,特性等),ES打算切换HTTP层(layer),如同对换出一个配置值那样简单(http.type)。因此,Sonian基于Jetty发布了一个ES的HTTP层,这个东西刚好解决这个问题。可以在这里下载。基于Jetty的实现支撑了诸如验证这样的特性,这在一些应用场景种肯定有相应的需求。

命名空间

下图展示了ES的模块和命名空间:


Elasticsearch内部探秘_第1张图片
elasticsearch_internal.png

多个模块基于他们在源代码树或者代码中的调用情况被放进了不同的命名空间中。ES不同的侧面,诸如REST接口,插件,River和传输服务是分割的实体,他们之间没有模块层面的依赖。模块可能已经太过庞大或者难以复合使用的将会被进一步分割成嵌套命名空间中的稍小的模块。

所有模块

所有模块的全图是相当大的。下图展示了这个情况:
其中的注释命名规则是:Namespaces-Module names-Bound classes

Elasticsearch内部探秘_第2张图片
modules-all.png

新模块的产生

大多数模块仅仅会提供一个或者多个类或接口,但是某些模块可以产生它们需要的新模块。这些模块通常依赖当前Setting对象而产生,这是在启动ES的时候从elasticseasrch.yml中读取的。这就让插件作者能够写出替代或者扩展ES内置功能,可以通过默认的配置系统来开启和配置这些插件。

这里有个例子,Discovery Module,默认使用Zen或者Local发现模块,但是可能有其通过设置discovery.type配置值来实现完成另外模块的对换。此乃Sonian的ZooKeeper Discovery的工作原理。

扩展和对换的实现

当我们需要完全对换出ES中整个部件的实现时,这些模块提供给我们一种简单增加ES能力的的方法。因为所有由模块系统实例化的类可能需要一个到任何其他由同一个系统实例化的类的引用,于是通过良定义的接口很容易扩展功能。

AnalysisModule是使用ES和Lucene的开发者最最关心的模块之一。分析模块负责提供索引和搜索时分析器、分词词、字符过滤器和token过滤器。使用这个模块提供的API,很容易增加Lucene适用的分析器、分词器或者过滤器进入ES,只需要几行代码就可以完成。

你可能感兴趣的:(Elasticsearch内部探秘)