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

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

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

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

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

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

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

更新：

这就是为什么我认为每个微服务都应该单独处理它们的搜索：

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

这种拥有单个微服务的模型search让人想起 CQRS（命令查询职责分离）架构模式。我首先将数据推送到我的微服务 A 中的数据库，然后将其发布到消息传递代理（命令），消费者将从队列中提取一条消息并将其推送到 ES。然后前端，在读取路径（查询）上，将直接进入search微服务。

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

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

标签： elasticsearchmicroservices

我会选择单独的Search服务。有几个原因。

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