Здравствуйте.

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

Мне казалось, что микросервисы -- это изоляция по функционалу, а не по данным.

Заранее благодарю.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S>Вопрос: правильно ли я понимаю, что в случае микросервисов желательно, или даже необходимо, чтобы у каждого сервиса была своя база данных.
S>Или можно иметь кучу сервисов, которые будут шарить какую-нибудь одну бд, разграничение по схемам или таблицам?

S>Мне казалось, что микросервисы -- это изоляция по функционалу, а не по данным.

S>Заранее благодарю.

Микросервисы — это ОСОБЕННО изоляция по данным. Про общую базу еще Фаулер писал: https://martinfowler.com/bliki/IntegrationDatabase.html

Смысл микросервиса — это изолированная сущность, приносящая бизнес-пользу сама по себе. С общей базой появляются зависимости, single point of failure, не дай бог джойны между данными разных микросервисов и тушите свет.

Общую физическую БД использовать можно, почему нет. главное — чтобы микросервисы не имели доступ к данным друг друга.

Здравствуйте, scf, Вы писали:
scf>Общую физическую БД использовать можно, почему нет. главное — чтобы микросервисы не имели доступ к данным друг друга.
Вот это вот крайне интересная штука, если честно.
Потому, что тут интересы производительности и непротиворечивости входят в явное противоречие с интересами независимого развития.
Я встречал такие системы, но там забавно, что зачастую их развитие наталкивается ровно на эти же ограничения.
Грубо говоря, информация о подчинении хранится в базе Human Resources, а информация о продажах — в базе Sales.
Когда руководство внезапно хочет сравнить перформанс одного и того же менеджера по продажам при его работе под руководством разных руководителей, то мы натыкаемся на то, что данные вытащить никак невозможно. Server-side join невыполним, т.к. микросервисы, а client-side join займёт всё время до остывания галактики.
Зато, если мы когда-то захотим, то сможем легко заменить HR-систему. Вместо PeopleSoft у нас станет Workday, и все интеграции сохранятся. Ага-ага.
Поэтому, чтобы решить эту фундаментальную проблему, мы предлагаем.... Data Warehouse!! Тадаам!
То есть мы теперь обратно соберём все данные в отдельный дорогостоящий сервис, и зато получим возможность извлекать их на ходу.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, scf, Вы писали:
S>Поэтому, чтобы решить эту фундаментальную проблему, мы предлагаем.... Data Warehouse!! Тадаам!
S>То есть мы теперь обратно соберём все данные в отдельный дорогостоящий сервис, и зато получим возможность извлекать их на ходу.

Ну так то да. Текущая работа и формирование отчетов это 2 разные задачи.
Даже в классических RDBMS есть OLTP, а есть OLAP и появилось это разделение за долго до микросервисов.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, scf, Вы писали:
scf>>Общую физическую БД использовать можно, почему нет. главное — чтобы микросервисы не имели доступ к данным друг друга.
S>Вот это вот крайне интересная штука, если честно.
S>Потому, что тут интересы производительности и непротиворечивости входят в явное противоречие с интересами независимого развития.
S>Я встречал такие системы, но там забавно, что зачастую их развитие наталкивается ровно на эти же ограничения.
S>Грубо говоря, информация о подчинении хранится в базе Human Resources, а информация о продажах — в базе Sales.
S>Когда руководство внезапно хочет сравнить перформанс одного и того же менеджера по продажам при его работе под руководством разных руководителей, то мы натыкаемся на то, что данные вытащить никак невозможно. Server-side join невыполним, т.к. микросервисы, а client-side join займёт всё время до остывания галактики.
S>Зато, если мы когда-то захотим, то сможем легко заменить HR-систему. Вместо PeopleSoft у нас станет Workday, и все интеграции сохранятся. Ага-ага.
S>Поэтому, чтобы решить эту фундаментальную проблему, мы предлагаем.... Data Warehouse!! Тадаам!
S>То есть мы теперь обратно соберём все данные в отдельный дорогостоящий сервис, и зато получим возможность извлекать их на ходу.

Есть одно принципиальное отличие — DWH является главным источником данных (source of truth), а в среде микросервисов главным источником являются микросервисы.
Т.е. историчность не нужна, консистентность не нужна, надежность не нужна. Поэтому можно использовать альтернативные методы — qlikview или колоночные СУБД с денормализацией (Kassandra, ES, solr)

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S>Вопрос: правильно ли я понимаю, что в случае микросервисов желательно, или даже необходимо, чтобы у каждого сервиса была своя база данных.
S>Или можно иметь кучу сервисов, которые будут шарить какую-нибудь одну бд, разграничение по схемам или таблицам?

S>Мне казалось, что микросервисы -- это изоляция по функционалу, а не по данным.

Микросервисы — это ограничение в первую очередь по деплойменту. А из этого логично следует, что если микросервисы шарят базу, то независимого деплоймента микросервиса нее получится в принципе.
Но точно ли вам нужны микросервисы?

Здравствуйте, Sinclair, Вы писали:

S>Потому, что тут интересы производительности и непротиворечивости входят в явное противоречие с интересами независимого развития.
Так и есть, с этим надо жить, если уж пошли в сторону микросервисов.

S>Я встречал такие системы, но там забавно, что зачастую их развитие наталкивается ровно на эти же ограничения.
S>Грубо говоря, информация о подчинении хранится в базе Human Resources, а информация о продажах — в базе Sales.
S>Когда руководство внезапно хочет сравнить перформанс одного и того же менеджера по продажам при его работе под руководством разных руководителей, то мы натыкаемся на то, что данные вытащить никак невозможно. Server-side join невыполним, т.к. микросервисы, а client-side join займёт всё время до остывания галактики.
Поэтому грамотное разбиение системы на микросервисы непросто и требует опыта и глубокого понимания предметной области, в том числе понимания куда система будет развиваться на протяжении многих лет.
Конкретно в этом случае, вот так сходу, можно завести еще один микросервис, который будет хранить историю и использоваться только для этого запроса. А данные да, дублировать. Там вас еще eventual consistency ожидает, готовьтесь, никаких ACID

Здравствуйте, itslave, Вы писали:

I>Микросервисы — это ограничение в первую очередь по деплойменту. А из этого логично следует, что если микросервисы шарят базу, то независимого деплоймента микросервиса нее получится в принципе.

Какие ограничения по деплойменту, все свое ношу с собой? Сначала, очевидно, задеплоить базу, далее сервисы. Что не так?

I>Но точно ли вам нужны микросервисы?

Нужны сервисы, где каждый занимается какой-то своей функциональностью, при этом, возможно, будет общая база. Мне всегда казалось (я этот вопрос никогда подробно не изучал),
что микросервисы -- это изоляция по функциональности, т.е. каждый сервис делает что-то одно. Выше подсказали, что это изоляция по данным, что в сущности одно и то же.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, itslave, Вы писали:

I>>Микросервисы — это ограничение в первую очередь по деплойменту. А из этого логично следует, что если микросервисы шарят базу, то независимого деплоймента микросервиса нее получится в принципе.

S>Какие ограничения по деплойменту, все свое ношу с собой? Сначала, очевидно, задеплоить базу, далее сервисы. Что не так?
Микросервис — это полный отдельный проект, со своей командой, своим беклогом и приоретизацией. Соотвественно — верно, все свое ношу с собой. 2 микросервиса не могут шарить базу, потому что один из них может накатить апдейт схемы и поломать работу другого. Шаринг базы, кеша etc. полностью ломает концепцию.

Здравствуйте, itslave, Вы писали:

I>Микросервис — это полный отдельный проект, со своей командой, своим беклогом и приоретизацией. Соотвественно — верно, все свое ношу с собой. 2 микросервиса не могут шарить базу, потому что один из них может накатить апдейт схемы и поломать работу другого. Шаринг базы, кеша etc. полностью ломает концепцию.

В чем проблема иметь физически одну бд, и разные схемы, со своими правами доступа для каждого сервиса?

Здравствуйте, Sharov, Вы писали:

S>В чем проблема иметь физически одну бд, и разные схемы, со своими правами доступа для каждого сервиса?
Так можно, но в этом случае модель данных то шарится не будет и поэтому с логической точки зрения — это 2 разных базы