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

Question

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

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

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

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

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

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

更新：

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

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

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

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

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

Answer 1

另一个搜索服务会过度抽象它。

我会做什么：

使用现已免费的 Xpack Security RBAC 将每个微服务的索引锁定到该服务配置为使用的帐户： https: //www.elastic.co/blog/security-for-elasticsearch-is-现在免费
使用 Elasticsearch 中的搜索模板将搜索逻辑从服务抽象到 ES，然后让服务调用模板。