对于 JVM 应用程序，是否有充分的理由使用 Elasticsearch REST API？

Question

我正在使用 Elasticsearch 等工具开发 Java 应用程序。

到目前为止，我使用的是 Java 节点客户端。然后前段时间听同事说首选REST API，原因如下：

1. 能够在不影响传输客户端版本的情况下升级 Elasticsearch，即 Java 客户端的版本取决于 ES 集群运行的版本
2. 节点/传输客户端将在即将发布的版本中弃用？
3. 安全性

我现在正试图找出这有多少。

谈到#1，the Elasticsearch docs state （通常）客户端和 ES 集群具有相同的主要版本就足够了。所以，REST API 在这里并没有真正提供更好的东西。

那么，#3 正在由Shield 处理。

我找不到关于 #2 的任何信息。

根据上面的信息，我可能想在我的 Java 应用程序中使用 REST API 的唯一原因是版本独立性，只是为了安全起见。除此之外，不多；这是真的吗？节点/传输客户端是否会被弃用？

Answer 1

我不是 ES 专家，但我们只是在问自己同样的问题，以下是我们对该主题的看法。

1. ES 客户端版本与 ES 服务器版本：
   • 本机客户端遵循您所说的规则：主要版本兼容性。直到最近才出现这种情况，对于真正特定的功能（例如 Percolator），现在仍然不是（对小版本的重大更改），
   • 现在最好的 HTTP 客户端抽象 Jest 似乎也有同样的限制：documentation 说版本 1.x 不适用于 2.x，
   • 最后的解决方案是使用低级别的 HTTP 客户端，但会失去流畅的 Java 抽象。经不起比较，
   • 您无法使用基于本机客户端的 Java 应用程序处理 ES 的混合版本（在具有 1.x 和 2.x 实例的异构环境的情况下）。 HTTP 客户端应该可以实现，因此可以简化一些渐进式迁移场景。
2. 本机客户端弃用：
   • 没有明确说明，而是there will be an official HTTP client for version 5.x。这样一来，拥有两个客户又有什么意义？
3. 安全：
   • 如果需要，可以使用一些中间件（例如 Apache 前端）或使用 https://github.com/Asquera/elasticsearch-http-basic，轻松设置基本 HTTP 安全性，
   • Shield 是官方的，适用于原生和 HTTP，但不是免费的……

在我们的应用程序中，我们使用的是 Spring Data ES。非常易于使用，代码行数很少，但存在版本滞后（在 ES 2 发布后 6 个月支持 2.x）并且基于原生客户端。从我们的角度来看，在开发效率方面的权衡值得。

最后，SAAS 只提供 HTTP API，所以在这种情况下，你别无选择。