我们有微服务设计，我们有DocumentService 和DocumentReportService。
DocumentsService - 获取文档，在 ELK 中搜索文档。
DocumentsReportsService - 在 doc 中生成报告，导出为 PDF，例如我想再次使用 ELK 作为存储。
问题：DocumentsService 和 DocumentReportService 的 ELK 是 1 个 ELK 实例还是 2 个？
【问题讨论】：
标签： elasticsearch design-patterns microservices
如果您的问题是对两个服务使用相同的 ES 集群还是为每个服务使用单独的集群-
我主张“没有糟糕的设计”这样的说法。设计应该始终补充您的要求，同时应该足够简单易懂。记住KISS design principle。
微服务支持两种数据库模式
两者各有利弊。 但是在微服务设计中不应该忽略或忽视的是bounded context。
在你的情况下，我想一个更简单的设计版本可以很好地定义边界：
文档服务：主要负责与文档存储交互（在您的情况下为弹性搜索）。它是检索文档并在需要时将文档存储在文档存储中的服务。将文档服务保持为唯一与文档存储交互的服务可以让您利用其他服务，而无需担心文档的存储方式和存储位置。其他服务只知道一种服务，它封装了提供和存储文档的责任。如果将来您想更改文档存储，可以轻松更改它，而不会影响您的环境中的任何其他服务。 （与许多服务与您的数据存储交互并且如果您想更改存储所有这些服务必须合并更改相比）。 因此，您会看到上下文边界如何使您的设计具有可扩展性。
报告服务：负责生成报告。它封装了创建完整报告（仅生成）的整个业务逻辑。该服务不知道文档/报告的存储位置。 （此服务只限于生成报告而不是存储报告）
【讨论】：
DocumentReportService 应该使用 DocumentService 而不是他自己的 ES。
ELK 也是 Elasticsearch、Logstash、Kibana
【讨论】：
我假设，您的问题是是否为两个服务使用相同的 ES 集群或为每个服务使用单独的集群。
在微服务架构中，“共享数据库”被认为是一种不好的做法——实际上，这意味着多个服务不应访问相同的数据库对象，因为这会导致它们之间的紧密耦合。 很可能多个服务仍然使用数据库的相同物理实例。
因此，在您的情况下，如果两个服务在 ES 中使用单独的索引和映射，它们可能使用相同的集群。您应该避免服务读取和写入到相同的映射，因为这会导致紧密耦合。
【讨论】：