ElasticSearch в дизайне микроуслуг

Question

у нас есть дизайн микро-услуг, и у нас есть DocumentService и DocumentReportService.

DocumentsService - получение документов, поиск документов в ELK.

DocumentsReportsService - создание отчетов в формате doc, экспорт в PDF и т. Д., И я хочу снова использовать ELK в качестве хранилища.

Вопрос: ELK для DocumentsService и DocumentReportService это 1 экземпляр ELK или 2?

Answer 1

DocumentReportService должен использовать DocumentService вместо своей собственной ES.

Также ELK - это Elasticsearch, Logstash, Kibana

Answer 2

Если ваш вопрос заключается в том, использовать ли один и тот же кластер ES для обеих служб или отдельный кластер для каждого, то -

Я бы выступил за утверждение «плохого дизайна не бывает». Дизайн всегда должен дополнять ваши требования и в то же время должен быть достаточно простым для понимания. Запомните принцип дизайна KISS .

Микросервисы поддерживают оба шаблона для базы данных

• База данных на услугу
• Общая база данных

У обоих есть свои плюсы и минусы. Но при проектировании в микросервисах не следует упускать из виду или пренебрегать ограниченным контекстом .

В вашем случае, я думаю, что более простая версия дизайна могла бы поддерживать четкие границы:

Служба документов : берет на себя основную ответственность за взаимодействие с хранилищем документов (в вашем случае Elastic search). Это службы, которые извлекают и при необходимости сохраняют документ в хранилище документов. Сохранение службы документов единственной, взаимодействующей с хранилищем документов, дает вам преимущество, так как другим вашим службам не нужно беспокоиться о том, как и где хранятся документы. Другие службы просто знают одну службу, которая включает в себя ответственность за предоставление и хранение документов. Если в будущем вы захотите изменить хранилище документов, его можно легко изменить, не влияя на другие службы в вашем ландшафте. (по сравнению с тем, когда многие службы взаимодействуют с вашим хранилищем данных и если вы хотите изменить хранилище, все эти службы должны включать эти изменения). Итак, вы видите, как ограничивающий контекст сделал ваш дизайн расширяемым.

Служба отчетов : берет на себя ответственность за создание отчета. Он заключает в себе всю бизнес-логику создания полных отчетов (только генерации). Эта служба не знает, где хранятся документы / отчеты. ( Эта служба ограничена только генерацией отчетов без хранения отчетов )

Answer 3

Я предполагаю, что ваш вопрос заключается в том, использовать ли один и тот же кластер ES для обеих служб или отдельный кластер для каждой.

В архитектуре Microservice считается плохой практикой "совместно использовать базу данных" - на практике чтоподразумевается, что несколько служб не должны обращаться к одним и тем же объектам базы данных, поскольку это приведет к тесной связи между нимиВполне возможно, что несколько служб могут по-прежнему использовать один и тот же физический экземпляр базы данных.

Так что в вашем случае, если обе службы используют отдельный индекс и отображение в ES, они могут использовать один и тот же кластер.Чего следует избегать, так это чтобы службы считывали и записывали в одно и то же отображение, так как это приведет к тесной связи.