Как обмениваться общими данными через несколько микросервисов - PullRequest
0 голосов
/ 26 апреля 2018

Я пишу дипломную работу бакалавра о микросервисах.

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

Мой подход заключается в том, что я создам новую схему базы данных с этими конкретными таблицами и разрешу всем микросервисам читать из нее. Это будет подход с общим ядром, который не рекомендуется экспертами Microservices.

Есть ли у вас опыт или рекомендации по этой проблеме?

Есть ли у вас какие-либо рекомендации относительно книг, посвященных аналогичным проблемам?

Ответы [ 3 ]

0 голосов
/ 29 апреля 2018

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

Еще одна вещь, которую следует учитывать, - это то, что если у вас есть N микросервисов, которым нужно больше, чем ссылки на одни и те же биты данных, то, скорее всего, вам лучше будет хранить эти сценарии использования вместе в одном сервисе, чем разбивать его. Фред Джордж говорит о том, что нужно просто попытаться разделить ваши микросервисы на «сервисы сущностей»:

https://www.youtube.com/watch?v=vs_XiP5Lkgg

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

0 голосов
/ 25 мая 2019

вы можете создать единый микросервис для управления этими общими данными (например, данные о стране или регионе и т. Д.) И реплицировать таблицы между всеми микросервисами.

Этот микросервис был единственной точкой управления этими данными (с CRUD). При операции создания, обновления или удаления вы синхронизируете все микросервисы с асинхронной связью (kafka, rabbitMQ)

Благодаря этому решению все микросервисы были независимы друг от друга и были синхронизированы с данными без http-вызова для обеспечения максимальной производительности.

0 голосов
/ 26 апреля 2018

Вы должны быть знакомы с статьей Пэта Хелланда Неизменность меняет все .

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...