将elasticsearch服务直接暴露给客户端或放在中间件后面答案

【问题标题】：expose elasticsearch service directly to the client or put it behind a middleware将elasticsearch服务直接暴露给客户端或放在中间件后面
【发布时间】：2013-06-04 17:45:01
【问题描述】：

我编写了一个客户端服务器应用程序。我在服务器上设置了弹性搜索服务。客户端（iOS 应用）从弹性搜索服务中查询信息。我有两个选择：

1. put the elastic-search behind a nginx server(as proxy server). 
2. write an app running on the middle-ware to wrap the elastic-search APIs(only 
   certain APIs that will be queried by the client).

对于选项 1，所有弹性搜索 API 将同时向客户端和公众公开。

我应该采取什么选择？或者有什么其他好的做法来处理这种情况？

【问题讨论】：

标签： deployment architecture elasticsearch web-deployment

【解决方案1】：

在我看来，你永远不应该向公众提供 ES-API。这样，每个人都可以删除您的索引更改您的映射并做他们想做的任何事情......这简直是危险的。

此外，对于某些只想执行一些基本操作的客户端而言，此 API 的强大功能可能过于复杂。尽管我不知道您的要求，但我建议您将 ES 封装到您自己的 REST-API 中，这可以满足客户端的特定需求。

【讨论】：

【解决方案2】：

如果您的客户端应用程序将使用大部分或整个 Elasticsearch API，则将其置于 Nginx 等代理之后是有意义的。

如果客户端应用程序可以在传统意义上使用 Elasticsearch（搜索，甚至更新文档），我更愿意在它前面放置一个“更智能”的代理，即。你所谓的中间件，用 Ruby、Python 等编写。你可以更严格地控制这里的工作流程，尽管 Nginx 代理也很聪明。

更重要的问题是您是否可以通过 HTTP Auth 或基于令牌的身份验证等方式将 Elasticsearch API 公开给客户端。这样，凭据对客户端来说是清晰可见的，可以被截获等等。

本文中有一个基于 OAuth 的 Elasticsearch 和 JavaScript 客户端应用程序身份验证示例：JavaScript Web Applications and Elasticsearch。它使用 Twitter @Anywhere（被 Sign in with Twitter 取代）对用户进行身份验证，而不允许他通过拦截凭据绕过代理。

【讨论】：