elasticsearch - 微服务架构中的Elasticsearch，设计问题

我正在设计一个系统，其中有多个通过中间件进行通信的微服务。

现在，有关微服务的每一个蓝图都强调微服务必须是自治的，并且每个微服务必须处理自己的数据。目前，我系统中的每个微服务都确实将数据存储在关系数据库中。

我对实现全文搜索有新的要求，我的每个微服务都存储可能的可搜索实体。

我当时正在考虑使用ElasticSearch集群，在该集群中我有多个索引，索引将用作分隔来自各种微服务的数据的边界。我想强调一个事实，就是我打算仅将ES用作搜索引擎，而不用作记录系统。

这是我的难题： 1.是否应该允许每个微服务直接处理ES交互（如缓存和持久性）？ 2.还是应该创建一个单独的微服务（称为“搜索”），该微服务将与ES集群交互？我倾向于1. b / c，因为每个微服务都必须在持久性，缓存方面是自治的，它也可以处理全文本搜索。

听到不同的意见会很有趣。

更新：

这就是为什么我认为每个微服务都应分别处理其搜索：

对我来说，全文搜索功能类似于持久性和缓存层，每个微服务都更好地了解业务模型，并负责分别实现这些层。
如果我只是为了进行搜索而引入一种微服务，那我将有一个额外的失败点，如果我们不希望search微服务之间进行直接交互，则将PubSub用作中间人也是一样和其余的包。相反，直接使用ES（这是一种高度可用的SaaS）可以消除单点故障。所有写请求都将很快，并且不会有延迟。信息将立即可搜索。这将确保无缝的用户体验。
我不认为搜索是另一个业务流程（也许我的理解有缺陷）。对我来说，它只是一个不错的功能，而不是核心功能的一部分。但是，一旦实现，我希望它可以提供出色的用户体验。

这种具有单独的search微服务的模型使人联想起CQRS（命令查询责任分离）体系结构模式。首先将数据推送到微服务A中的数据库，然后将其发布到消息传递代理（命令）的地方，消费者将从队列中提取一条消息并将其推送到ES中。然后，在读取路径（查询）上的前端将直接转到search微服务。

我从未见过为搜索而实现这种模式，在大数据世界中这样做是有意义的，在该世界中，一个微服务将摄取数据，然后工作进程将其聚合以进行分析并将其推入聚合的数据表或单独的数据存储，只有这样，数据才可以通过单独的微服务进行查询，从而可以提取分析数据。

是否有任何出版物或ES的CQRS模式的成功实现（考虑到ES不是用作主要的记录系统，而是用作全文搜索引擎）？

我将使用单独的Search服务。原因有很多。

这是另一个（业务）流程，因此您可以更加灵活。假设您可能有CustomerMasterData服务和CustomerAddress服务。但是搜索要求是能够按客户名称或地址进行搜索。具有两个不同的服务器/ ES索引不会使您的生活更轻松。但是，在使用单独的搜索服务的情况下，您实际上可以构建包含来自不同来源的数据的索引。
服务应拥有数据。这意味着Search应该是唯一可以直接访问ES索引的服务。
填充ES索引可以分离并通过与另一服务的通信来完成。我会通过邮件系统来做到这一点。例如，Search服务发送了Sync请求，而其他监听队列的服务将发送数据。它可以使事情保持独立。