将elasticsearch服务直接暴露给客户端或将其置于中间件之后

时间:2013-06-08 14:49:22

标签: deployment architecture elasticsearch web-deployment

我编写了一个客户端服务器应用程序我在服务器上设置了弹性搜索服务。 客户端(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将同时向客户端和公众公开。

我应该选择什么?还是有其他好的做法来处理这种情况?

2 个答案:

答案 0 :(得分:4)

在我看来,你绝不应该向公众提供ES-API。 通过这个,每个人都可以删除你的索引改变你的映射并做任何他们想做的事情......这只是一个危险的。

此外,对于某些客户来说,这种API的强大功能可能过于复杂,只是想执行一些基本操作。 尽管我不了解您的要求,但我建议您将ES包装到您自己的REST-API中,以满足客户的特定需求。

答案 1 :(得分:3)

如果您的客户端应用程序会使用多数或整个Elasticsearch API,那么将它放在Nginx之类的代理之后是有意义的。

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

更重要的问题是,您是否可以通过HTTP Auth或基于令牌的身份验证向客户端公开Elasticsearch API。通过这种方式,客户端可以清楚地看到凭证,可以截取等等。

本文中有一个针对Elasticsearch和JavaScript客户端应用程序的基于OAuth的身份验证的示例:JavaScript Web Applications and Elasticsearch。它使用 Twitter @Anywhere (由使用Twitter登录取代)对用户进行身份验证,而不允许他通过拦截凭据绕过代理。