微业务设计中的ElasticSearch

Question

我们有微型服务设计，也有DocumentService和DocumentReportService.

DocumentsService -获取文档，在麋鹿中搜索文档。

DocumentsReportsService -生成文档中的报告，导出成PDF，例如，我想再次使用ELK作为存储。

问题:对于DocumentsService和DocumentReportService来说，ELK是一个ELK实例还是2个？

Answer 1

DocumentReportService应该使用DocumentService而不是他自己的ES。

还有Elasticsearch，Logstash，Kibana

Answer 2

如果您的问题是对两个服务都使用相同的ES集群，还是对每个服务使用单独的群集，那么-

我主张这样的说法：“没有这样的东西是不好的设计”。设计应该总是补充您的需求，同时也应该是足够简单的理解。记住接吻设计原则。

Microservices支持数据库的两种模式。

• 每个服务的数据库
• 共享数据库

两者各有优缺点。但是，在微服务中进行设计时不应忽略或忽略的是有界上下文。

在您的情况下，我想一个更简单的设计版本可能会很好地定义边界：

​

​

文档服务：承担与文档存储交互的主要责任(在您的例子中是弹性搜索)。检索并在需要时将文档存储在文档存储中的是服务。保持文档服务--唯一与文档存储交互的服务--可以使您获得其他服务的优势，而不必担心文档存储的方式和位置。其他服务只知道一个服务，它封装了提供和存储文档的责任。如果将来想要更改文档存储，可以很容易地更改它，而不会影响到您的领域中的任何其他服务。(相比之下，当许多服务与您的数据存储交互时，如果您想要更改存储，那么所有这些服务都必须合并这些更改)。因此，您可以看到上下文是如何使您的设计可扩展的。

报告服务：负责生成报表。它封装了创建完整报告的整个业务逻辑(仅生成)。此服务不知道文档/报表存储的位置。(此服务仅限于生成报表而不是存储报表)

Answer 3

我想，您的问题是，是为两个服务使用相同的ES集群，还是为每个服务使用单独的集群。

在Microservice体系结构中，“共享数据库”被认为是一种不好的做法--实际上，多个服务不应该访问相同的数据库对象，因为它会导致它们之间的紧密耦合。很有可能，多个服务仍然可以使用数据库的同一个物理实例。

因此，在您的示例中，如果两个服务在ES中使用单独的索引和映射，那么它们可能使用相同的集群。您应该避免的是将服务读写到相同的映射中，因为这会导致紧密耦合。