微服务设计中的ElasticSearch

Question

我们有微服务设计，并且有DocumentService和DocumentReportService。

DocumentsService-获取文档，以ELK搜索文档。

DocumentsReportsService-以doc格式生成报告，导出为PDF格式，例如我想再次使用ELK作为存储。

问题：DocumentsService和DocumentReportService的ELK是1个ELK实例还是2个？

Answer 1

DocumentReportService应该使用DocumentService代替自己的ES。

ELK还是Elasticsearch，Logstash，Kibana

Answer 2

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

我会主张“没有这样的东西会造成不良设计”的说法。设计应始终满足您的需求，同时应足够简单易懂。记住KISS design principle。

微服务同时支持两种数据库模式

• Database per service
• Shared database

两者都有其优点和缺点。 但是，在微服务中进行设计时不应遗漏或忽略的事情是有限上下文。

在您的情况下，我认为一个更简单的设计版本可以使边界得到明确定义：

文档服务：承担与文档存储进行交互的主要责任（在您的情况下为Elastic search）。它是检索服务，如果需要，将文件存储在文件存储中。保持文档服务是唯一与文档存储交互的功能，这为您提供了其他服务的优势，而不必担心文档的存储方式和位置。其他服务仅知道一种服务，其中包含了提供和存储文档的责任。如果将来要更改文档存储，则可以轻松更改它，而不会影响环境中的任何其他服务。 （与许多服务正在与您的数据存储进行交互的情况相比，如果要更改存储，则所有这些服务都必须包含所做的更改）。 因此，您将看到上下文的边界如何使您的设计具有可扩展性。

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

Answer 3

我假设，您的问题是针对两个服务使用相同的ES群集还是针对每个服务使用单独的群集。

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

因此，在您的情况下，如果两个服务在ES中都使用单独的索引和映射，则它们可能使用相同的群集。您应该避免的是，两个服务都必须对同一映射进行读写，因为这会导致紧密耦合。